Python3 script furcsaság

Szkriptek: Python, Perl, Bash, ...

Van egy egyszerű python3 scriptem a while ciklushoz, csak ennyi:

#!/usr/bin/env python3
while True:
s = input('Kérdés')

Elmentettem egy fájlba, amit futtathatóvá tettem.
Ha így futtatom:
python3 whilex.py akkor rendben lefut.
de ha így ./whilex.py akkor hibaüzenetet kapok, hogy nincs ilyen fájl vagy könyvtár.
Ez miért van? Egyszerűen nem értem mi a baja.

  • 2354 megtekintés

Láttam a screenshotodból, hogy nem ez. A 3 byte-tal hosszabb fájl árulkodott.
Lássuk: 


cat >> teszt.py
#!/usr/bin/env python3
while True:
   s = input('Kérdés')

chmod +x teszt.py
./teszt.py

le fog futni

todos teszt.py # ennek hatására #!/usr/bin/env python3\r lesz
./teszt.py
: Nincs ilyen fájl vagy könyvtár

nem fog lefutni.

Körüljártam egyúttal még jobban: kivettem az "env"-et, "#!/usr/bin/python3\r" maradt rejtett dos-os \r-rel, és lefuttattam:

./teszt.py
bash: ./teszt.py: /usr/bin/python3^M: rossz parancsértelmező: Nincs ilyen fájl vagy könyvtár

Mennyivel beszédesebb ez a hibaüzenet.

Érdekes problémára világítottál rá, ami más szkriptnyelvnél is #!/usr/bin/env xxxx esetén problémát okozhat. Köszi.

Nincs mit! Igazság szerint nem is csináltam volna ebből topicot, csak azt hittem én vagyok a hülye, hogy a script Python3 IDLE-ben működik, parancssorban meg nem. Az eltérő méret miatt nem gondoltam karakterkódolási hibára, azt hittem csak azért nem egyezik a méret, mert az egyikben több Enter-t ütöttem.

A héten jártam én is így, egy levélben kiküldött script fájllal. Csak nem futott le a fogadó félnél. Aztán meglett hogy ez a probléma :/

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: https://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes

( THavoc v | 2015. 12. 11., p – 02:58 )

probald igy:
#!/usr/bin/python3

Ha nincs jol beallitva a PATH, az env ossze-vissza mukodhet

Ilyet még nem láttam. Olyan mintha ez a fájl sérült volna. De hogy lehet sérült egy 3 soros szövegfájl?
Nem számít ha átnevezem, ha másolom, ha kicserélem a parancsokat, ez a fájl nem fut le. De ha létrehozok egy másik fájlt és copy-zom parancsokat, az meg lefut. Megáll az eszem.

No, a megoldás az lesz, amit a többiek is feszegetnek itten. Ha valamiért \n helyett \r\n van a sorok végén (windows alatt lett mentve?)

Emiatt a bash az első sort úgy értelmezi, hogy a python3\r nevű környezeti változót akarod kiszedni, ami értelemszerűen nincs, ezért is írja neked, hogy ":command not found" (látod a kettőspontot, előtte volna a parancs amit próbált futtatni)

Megoldás: Konvertáld át hogy a sorvégződések ne windowsosak legyenek :)

Az az igazság, hogy az eredeti fájl a coded nevű WP8 alkalmazásban készült.
Akkor ezek szerint ez karakterkódolási hiba. Hogy tudom átkonvertálni? Hogy lehet ezt elkerülni? Mert ez így elég gáz.
Ezen a linken megtalálható:
https://onedrive.live.com/?cid=0290852993448AC9&id=290852993448AC9!1689…

Köszönöm. Kipróbálom. Bár gondolom, ilyen konvertálást, bármelyik editor tud. Jobb szeretném ezt a problémát megelőzni.

Ezután Linux -programozáshoz Linux alkalmazást (lehetőleg konzolosat) használj, szerintem.
Egyelőre még csak ismerkedem a python-nal, így a Python IDLE-t használom elsősorban. Innen is jött a probléma, mert ott működött a script, konzolon meg nem.

Én az elvre nem jöttem rá. Ha az órán nekem azt mondta a tanár tollbamondáskor, hogy új sor, akkor a sor elején kezdtem írni.

