Warum schreibt man #!/usr/bin/env python in die erste Zeile eines Python-Skripts?

Question

Ich sehe dies am Anfang der Python-Dateien:

1. Für Python 2-Dateien

   #!/usr/bin/env python

2. Für Python 3-Dateien

   #!/usr/bin/env python3

Ich habe den Eindruck, dass die Dateien auch ohne diese Zeile funktionieren.

Answer 1

Es wird empfohlen und in der Dokumentation vorgeschlagen:

2.2.2. Ausführbare Python-Skripte

O ausführbar gemacht werden, wie Shell-Skripte, indem die Zeile

#! /usr/bin/env python3.2

von http://docs.python.org/py3k/tutorial/interpreter.html#executable-python-scripts

Answer 2

Sie gibt lediglich an, welchen Interpreter Sie verwenden möchten. Um dies zu verstehen, erstellen Sie eine Datei über das Terminal, indem Sie touch test.py und geben Sie dann in diese Datei Folgendes ein:

#!/usr/bin/env python3
print "test"

und tun chmod +x test.py um Ihr Skript ausführbar zu machen. Wenn Sie danach ./test.py sollten Sie eine Fehlermeldung erhalten:

  File "./test.py", line 2
    print "test"
               ^
SyntaxError: Missing parentheses in call to 'print'

weil Python 3 den Druckoperator nicht unterstützt.

Ändern Sie nun die erste Zeile Ihres Codes in:

#!/usr/bin/env python2

und es wird funktionieren, Drucken test nach stdout, da Python2 den Druckoperator unterstützt. So, jetzt haben Sie gelernt, wie man zwischen Skript-Interpretern umschaltet.

Answer 3

Sie können dieses Problem mit virtualenv versuchen

Hier ist test.py

#! /usr/bin/env python
import sys
print(sys.version)

Virtuelle Umgebungen erstellen

virtualenv test2.6 -p /usr/bin/python2.6
virtualenv test2.7 -p /usr/bin/python2.7

aktivieren Sie jede Umgebung und überprüfen Sie die Unterschiede

echo $PATH
./test.py

Answer 4

Ich habe den Eindruck, dass die Dateien auch ohne diese Zeile funktionieren.

Wenn ja, dann führen Sie das Python-Programm vielleicht unter Windows aus? Windows verwendet diese Zeile nicht. Stattdessen wird die Dateinamenerweiterung verwendet, um das mit der Dateierweiterung verbundene Programm auszuführen.

Allerdings im Jahr 2011, ein "Python-Startprogramm" entwickelt, das (bis zu einem gewissen Grad) dieses Linux-Verhalten für Windows nachahmt. Dies beschränkt sich auf die Auswahl, welcher Python-Interpreter ausgeführt wird - z.B. die Auswahl zwischen Python 2 und Python 3 auf einem System, auf dem beide installiert sind. Der Launcher wird optional installiert als py.exe durch die Python-Installation, und kann mit .py Dateien, damit der Launcher diese Zeile überprüft und die angegebene Python-Interpreter-Version startet.

Answer 5

Dies ist eher eine historische Information als eine "echte" Antwort.

Erinnern Sie sich daran, dass es früher viele Unix-ähnliche Betriebssysteme gab, deren Entwickler alle ihre eigene Vorstellung davon hatten, wo sie etwas hinpacken wollten, und die manchmal Python, Perl, Bash oder viele andere GNU/Open-Source-Sachen nicht enthielten überhaupt .

Dies galt sogar für verschiedene Linux-Distributionen. Unter Linux - vor FHS[1] - hatten Sie Python vielleicht in /usr/bin/ oder /usr/local/bin/. Oder es war nicht installiert, also haben Sie Ihr eigenes Programm gebaut und in ~/bin

Solaris war das Schlimmste, an dem ich je gearbeitet habe, zum Teil als Übergang von Berkeley Unix zu System V. Man konnte mit Dingen in /usr/, /usr/local/, /usr/ucb, /opt/ usw. enden. Das könnte für einige wirklich lange Wege. Ich kann mich daran erinnern, dass das Zeug von Sunfreeware.com jedes Paket in ein eigenes Verzeichnis installiert hat, aber ich kann mich nicht daran erinnern, ob es die Binärdateien in /usr/bin verlinkt hat oder nicht.

Oh, und manchmal lag /usr/bin auf einem NFS-Server[2].

Also die env wurde entwickelt, um dieses Problem zu umgehen.

Dann könnten Sie schreiben #!/bin/env interpreter und solange der Weg richtig war, hatten die Dinge einen vernünftig Chance zu laufen. Ja, natürlich, vernünftig bedeutete (für Python und Perl), dass Sie auch die entsprechenden Umgebungsvariablen gesetzt hatten. Für bash/ksh/zsh funktionierte es einfach.

Das war wichtig, weil die Leute Shell-Skripte (wie Perl und Python) weitergaben, und wenn Sie /usr/bin/python auf Ihrer Red Hat Linux-Workstation hart kodiert hatten, würde es auf einer SGI schlecht funktionieren... nun, nein, ich glaube, IRIX hat Python an die richtige Stelle gesetzt. Aber auf einer Sparc-Station läuft es vielleicht gar nicht.

Ich vermisse meine Sparc-Station. Aber nicht sehr. Ok, jetzt hast du mich dazu gebracht, bei E-Bay zu stöbern. Bastarde.

[1] Dateisystem-Hierarchienorm. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[2] Ja, und manchmal machen die Leute immer noch solche Sachen. Und nein, ich habe weder eine Rübe noch eine Zwiebel an meinem Gürtel getragen.