Чи слід ставити #! (shebang) в сценаріях Python, і в якій формі він повинен мати?

Чи слід вводити шебанг у свої сценарії Python? У якій формі?

#!/usr/bin/env python 

або

#!/usr/local/bin/python

Вони однаково портативні? Яка форма використовується найбільше?

Примітка: смерч проект використовує хатину. З іншого боку,проект Django не робить.

Рядок shebang у будь-якому сценарії визначає здатність сценарію виконуватись як окремий виконуваний файл, не вводячи pythonпопередньо термінал або двічі клацнувши його у файловому менеджері (при правильному налаштуванні). Це не обов'язково, але, як правило, ставлять його так, коли хтось бачить файл, відкритий у редакторі, він одразу знає, на що дивиться. Тим НЕ менше, що притон лінія використовується IS важливо.

Правильне використання сценаріїв Python 3:

#!/usr/bin/env python3

Це за замовчуванням версія 3.latest. Для Python 2.7. останнє використання python2замість python3.

Наступне НЕ слід використовувати (за винятком рідкісного випадку, коли ви пишете код, сумісний як з Python 2.x, так і з 3.x):

#!/usr/bin/env python

Причина цих рекомендацій, наведена в PEP 394 , полягає в тому, що вони pythonможуть посилатися на різні системи python2або python3на них. В даний час це стосується python2більшості дистрибутивів, але це, можливо, зміниться в якийсь момент.

Також НЕ використовуйте:

#!/usr/local/bin/python

"python може бути встановлений у / usr / bin / python або / bin / python у цих випадках, вищезазначений #! не вдасться."

- "#! / usr / bin / env python" vs "#! / usr / local / bin / python"

Це справді лише питання смаку. Додавання shebang означає, що люди можуть звертатися безпосередньо до сценарію, якщо вони хочуть (припустимо, що він позначений як виконуваний); опускати це просто означає python, що потрібно викликати вручну.

На кінцевий результат запуску програми жодним чином не впливає; це лише варіанти засобів.

Чи слід вводити шебанг у свої сценарії Python?

Вставте шебанг в сценарій Python, щоб вказати:

• цей модуль можна запустити як сценарій
• чи можна це запускати лише на python2, python3 чи сумісний Python 2/3
• на POSIX, це необхідно, якщо ви хочете запустити сценарій безпосередньо, не викликаючи pythonявно виконуваний файл

Вони однаково портативні? Яка форма використовується найбільше?

Якщо ви пишете шебанг вручну, тоді завжди використовуйте, #!/usr/bin/env pythonякщо у вас немає конкретної причини не використовувати його. Ця форма зрозуміла навіть у Windows (Python launcher).

Примітка: встановлені сценарії повинні використовувати певний виконуваний файл python, наприклад, /usr/bin/pythonабо /home/me/.virtualenvs/project/bin/python. Погано, якщо якийсь інструмент зламається, якщо ви активуєте virtualenv у своїй оболонці. На щастя, правильний шебанг створюється автоматично у більшості випадків setuptoolsінструментами вашого пакета розповсюдження (або в Windows, setuptoolsможе генерувати .exeсценарії обгортки автоматично).

Іншими словами, якщо сценарій знаходиться в касі джерела, ви, ймовірно, побачите #!/usr/bin/env python. Якщо він встановлений, то shebang - це шлях до певного виконуваного python, такого як #!/usr/local/bin/python (ПРИМІТКА: шляхи з останньої категорії не слід писати вручну).

Для того, щоб вибрати , чи слід використовувати python, python2або python3в кубло, см PEP 394 - The «пітон» Command на Unix-подібних системах :

• ... pythonслід використовувати в рядку shebang лише для скриптів, які є джерелом, сумісними як з Python 2, так і з 3.

• готуючись до можливої ​​зміни версії Python за замовчуванням, лише сценарії Python 2 повинні бути оновлені, щоб бути джерелом, сумісним з Python 3, або використовуватись python2у рядку shebang.

