Python donne `: Aucun fichier ou répertoire de ce type`
J'ai plusieurs scripts python qui fonctionnent très bien mais un script a (à partir de ce matin) commencé à me donner cette erreur si j'essaye de l'exécuter à partir du bash:
: Aucun fichier ou répertoire de ce nom
Je peux exécuter le script "cassé" en faisant python script_name.py et après avoir regardé un peu autour de moi, l'idée générale que j'ai prise était que peut-être ma fin de ligne du hashbang avait changé (silencieusement) alors j'ai regardé la fin de ligne d'un script de travail et d'un script cassé via le :set list option dans VI comme indiqué dans cette question -> Afficher les fins de ligne dans un fichier texte
Les deux fichiers semblent se terminer avec le même caractère (un $) donc je ne sais pas trop comment procéder à partir d'ici. Plus précisément, comment réellement "voir" la ligne se terminant au cas où le set list n'était pas la bonne méthode.
PS: Le script est exécutable et le Shebang est là, j'ai déclaré que c'est juste ce 1 script qui fonctionnait bien avant le week-end mais il a commencé à me donner cette erreur à partir de ce matin.
-- modifier: --
Exécution du script via dos2unix le fait fonctionner à nouveau mais j'aimerais savoir de quelle façon visualiser la ligne se terminant d'une manière ou d'une autre dans VI (M) ou pourquoi Geany a en quelque sorte converti les fins de ligne en premier lieu (car je ne travaille jamais sur un système DOS/Windows de toute façon).
D'après les commentaires ci-dessus, il semble que vous ayez des terminaisons de ligne de dos, et donc la ligne de hachage n'est pas correctement traitée.
Le style de fin de ligne ne s'affiche pas avec :set list dans Vim car cette option n'est utilisée que lors de la lecture/écriture du fichier. En mémoire, les fins de ligne sont toujours des fins de ligne. Le style de fin de ligne utilisé pour un fichier est conservé dans une option Vim par fichier, étrangement appelée fileformat.
Pour voir/modifier le style de fin de ligne de Vim, vous pouvez utiliser les commandes suivantes:
:set fileformat
:set ff
Il affichera dos ou unix. Vous voulez unix, bien sûr ;-).
Pour le changer rapidement, vous pouvez enregistrer le fichier avec:
:w ++ff=unix
Ou si vous préférez:
:set ff=unix
Et puis enregistrez le fichier normalement.
Alors, voyez tous les détails sanglants juste faire :help fileformat, :help file-formats et :help fileformats
Vous pouvez également utiliser la commande dos2unix pour convertir le format de fichier
dos2unix
Cela m'a aidé à exécuter les scripts python
Cela se produit normalement lorsque nous ouvrons des fichiers dans Windows et que nous les enregistrons. si vous ouvrez le fichier localisez les caractères ^ M à la fin de chaque ligne
Merci
Personnellement, je trouve ça un peu mal en utilisant le chemin direct vers l'interpréteur python. Comme vous n'utilisez pas la plate-forme Windows, vous devriez avoir le programme env, généralement dans/usr/bin (/ usr/bin/env) Essayez d'utiliser le Shebang suivant:
#!/usr/bin/env python
Différents magasins de distributions python binaire dans/bin ou/usr/bin (ou certains emplacements étranges), et celui-ci rend votre script indépendant de la configuration (dans la mesure du possible, nous avons ici la possibilité que env est stocké ailleurs; encore - il est moins possible que env ne soit pas dans/usr/bin que cela python est mal placé).
J'ai eu un problème similaire (sinon exactement le même) et cela a fonctionné pour moi.
De plus, j'ai les deux python interprètes (2.7.x et 3.x) installés, donc j'ai besoin d'utiliser l'argument "python3" pour env. AFAIR distribue généralement des liens différents noms à différents binaires, donc "env python" exécutera python2.7 sur mon système, "env python3" (également python33, ou smth comme ça) exécutera p3k et "env python2" (également python27, etc) exécutera python 2.7.x. La déclaration de la version de l'interpréteur à utiliser semble également être une bonne idée.
J'ai rencontré ce problème lors de l'édition de mon code sous Windows, de l'archivage avec git, de l'extraction et de son exécution sous Linux.
Ma solution était: dites à git de faire la bonne chose. J'ai émis cette commande sur la boîte Windows:
git config --global core.autocrlf true
Modifié les fichiers et les a archivés; le tour est joué, plus aucun problème de ce genre.
Comme discuté sur le documentation Git .