Valaki tudja, miért alakult ki a történelem során az MS-féle kocsivissza+újsor? Tehát a technikatörténet során miért lett a kétféle rendszer?

Ha logikai szempontból vizsgálod, van értelme a CR LF-nek, csak pazarlás. Például írsz egy terminálos alkalmazást, ahol rendszeres időközönként ki kell írnod, hány százaléknál tart a folyamat. Itt csak CR-re van szükséged LF nélkül, mert a kurzort a sor elejére viszed, majd ugyanazt a sort kell felülírnod.

Mondjuk az LF értelme CR nélkül valóban vitatható, nem tartom életszerűnek, hogy a következő sorban ugyanattól a vízszintes pozíciótól folytassunk valamit. Lényegében éppen ezt használja ki a GNU/Linux. A CR-t valóban CR-ként, azaz kurzor sor elejére küldéseként értelmezi, míg az LF-be beleért egy CR-t is, tehát valójában CR LF-et csinál.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valaki tudja, miért alakult ki a történelem során az MS-féle kocsivissza+újsor? Tehát a technikatörténet során miért lett a kétféle rendszer?

Ez volt előbb. A nyomtató számára a "menjünk vissza a sor elejére" egy önálló művelet, a "tekerjünk a papíron felfele" egy másik. Mind a kettőre szükség lehet magában, és pl. a mátrix nyomtatókon lehet is használni (minek mozgassuk a fejet, ha nem muszáj, mert egymás alá akarunk nyomtatni, ha meg rá akarunk nyomtatni ugyanarra a sorra megint, akkor meg kell a CR is).

Az LF-only tudtommal a UNIX-ot és a C nyelvet kitalálók "egyszerűsítése" volt.

UNICS 1969 (még assembly-ben írva) és Kernighan-Ritchie féle C 1972.
MSDOS 1981

Melyik őstől örökölhette a CR+LF kombinációt az MSDOS, mert hogy nem a UNICS-tól az LF-et az biztos.

És egy jövőbemutató gondolat:
- vajon mikor lesz mindenhol egységesen CR (azonos sor felülírása) és az újsorra egyetlen LF (újsor) karakter?
- vajon mikor lesz mindenhol egységesen UTF8 a 7 bites ASCII karaktereken túlmutató karakterekre?

Szerintem nem a Unix-hoz van köze, hanem a soros terminálok és nyomtatók világához, valamint az ASCII-kódokhoz. Nézd meg az ASCII táblázat 0-0x1F tartományát, a vezérlőkódok jelentését. Abból nagyon érződik, hogy az akkoriban szokásos technológiát szolgálta ki. Az UTF-8 felvetése jogos, bár ez csak egy unicode implementáció, a gyakorlatban talán a legcélszerűbb. Ugyanakkor unicode-ot lehet más módon, például UTF-16, vagy UTF-32 kódolással ábrázolni. A CR LF nem egyszerű, mert bár logikus a Unix szokásos eljárása, valójában éppen ez a csalás, a tömörítés. Igazán tisztességesen ki kellene írni a CR LF-et, tekintve azok eredeti, ASCII jelentését, más kérdés, hogy manapság ezt meghaladta a kor.

Én nem szoktam beleszaladni efféle hibába, mert azok után, hogy egy valami.xls nevű html file-lal találkoztam egykoron, óvatos vagyok, tanultam a figyelmetlenségemből, s ha valami nem stimmel, azonnal megnézem file paranccsal illetve hex viewerrel is a file-t.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyrészt soha, másrészt kb ugyanakkor.

Egyébként az nem igaz, hogy 'unixon nincs CR', csak az, hogy a 'unixos texfájlokban nincs CR'. De amikor a terminállal kommunikálunk, akkor nagyon is van.

Az utf8 kb akkor lesz univerzális, ha a mindenki, aki most utf16-ot használ, gyorsan átáll. Ilyenek pl: MS Windows, Java, Oracle, IBM AIX... Szóval én még nem várom holnapra.

Ha igazán ügyes lenne az env, írhatna egy figyelmeztetést, hogy "python3\r nincs, csak python3"
Vagy úgy kell beállítani a verziókövetőt (mivel nem említette a kolléga, feltételezem, hogy most nem használt), hogy Windowson windowsos soremeléssel vegye ki a fájlokat, Linuxon linuxossal.

Fuszenecker Róbert