Якщо у вас є більше однієї версії Python, і сценарій потрібно запускати під певною версією, she-bang може забезпечити правильне використання правильного сценарію, наприклад:

#!/usr/bin/python2.7

Зверніть увагу, що сценарій все ще може бути запущений через повний командний рядок Python або через імпорт, і в цьому випадку she-bang ігнорується. Але для сценаріїв, які виконуються безпосередньо, це гідна причина використовувати she-bang.

#!/usr/bin/env python як правило, кращий підхід, але це допомагає в особливих випадках.

Зазвичай було б краще створити віртуальне середовище Python, і в цьому випадку загальний #!/usr/bin/env pythonідентифікував би вірний екземпляр Python для virtualenv.

Ви повинні додати шебанг, якщо сценарій призначений для виконання. Слід також встановити сценарій із встановленням програмного забезпечення, яке модифікує шебанг на щось правильне, щоб він працював на цільовій платформі. Прикладами цього є distutils і розподілити.

Призначення shebang полягає в тому, щоб скрипт розпізнав тип інтерпретатора, коли потрібно виконати сценарій з оболонки. Переважно, і не завжди, ви виконуєте сценарії, поставляючи інтерпретатор зовні. Приклад використання:python-x.x script.py

Це спрацює, навіть якщо у вас немає декларатора шебанга.

Чому перший варіант є більш "портативним", тому що він /usr/bin/envмістить вашу PATHдекларацію, яка враховує всі місця призначення, де розміщені ваші виконуючі системи.

ПРИМІТКА: Торнадо суворо не використовує шебангів, а Джанго суворо. Це залежить від того, як ви виконуєте основну функцію програми.

ТАКОЖ: Це не відрізняється від Python.

Іноді, якщо відповідь не дуже чіткий (я маю на увазі, ви не можете вирішити, чи так, ні), це не має великого значення, і ви можете ігнорувати проблему, поки відповідь не буде зрозумілою.

#!Єдина мета для запуску скрипта. Джанго завантажує джерела самостійно та використовує їх. Ніколи не потрібно вирішувати, який перекладач слід використовувати. Таким чином, #!насправді тут немає сенсу.

Як правило, якщо це модуль і не може бути використаний як сценарій, немає необхідності у використанні #!. З іншого боку, джерело модуля часто містить if __name__ == '__main__': ...принаймні деяку тривіальну перевірку функціональності. Тоді #!знову є сенс.

Однією з хороших причин використання #!є те, що ви використовуєте і сценарії Python 2, і Python 3 - вони повинні інтерпретуватися різними версіями Python. Таким чином, ви повинні пам'ятати, що pythonпотрібно використовувати при запуску сценарію вручну (без #!внутрішньої). Якщо у вас є суміш таких сценаріїв, добре використовувати #!внутрішній, зробити їх виконуваним і запустити їх як виконувані файли (chmod ...).

Під час використання MS-Windows #!сенсу не було - до недавнього часу. Python 3.3 представляє Windows Python Launcher (py.exe та pyw.exe), який читає #!рядок, виявляє встановлені версії Python та використовує правильну або явно потрібну версію Python. Оскільки розширення може бути пов’язане з програмою, ви можете отримати подібну поведінку в Windows, як з прапором виконання в системах на базі Unix.

Коли я нещодавно встановив Python 3.6.1 на Windows 7, він також встановив програму Python Launcher для Windows, яка повинна обробляти лінію shebang. Однак я виявив, що запуск Python не робив цього: рядок shebang була проігнорована і Python 2.7.13 завжди використовувався (якщо тільки я не виконав сценарій, використовуючи py -3).

Щоб виправити це, мені довелося відредагувати ключ реєстру Windows HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\open\command. Це все ще мало значення

"C:\Python27\python.exe" "%1" %*

з моєї попередньої установки Python 2.7. Я змінив це значення ключа реєстру на

