Почему люди пишут #! / Usr / bin / env pybang в первой строке скрипта Python?

Это позволяет Вам выбирать исполняемый файл, который Вы хотите использовать; который очень удобен, если, возможно, Вы имеете несколько установок Python и различных модулей в каждом и хотите выбрать. например,

#!/bin/sh
#
# Choose the python we need. Explanation:
# a) '''\' translates to \ in shell, and starts a python multi-line string
# b) "" strings are treated as string concat by python, shell ignores them
# c) "true" command ignores its arguments
# c) exit before the ending ''' so the shell reads no further
# d) reset set docstrings to ignore the multiline comment code
#
"true" '''\'
PREFERRED_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python
ALTERNATIVE_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
FALLBACK_PYTHON=python3

if [ -x $PREFERRED_PYTHON ]; then
    echo Using preferred python $ALTERNATIVE_PYTHON
    exec $PREFERRED_PYTHON "[110]" "$@"
elif [ -x $ALTERNATIVE_PYTHON ]; then
    echo Using alternative python $ALTERNATIVE_PYTHON
    exec $ALTERNATIVE_PYTHON "[110]" "$@"
else
    echo Using fallback python $FALLBACK_PYTHON
    exec python3 "[110]" "$@"
fi
exit 127
'''

__doc__ = """What this file does"""
print(__doc__)
import platform
print(platform.python_version())

Если Вы - пользователь WebFaction, см. https://community.webfaction.com/questions/18791/why-can-my-virtualenv-still-see-system-site-packages

, Там глобальная политика настройки сайта в нашей системе установки Python, и virtualenv не может проигнорировать его.

Для работы вокруг этого можно создать пустой файл, названный sitecustomize.py в каталоге lib/python virtualenv.

Если у вас установлено несколько версий Python, / usr / bin / env гарантирует, что используемый интерпретатор будет первым в $ вашей среды. ПУТЬ .Альтернативой может быть жесткое кодирование чего-то вроде #! / Usr / bin / python ; это нормально, но менее гибко.

В Unix исполняемый файл, предназначенный для интерпретации, может указывать, какой интерпретатор использовать, имея #! в начале первой строки, за которым следует интерпретатор (и любые необходимые ему флаги).

Если вы говорите о других платформах, конечно, это правило не применяется (но эта «строка shebang» не причиняет вреда и поможет, если вы когда-нибудь скопируете этот сценарий на платформу с помощью база Unix, например Linux, Mac и т. д.).

Это называется линией шебанга . Как поясняется в статье Википедии :

В вычислениях, шебанг (также называемый хеш-бэнгом, хешэмплингом, фунт-бэнгом или кранчбэнгом) относится к символам "#!" когда они являются первыми двумя символами в директиве интерпретатора в качестве первой строки текстового файла. В Unix-подобной операционной системе загрузчик программы принимает присутствие этих двух символов как указание на то, что файл является сценарием, и пытается выполнить этот сценарий, используя интерпретатор, указанный в оставшейся части первой строки файла.

См. Также раздел часто задаваемых вопросов по Unix .

Даже в Windows, где строка shebang не определяет запускаемый интерпретатор, вы можете передать параметры интерпретатору, указав их в строке shebang. Я считаю полезным сохранить общую строку shebang в одноразовых сценариях (например, тех, которые я пишу, отвечая на вопросы по SO), чтобы я мог быстро протестировать их как в Windows, так и в ArchLinux .

Утилита env позволяет вызывать команду по пути:

Первый оставшийся аргумент указывает имя программы, которую нужно вызвать; он ищется в соответствии с переменной среды PATH . Любые оставшиеся аргументы передаются этой программе в качестве аргументов.

Это соглашение оболочки, которое сообщает оболочке, какая программа может выполнить сценарий.

#!/usr/bin/env python

преобразуется в путь к двоичному файлу Python.

Мне кажется, что файлы работают без этой строки одинаково.

Если да, то, возможно, вы запускаете программу Python в Windows? Windows не использует эту строку - вместо этого она использует расширение имени файла для запуска программы, связанной с расширением файла.

Однако в 2011 году была разработана «программа запуска Python» , которая (в некоторой степени) имитирует это поведение Linux для Windows. Это ограничено только выбором того, какой интерпретатор Python запускается - например, для выбора между Python 2 и Python 3 в системе, где оба установлены. Программа запуска дополнительно устанавливается как py.exe при установке Python и может быть связана с файлами .py , чтобы средство запуска проверило эту строку и, в свою очередь, запустило указанную версию интерпретатора Python. .

Немного расширяя другие ответы, вот небольшой пример того, как ваши сценарии командной строки могут столкнуться с проблемами из-за неосторожного использования / usr / bin / env строки 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

Модуль json не существует в Python 2.5.

Один из способов защититься от такого рода проблем - использовать имена команд Python с версией, которые обычно устанавливаются с большинством Python:

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

Если вам просто нужно различать Python 2.x и Python 3.x, последние выпуски Python 3 также предоставляет имя python3 :

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

Технически, в Python это просто строка комментария.

Эта строка используется, только если вы запускаете скрипт py из оболочки (из командной строки). Это известно как "Shebang!", и она используется в различных ситуациях, не только со сценариями Python.

Здесь он указывает оболочке запустить определенную версию Python (чтобы позаботиться об остальной части файла.