Какой тип пути в Шебанге является более предпочтительным?
В скриптах первая строка должна указывать путь к интерпретатору.
Но на разных серверах Linux, Unix или BSD этот путь может быть разным.
Что предпочтительнее?
#!/usr/bin/env bash
или же
#!/bin/bash
3 ответа
Если вы хотите использовать установленную системой версию данного интерпретатора, установленного в стандартном месте, используйте прямой путь. Если вы хотите использовать ту версию интерпретатора, которая появляется первой у пользователя $PATH использовать #!/usr/bin/env ...,
env Команда вызывает указанную команду, позволяя вам устанавливать или сбрасывать переменные окружения:
env FOO=BAR do-something
env DISPLAY=:0.0 xterm -ls &
Если вы не укажете какие-либо переменные окружения или другие параметры, он просто вызовет именованную команду. (Использовать его таким образом, возможно, немного хак.)
Цель написания Шебанга как
#!/usr/bin/env interp
это призвать что угодно interp появляется первым в $PATH,
Это означает, что вам не нужно знать при написании сценария, где именно interp есть (скажем, если это может быть в любом /bin, /usr/bin, или же /usr/local/bin). Конечно, вы должны знать, что env является /usr/bin/env, но это кажется достаточно универсальным.
Преимущество состоит в том, что он вызывает ту версию интерпретатора, которая появляется первой в пользовательском файле. $PATH, Недостатком является то, что он вызывает ту версию интерпретатора, которая появляется первой у пользователя. $PATH,
Например, предположим, что я установил личную сборку perl в моем домашнем каталоге, как $HOME/bin/perl, и я имею $HOME/bin в передней части моего $PATH, Если я запускаю скрипт, чей шебанг
#!/usr/bin/env perl
тогда он будет работать с моим собственным установленным perl исполняемый файл - что может быть не очень хорошо. Автор сценария, вероятно, не проверял его с использованием Perl, который я создал из исходного кода месяц назад.
Для чего-то вроде Perl или Bash, которые могут быть установлены в согласованном месте в большинстве систем (/usr/bin/perl а также /bin/bashсоответственно), я бы использовал прямой путь к команде. Для чего-то более неясного, что может быть установлено по-разному в разных системах, я бы использовал /usr/bin/env трюк, или я бы написал инсталлятор, который корректирует строку shebang по мере установки скрипта. (Раньше я делал это для моих скриптов Perl.)
ОБНОВЛЕНИЕ: В этом ответе на этот вопрос я подробно остановился на сайте Unix & Linux.
Лучшая практика заключается в следующем:
#!/usr/bin/env bash
#!/usr/bin/env sh
#!/usr/bin/env python
И так далее...
Когда Ubuntu впервые начал использовать dash, некоторые скрипты сломались. Об этом шла дискуссия. Большинство сценариев были написаны #!/bin/sh которая была ссылкой на / bin / bash. Согласие таково: автор сценария отвечает за указание интерпретатора. Поэтому, если ваш скрипт всегда должен вызываться с помощью BASH, укажите его из среды. Это избавляет вас от необходимости угадывать путь, который отличается в разных системах Unix/Linux. Кроме того, это будет работать, если завтра / bin / sh станет ссылкой на какую-то другую оболочку, например / bin / wthsh, или на какую-то другую неявку.
К вашему сведению, это трах #!вам нужно #, Вы используете эту строку, чтобы определить, с каким интерпретатором запускать скрипт.
По умолчанию ссылки на Ubuntu /bin/sh разбить
В зависимости от того, как много вы хотели бы узнать о dash и почему dash используется для системных оболочек или оболочек deamon, смотрите:
Страница справочника по Ubuntu
Bash является оболочкой по умолчанию, используемой большинством пользователей Linux, и имеет функции, отличные от dash. Сценарий, написанный для bash, может работать или не работать должным образом, если он запускается с помощью dash, чем сложнее скрипт, тем меньше вероятность его запуска.
Скрипт, написанный для Perl, Python и т. Д., Вообще не будет работать с /bin/sh или же /bin/bash,
Поэтому, когда вы пишете сценарий, вы определяете, какой интерпретатор следует использовать с ши-бен
Выбор того, что использовать, сделан автором сценария, и одно не лучше другого, все они имеют различные особенности, преимущества и недостатки.