"C:\Windows\py.exe" "%1" %*

і обробка лінії shebang запуску Python Launcher працювала, як описано вище.

Якщо у вас встановлені різні модулі та вам потрібно використовувати певну установку python, спочатку, здається, shebang обмежений. Однак ви можете робити хитрощі, як показано нижче, щоб дозволити спочатку викликати шебанг як сценарій оболонки, а потім вибрати пітон. Це дуже гнучкий imo:

#!/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 $PREFERRED_PYTHON
    exec $PREFERRED_PYTHON "$0" "$@"
elif [ -x $ALTERNATIVE_PYTHON ]; then
    echo Using alternative python $ALTERNATIVE_PYTHON
    exec $ALTERNATIVE_PYTHON "$0" "$@"
else
    echo Using fallback python $FALLBACK_PYTHON
    exec python3 "$0" "$@"
fi
exit 127
'''

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

Або ще краще, можливо, для полегшення повторного використання коду в декількох сценаріях python:

#!/bin/bash
"true" '''\'; source $(cd $(dirname ${BASH_SOURCE[@]}) &>/dev/null && pwd)/select.sh; exec $CHOSEN_PYTHON "$0" "$@"; exit 127; '''

а потім select.sh має:

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
    CHOSEN_PYTHON=$PREFERRED_PYTHON
elif [ -x $ALTERNATIVE_PYTHON ]; then
    CHOSEN_PYTHON=$ALTERNATIVE_PYTHON
else
    CHOSEN_PYTHON=$FALLBACK_PYTHON
fi

Відповідь: Тільки якщо ви плануєте зробити його скриптом для виконання командного рядка.

Ось процедура:

Почніть з перевірки правильного рядка shebang для використання:

which python

Візьміть висновок з цього і додайте його (з шебангом #!) У перший рядок.

У моїй системі він відповідає так:

$which python
/usr/bin/python

Так ваш шебанг буде виглядати так:

#!/usr/bin/python

Після збереження він буде працювати як і раніше, оскільки python побачить цей перший рядок як коментар.

python filename.py

Щоб зробити це командою, скопіюйте її, щоб скинути розширення .py.

cp filename.py filename

Скажіть файловій системі, що це буде виконується:

chmod +x filename

Щоб перевірити це, використовуйте:

./filename

Найкраща практика - перемістити його кудись у вашому $ PATH, тому все, що вам потрібно ввести, - це саме ім’я файлу.

sudo cp filename /usr/sbin

Таким чином він буде працювати всюди (без ./ перед назвою файлу)

Абсолютний проти логічного шляху:

Це справді питання про те, чи повинен шлях до інтерпретатора Python бути абсолютним або логічним ( /usr/bin/env) щодо переносимості.

Зустрічаючи інші відповіді на ці та інші сайтах Stack , які говорили про проблеми в загальному вигляді без підтримки доказів, я скоїв якийсь на насправді, дійсно , зернисте тестування & аналіз на цьому самому питання про unix.stackexchange.com . Замість того, щоб надіслати цю відповідь тут, я вкажу тих, хто цікавиться порівняльним аналізом, на цю відповідь:

https://unix.stackexchange.com/a/566019/334294

Будучи інженером Linux, моя мета - завжди забезпечити найбільш підходящі, оптимізовані хости для своїх клієнтів-розробників, тому питання середовищ Python було чимось, на що я справді потребував ґрунтовної відповіді. Моя думка після тестування полягала в тому, що логічний шлях у she-bang був кращим із (2) варіантів.

Використовуйте спочатку

which python

Це дасть вихід як місце, де присутній мій інтерпретатор пітонів (бінарний).

Цей вихід може бути будь-яким

/usr/bin/python

або

/bin/python

Тепер належним чином виберіть лінію shebang і використовуйте її.

Для узагальнення ми можемо використовувати:

#!/usr/bin/env

або

#!/bin/env