2009-08-30 4 views
63

Quelqu'un le sait? Je n'ai jamais été capable de trouver une réponse.Pourquoi "#!/Usr/bin/env python" est-il supposé plus correct que "#!/Usr/bin/python"?

+4

pas une tonne. je suis sur osx et la page de manuel env est plutôt ambigu là-bas. –

+16

@ S.Lott: Avez-vous * lu * récemment? Dans ma boîte Debian, c'est l'une des pages de manuel les plus inutiles que j'ai jamais vues, et cela dit quelque chose. (Voici toute la "Description": Mettez chaque NOM à VALEUR dans l'environnement et exécutez la COMMANDE Yup, cela l'effacera tout de suite.) – Telemachus

+0

@Telemachus: Oui, je l'ai lu. C'est pourquoi j'ai trouvé l'entrée Wikipedia. –

Répondre

64

Si vous êtes enclin à l'installation de python dans des endroits différents et intéressants sur votre PATH (comme dans $PATH dans les shells Unix typiques, %PATH sur les Windows typiques), en utilisant /usr/bin/env répondra à votre caprice (bien, dans les environnements Unix-like au moins) tout en allant directement à /usr/bin/python ne sera pas. Mais perdre le contrôle de la version de Python sous vos scripts n'est pas une bonne affaire ... si vous regardez mon code, vous êtes plus susceptible de le voir commencer par, par exemple, #!/usr/local/bin/python2.5 plutôt qu'avec un #!/usr/bin/env python ouvert et acceptant - en supposant le script est important, je veux m'assurer qu'il fonctionne avec la version spécifique que j'ai testée et développée avec, PAS une version semi-aléatoire ;-).

+38

Bien sûr, vous pouvez toujours utiliser #!/Usr/bin/env python2.5 pour contraindre l'ensemble des choix semi-aléatoires: =) –

+1

+1 Bonne explication, merci! Je n'avais pas rencontré cette utilisation de "env" avant ... maintenant j'ai quelque chose à ajouter à mon sac-de-script. –

+3

+1 pour justifier l'utilisation de "env python". Je me suis rendu compte que si je voulais utiliser "env python", je ferais mieux de coder pour le plus petit dénominateur commun, puisque je n'aurais aucun contrôle sur la version de python que l'utilisateur a dans le PATH. –

5

Il trouve 'python' aussi dans/usr/local/bin, ~/bin,/opt/bin, ... ou partout où il peut cacher.

+0

merci! En fait, cela m'a causé un problème parce que, pour une raison quelconque, env n'existait pas. –

+3

C'est un peu trompeur. Il va seulement trouver le premier "python" sur vos instances $ PATH et Python en cours sur OS X peut être assez bon à cacher. En particulier, le framework standard est construit à partir de python.org et d'autres ont des sous-répertoires "bin" dans le framework où "python" et d'autres exécutables et scripts sont stockés. Il est très facile de se retrouver avec plusieurs instances qui peuvent ou non avoir des liens symboliques dans les endroits habituels, comme/usr/local/bin et al. Gérer $ PATH sur OS X dans ce cas n'est pas aussi simple que sur les systèmes sans builds de type framework. –

+2

@KennethReitz: si '/ usr/bin/env' n'existe pas, votre système est cassé. 'env'est un outil requis par la norme POSIX. – MestreLion

24

De wikipedia

Shebangs spécifier des chemins absolus à executables du système; cela peut causer des problèmes sur les systèmes qui ont mises en page du système de fichiers non standard

Souvent, le programme/usr/bin/env peuvent être utilisés pour contourner cette limitation

10

il trouve l'exécutable python dans votre environnement et utilise cela. c'est plus portable car python n'est pas toujours dans/usr/bin/python. env est toujours situé dans/usr/bin.

+0

env n'est pas toujours là, mais nous augmentons la probabilité que le script trouve Python sur plusieurs machines. :) – Will

Questions connexes