Заголовок скрипта Python

79

Типичный заголовок должен быть 

#!/usr/bin/env python

Но я обнаружил, что ниже также работает при выполнении сценария, например $python ./my_script.py

#!/usr/bin/python
#!python

Какая разница между этими двумя заголовками? В чем может быть проблема для 2-го? Пожалуйста, также обсудите случай, когда интерпретатор python находится в PATH или нет. Благодарю.

python scripting Стэн
источник
3
этот заголовок называется Shebang en.wikipedia.org/wiki/Shebang_%28Unix%29
systempuntoout
4
К вашему сведению, когда вы запускаете скрипт таким образом $ python ./my_script.py(с pythonявным указанием ), #!строка shebang ( ) игнорируется. Он имеет эффект только в том случае, если вы запускаете скрипт как исполняемый файл, например $ ./my_script.py.
David Z
@ Давид Заславский: +1 Хороший улов.
Марк Байерс

Ответы:

103

Во-первых, каждый раз, когда вы запускаете скрипт с явным использованием интерпретатора, как в

$ python ./my_script.py
$ ksh ~/bin/redouble.sh
$ lua5.1 /usr/local/bin/osbf3

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

#!/usr/bin/env python

выполняет все, что pythonнаходится на пользователях $PATH. Эта форма устойчива к перемещению интерпретатора Python, что делает его несколько более переносимым, но это также означает, что пользователь может переопределить стандартный интерпретатор Python, поместив что-то перед ним $PATH. В зависимости от ваших целей такое поведение может быть нормальным, а может и нет.

Следующий,

#!/usr/bin/python

имеет дело с обычным случаем, в котором установлен интерпретатор Python /usr/bin. Если он установлен где-то еще, вы проиграете. Но это хороший способ убедиться, что вы получите именно ту версию, которую хотите, или вообще ничего (поведение "отказоустойчивое"), как в

#!/usr/bin/python2.5

В заключение,

#!python

работает только при наличии pythonисполняемого файла в текущем каталоге при запуске сценария. Не рекомендуется.

Норман Рэмси
источник
28


Я бы предложил 3 вещи в начале вашего скрипта:

Во-первых, как уже было сказано, используйте среду:

#!/usr/bin/env python

Во-вторых, установите кодировку:

# -*- coding: utf-8 -*-

В-третьих, установите некоторую строку документа:

"""This is a awesome
    python script!"""

И, конечно, я бы использовал " "(4 пробела) для идент.
Окончательный заголовок будет выглядеть так:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""This is a awesome
        python script!"""


С наилучшими пожеланиями и счастливого кодирования.

Димитар Атанасов
источник
Просто чтобы поддержать, казалось бы, самоуверенный комментарий о пробелах над табуляцией: «Пробелы - предпочтительный метод отступа». ( python.org/dev/peps/pep-0008/#tabs-or-spaces )
deepelement
5

Исполняемый файл Python может быть установлен в другом месте, кроме / usr / bin, но envпочти всегда присутствует в этом месте, поэтому его использование /usr/bin/envболее переносимо.

Марк Байерс
источник
2

Из справочной страницы для env(GNU coreutils 6.10):

env - run a program in a modified environment

Теоретически вы можете использовать envдля сброса среды (удаление многих из существующих переменных среды) или добавления дополнительных переменных среды в заголовок скрипта. На практике обе упомянутые вами версии идентичны. (Хотя другие отметили хороший момент: указание pythonдо envпозволяет абстрактно указать, pythonне зная его путь.)

Анника Бэкстрем
источник
1

Да, есть - python может не быть /usr/bin, но, например, в /usr/local/bin(BSD).

При использовании virtualenv это может быть что-то вроде ~/projects/env/bin/python

Алмад
источник
0

Это /usr/bin/env pythonстановится очень полезным, когда ваши сценарии зависят от настроек среды, например, используя сценарии, которые полагаются на python virtualenv. Каждый virtualenv имеет свою собственную версию двоичного файла python, которая требуется для добавления пакетов, установленных в virtualenv, в путь Python (не касаясь PYTHONPATH env).

Поскольку все больше и больше людей начинают использовать virtualenv для разработки на Python, предпочитают использовать, /usr/bin/env pythonесли вы не хотите, чтобы люди использовали свой собственный двоичный файл Python.

Примечание. Вы также должны понимать, что существуют потенциальные проблемы безопасности (в многопользовательских средах), когда вы позволяете людям запускать ваши сценарии в их пользовательских средах. Вы можете почерпнуть некоторые идеи отсюда .

Джатин Кумар
источник