#!Линия используется , прежде чем скрипт запускается, то игнорируется при выполнении сценария.
Вы спрашиваете, в чем разница между строкой Шебанга и обычным комментарием.
Строка, начинающаяся с #!такого же комментария, как и любая другая строка, начинающаяся с #. Это верно, если #!первая строка файла или где-либо еще. #!/bin/sh имеет эффект , но он не читается самим переводчиком .
#это не комментарий во всех языках программирования, но, как вы знаете, это комментарий в оболочках в стиле Борна, включая shи bash(а также в большинстве оболочек не в стиле Борна, например csh). Это также комментарий в Python . И это комментарий в различных конфигурационных файлах, которые вообще не являются сценариями (например /etc/fstab).
Предположим, что сценарий оболочки начинается с #!/bin/sh. Это комментарий, и интерпретатор (оболочка) игнорирует все в строке после #символа.
Цель #!строки - не предоставлять информацию переводчику. Цель этой #!строки - сообщить операционной системе (или какому-либо процессу, запускающему интерпретатор), что использовать в качестве интерпретатора .
Если вы вызываете сценарий как исполняемый файл, например, запустив его ./script.sh, система обращается к первой строке, чтобы узнать, начинается ли с #!нее, после которой идет ноль или более пробелов, после чего следует команда. Если это так, он запускает эту команду с именем сценария в качестве аргумента. В этом примере он запускается /bin/sh script.sh(или, технически, /bin/sh ./script.sh).
Если вы вызываете сценарий, явно вызывая интерпретатор, к #!строке никогда не обращаются. Так что, если вы запустите sh script.sh, первая строка не имеет никакого эффекта. Если script2.shпервая строка #!/usr/games/nibbles, запуск sh script2.shне будет пытаться открыть скрипт nibbles(но ./script2.shбудет).
Вы заметите, что ни в том, ни в другом случае расширение скрипта ( .sh), если оно есть, не влияет на его выполнение. В Unix-подобных системах это обычно не влияет на работу скрипта. В некоторых других системах, таких как Windows, система #!может полностью игнорировать строку shebang, и расширение может определять, какие сценарии выполняются. (Это не означает, что вам нужно давать расширения для скриптов, но это одна из причин, почему, если вы это сделаете, они должны быть правильными.)
#!был выбран для этой цели именно потому, что # начинается комментарий. #!Линия для системы, а не переводчик, и он должен быть проигнорирован интерпретатором.
Линия Shebang для сценариев Bash
Вы (изначально) сказали, что используете #!/bin/shдля bashсценариев. Вы должны делать это только в том случае, если сценарий не требует каких-либо bashрасширений - shдолжен иметь возможность запускать сценарий. shне всегда символическая ссылка на bash. Зачастую, в том числе во всех удаленно современных системах Debian и Ubuntu , shесть символическая ссылка на dash.
Линия Шебанга для скриптов Python
Вы также сказали (в первой версии вашего вопроса, перед редактированием), что запускаете свои скрипты Python #!/bin/sh read by the interpretor. Если вы имеете это в виду буквально, то вам определенно следует прекратить это делать. Если hello.pyначинается с этой строки, выполняется ./hello.pyrun:
/bin/sh read by the interpretor hello.py
/bin/shпопытается выполнить скрипт с именем read(в by the interpretor hello.pyкачестве аргумента), read(надеюсь) не будет найден, и ваш скрипт Python никогда не будет виден интерпретатором Python.
Если вы делаете эту ошибку, но у меня нет проблемы, которую я описываю, вы, вероятно, вызываете свои скрипты Python, явно указывая интерпретатор (например, python hello.py), в результате чего первая строка игнорируется. Когда вы распространяете свои сценарии среди других или используете их долгое время спустя, может быть неясно, что это необходимо для их работы. Лучше исправить это сейчас. Или, по крайней мере, удалите первую строку целиком, чтобы, когда они не запускаются, ./сообщение об ошибке имело смысл.
Для скриптов Python, если вы знаете, где находится (или будет) интерпретатор Python, вы можете написать #!строку так же:
#!/usr/bin/python
Или, если это скрипт на Python 3, вы должны указать python3, так как pythonэто почти всегда Python 2 :
#!/usr/bin/python3
Однако проблема заключается в том, что, хотя /bin/shпредполагается, что он всегда существует и /bin/bashпочти всегда существует в системах, где bashпоставляется ОС, Python может существовать в разных местах.
Поэтому многие программисты Python используют это вместо:
#!/usr/bin/env python
(Или #!/usr/bin/env python3для Python 3.)
Это заставляет сценарий полагаться на то, envчтобы быть в «правильном месте» вместо того, чтобы полагаться на то, pythonчтобы быть в правильном месте. Это хорошо, потому что:
envпочти всегда находится в /usr/bin.- В большинстве систем ваш скрипт
python должен запускаться первым PATH. Начиная hello.pyс #!/usr/bin/env pythonmake ./hello.pyrun /usr/bin/env python hello.py, что (практически) эквивалентно запуску python hello.py.
Причина, по которой вы не можете использовать #!pythonэто:
- Вы хотите, чтобы указанный интерпретатор был задан абсолютным путем (т. Е. Начиная с
/).
- Вызывающий процесс будет выполняться
python в текущем каталоге . Поиск пути, когда команда не содержит косой черты, является специфическим поведением оболочки.
Иногда Python или другой сценарий, который не является сценарием оболочки, будет содержать строку shebang, начинающуюся с #!/bin/sh ...где- ...то другого кода. Иногда это правильно, потому что есть несколько способов вызвать Bourne-совместимую оболочку ( sh) с аргументами, чтобы заставить ее вызывать интерпретатор Python. (Один из аргументов, вероятно, будет содержать python.) Однако для большинства целей #!/usr/bin/env pythonон проще, элегантнее и с большей вероятностью будет работать так, как вы хотите.
Линии Шебанга на других языках
Многие языки программирования и сценариев, а также некоторые другие форматы файлов используют #в качестве комментариев. Для любого из них файл на языке может быть запущен программой, которая принимает его в качестве аргумента, указав программу в первой строке после #!.
В некоторых языках программирования #это обычно не комментарий, но в особом случае первая строка игнорируется, если начинается с #!. Это облегчает использование #!синтаксиса, хотя в #противном случае не делает строку комментарием.
Строки Shebang для файлов, которые не запускаются как сценарии
Хотя он менее интуитивен, любой файл, формат файла которого может вместить первую строку, начинающуюся с #!полного пути исполняемого файла, может иметь строку shebang. Если вы сделаете это, и файл будет помечен как исполняемый, то вы можете запустить его как программу ... вызывая его открытие как документ.
Некоторые приложения используют это поведение намеренно. Например, в VMware .vmxфайлы определяют виртуальные машины. Вы можете «запустить» виртуальную машину, как если бы это был скрипт, потому что эти файлы помечены как исполняемые и имеют строку shebang, вызывающую их открытие в утилите VMware.
Линии Shebang для файлов, которые не работают как скрипты, но в любом случае действуют как скрипты
rmудаляет файлы Это не язык сценариев. Однако файл, который запускается #!/bin/rmи помечается как исполняемый, может быть запущен, и при запуске он rmвызывается для него, удаляя его.
Это часто концептуализируется как «файл удаляет сам себя». Но файл на самом деле не работает. Это больше похоже на ситуацию, описанную выше для .vmxфайлов.
Тем не менее, поскольку #!строка облегчает выполнение простой команды (включая аргументы командной строки), вы можете выполнить некоторые сценарии таким образом. В качестве простого примера более сложного «сценария» #!/bin/rmрассмотрим:
#!/usr/bin/env tee -a
Это принимает пользовательский ввод в интерактивном режиме, выводит его обратно пользователю построчно и добавляет его в конец файла «script».
Полезно? Не очень. Концептуально интересно? Полностью! Да. (В некотором роде.)
Концептуально похожие концепции программирования / написания сценариев (просто для удовольствия)
Скрипты / программы на нескольких языках одновременно , например, для имитации функциональности hashbang в ОС, в которых ее нет .
(Эти программы называются полиглоты , но это не следует путать с другим смыслом полиглота в разработке программного обеспечения , программы / проекта, где разные части написаны на разных языках.)
Метакоманды в QBasic / QuickBASIC, которые сообщали компилятору (для скомпилированного кода) опции для генерации кода, но были частью комментариев и, таким образом, игнорировались при фактической компиляции / интерпретации.
#include. Там тоже#не подразумевается как комментарий.