Skrypt Pythona daje`: No such file or directory`
Mam kilka skryptów Pythona, które działają dobrze, ale jeden skrypt (od dziś rano) zaczął dawać mi ten błąd, jeśli próbuję go uruchomić z Basha:
: brak takiego pliku lub katalogu
Jestem w stanie uruchomić "zepsuty" skrypt wykonując python script_name.py i po rozejrzeniu się trochę ogólny pomysł, że odebrałem było to, że może moja końcówka linii hashbang został zmieniony (po cichu) więc spojrzałem na końcówkę linii działającego skryptu i uszkodzony skrypt przez :set list opcja w VI wskazana w tym pytaniu - > wyświetl zakończenia linii w pliku tekstowym
Oba pliki kończą się tym samym znakiem (a $), więc nie wiem, jak dalej postępować. W szczególności, jak właściwie "zobaczyć" linię kończącą się w przypadku, gdy set list nie była właściwą metodą.
PS: skrypt jest wykonywalny i tam jest shebang, stwierdziłem, że to tylko ten 1 skrypt, który działał dobrze przed weekendem, ale zaczął dawać mi ten błąd od dziś rano.
-- edit: --
Uruchomienie skryptu przez dos2unix sprawia, że działa ponownie, ale chciałbym wiedzieć, jak wizualizować linię kończącą się jakoś w VI (M) lub dlaczego Geany jakoś przekonwertował zakończenia linii w pierwszej kolejności(ponieważ nigdy nie pracuję na systemie dos/windows).
4 answers
Z powyższych komentarzy wynika, że masz zakończenia linii dos, więc linia hashbang nie jest poprawnie przetworzona.
Style zakończenia linii nie są wyświetlane z :set list w Vim, ponieważ ta opcja jest używana tylko podczas odczytu / zapisu pliku. W pamięci zakończenia linii są zawsze takie, zakończenia linii. Styl zakończenia linii używany dla pliku jest przechowywany w opcji vim per-file, dziwnie zwanej fileformat.
Aby zobaczyć/zmienić styl zakończenia linii z Vima, możesz użyć następującego polecenia:
:set fileformat
:set ff
Pokaże dos lub unix. Chcesz unix, oczywiście; -).
Aby go szybko zmienić, możesz zapisać plik za pomocą:
:w ++ff=unix
Lub jeśli wolisz:
:set ff=unix
A następnie zapisz plik normalnie.
Zobacz wszystkie :help fileformat, :help file-formats i :help fileformats
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-04 10:26:16
Możesz również użyć polecenia dos2unix do konwersji formatu pliku
Dos2unix
To pomogło mi uruchomić skrypty Pythona
Zwykle dzieje się tak, gdy otwieramy pliki w systemie windows i je zapisujemy. jeśli otworzysz plik, znajdź znaki ^m na końcu każdej linii
Thanks
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-09-29 08:41:06
Osobiście uważam, że używanie bezpośredniej ścieżki do interpretera Pythona jest trochę niewłaściwe. Ponieważ nie używasz platformy windows, powinieneś mieć program env, zwykle w /usr / bin (/usr/bin / env). Spróbuj użyć następującego shebang:
#!/usr/bin/env python
Różne dystrybucje przechowują binarne Pythona w /bin lub / usr / bin (lub w niektórych dziwnych lokalizacjach), a to sprawia, że Twój skrypt jest niezależny od konfiguracji (o ile to możliwe, Tutaj mamy możliwość, że env jest przechowywany gdzie indziej; jednak jest mniej prawdopodobne, że env nie jest w /usr / bin niż ten python jest błędnie umiejscowiony).
Miałem podobny problem (jeśli nie dokładnie taki sam) i to zadziałało.
Mam również oba interpretery Pythona (2.7.x i 3.X) zainstalowany, więc muszę użyć argumentu "python3" dla env. AFAIR zwykle łączy różne nazwy z różnymi binariami, więc "ENV python" uruchomi python2. 7 na moim systemie, "env python3" (również python33, lub smth jak ten) uruchomi P3K, a "env python2" (również python27, itd.) uruchomi Pythona 2.7.X. deklarowanie, które wersja interpretera powinna być używana.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-04 10:02:54
Natknąłem się na ten problem edytując mój kod w Windows, sprawdzając go w git, i sprawdzając i uruchamiając go na Linuksie.
Moim rozwiązaniem było: powiedz gitowi, żeby postąpił właściwie. Wydałem to polecenie w oknie Windows:
git config --global core.autocrlf true
Zmodyfikowałem pliki i sprawdziłem je; voila, już nie ma takiego problemu.
Jak omówiono w dokumentacji Git .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-08-11 21:17:30