Pourquoi les gens écrivent-ils #!/usr/bin/env python sur la première ligne d'un script Python ?

Question

Je vois ceci en haut des fichiers Python :

1. Pour les fichiers Python 2

   #!/usr/bin/env python

2. Pour les fichiers Python 3

   #!/usr/bin/env python3

Il me semble que les fichiers fonctionnent de la même manière sans cette ligne.

Answer 1

Si vous avez plusieurs versions de Python installées, /usr/bin/env s'assurera que l'interpréteur utilisé est le premier sur la liste de l'environnement $PATH . L'alternative serait de coder en dur quelque chose comme #!/usr/bin/python ; c'est correct, mais moins flexible.

Dans Unix, un exécutable qui est destiné à être interprété peut indiquer quel interpréteur utiliser en ayant une balise #! au début de la première ligne, suivi de l'interpréteur (et de tous les drapeaux dont il peut avoir besoin).

Si vous parlez d'autres plates-formes, bien sûr, cette règle ne s'applique pas (mais cette "ligne shebang" ne fait pas de mal, et sera utile si jamais vous copiez ce script sur une plate-forme. avec une base Unix, comme Linux, Mac, etc).

Answer 2

C'est ce qu'on appelle le ligne shebang . Comme le L'entrée de Wikipedia explique :

En informatique, un shebang (également appelé hashbang, hashpling, pound bang ou crunchbang) désigne les caractères "# !" lorsqu'ils sont les deux premiers caractères d'une directive d'interpréteur comme première ligne d'un fichier texte. Dans un système d'exploitation de type Unix, le chargeur de programme prend la présence de ces deux caractères comme une indication que le fichier est un script, et essaie d'exécuter ce script en utilisant l'interpréteur spécifié par le reste de la première ligne du fichier.

Voir également le Entrée de la FAQ Unix .

Même sous Windows, où la ligne shebang ne détermine pas l'interpréteur à exécuter, vous pouvez passer des options à l'interpréteur en les spécifiant sur la ligne shebang. Je trouve utile de garder une ligne shebang générique dans les scripts ponctuels (comme ceux que j'écris lorsque je réponds à des questions sur SO), afin de pouvoir les tester rapidement à la fois sur Windows et sur ArchLinux .

El env. utilitaire permet d'invoquer une commande sur le chemin :

Le premier argument restant spécifie le nom du programme à invoquer ; il est recherché en fonction de l'option PATH variable d'environnement. Tous les arguments restants sont passés comme arguments à ce programme.

Answer 3

En développant un peu les autres réponses, voici un petit exemple de la façon dont votre ligne de commande scripts peut se mettre en difficulté par une utilisation imprudente de /usr/bin/env les lignes du shebang :

$ /usr/local/bin/python -V
Python 2.6.4
$ /usr/bin/python -V
Python 2.5.1
$ cat my_script.py 
#!/usr/bin/env python
import json
print "hello, json"
$ PATH=/usr/local/bin:/usr/bin
$ ./my_script.py 
hello, json
$ PATH=/usr/bin:/usr/local/bin
$ ./my_script.py 
Traceback (most recent call last):
  File "./my_script.py", line 2, in <module>
    import json
ImportError: No module named json

Le module json n'existe pas dans Python 2.5.

Une façon de se prémunir contre ce genre de problème est d'utiliser les noms de commandes python versionnés qui sont généralement installés avec la plupart des Python :

$ cat my_script.py 
#!/usr/bin/env python2.6
import json
print "hello, json"

Si vous avez simplement besoin de faire la distinction entre Python 2.x et Python 3.x, les versions récentes de Python 3 fournissent également une fonction python3 nom :

$ cat my_script.py 
#!/usr/bin/env python3
import json
print("hello, json")

Answer 4

Afin d'exécuter le script de python, nous devons dire trois choses au shell :

1. Que le fichier est un script.
2. Quel interpréteur nous voulons pour exécuter le script.
3. Le chemin dudit interprète

L'ensemble #! accomplit (1.). Le tout commence par un # parce que le # est un marqueur de commentaire dans de nombreux langages de script. Le contenu de la ligne shebang est donc automatiquement ignoré par l'interpréteur.

El env permet de réaliser (2.) et (3.). Pour citation "grawity,"

Une utilisation courante de la env est de lancer les interprètes, en faisant en profitant du fait que env cherchera dans $PATH la commande qu'on lui demande de de lancer. Puisque la ligne shebang requiert la spécification d'un chemin absolu absolu, et que l'emplacement des différents interpréteurs (perl, bash, python) peut varier beaucoup, il est courant d'utiliser :

#!/usr/bin/env perl   au lieu d'essayer de deviner si c'est /bin/perl, /usr/bin/perl, /usr/local/bin/perl, /usr/local/pkg/perl, /fileserver/usr/bin/perl, ou /home/MrDaniel/usr/bin/perl sur le système de l'utilisateur de l'utilisateur...

D'un autre côté, env est presque toujours dans /usr/bin/env (sauf dans les cas où il ne l'est pas. cas où il ne l'est pas ; certains systèmes peuvent utiliser /bin/env, mais c'est une assez rare et n'arrive que sur les systèmes non-Linux).

Answer 5

La principale raison de faire cela est de rendre le script portable à travers les environnements de système d'exploitation.

Par exemple sous mingw, python scripts utiliser :

#!/c/python3k/python 

et sous la distribution GNU/Linux c'est soit :

#!/usr/local/bin/python 

ou

#!/usr/bin/python

et sous le meilleur système commercial Unix sw/hw de tous (OS/X), il l'est :

#!/Applications/MacPython 2.5/python

ou sur FreeBSD :

#!/usr/local/bin/python

Cependant toutes ces différences peuvent rendre le script portable à travers tous en utilisant :

#!/usr/bin/env python