Какой тип пути в Шебанге является более предпочтительным?
В скриптах первая строка должна указывать путь к интерпретатору.
Но на разных серверах 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 &
Если вы не укажете никаких переменных среды или других параметров, она просто вызовет указанную команду. (Использование этого способа, вероятно, является чем-то вроде взлома.)
Цель написания shebang как
#!/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 впервые начал использовать тире, некоторые скрипты сломались. Об этом шла дискуссия.
Большинство скриптов были написаны #! / Bin / sh , который был ссылкой на / bin / bash.
Консенсус таков: автор сценария отвечает за определение интерпретатора.
Следовательно, если ваш сценарий всегда должен запускаться с помощью BASH, укажите его из среды. Это избавляет вас от необходимости угадывать путь, который отличается в разных системах Unix / Linux. Вдобавок это сработает, если завтра / bin / sh станет ссылкой на какую-нибудь другую оболочку, например / bin / wthsh, или на какую-нибудь другую ерунду.
К вашему сведению, это чушь #! , вам нужен # . Вы используете эту строку, чтобы определить, с каким интерпретатором запускать сценарий.
По умолчанию Ubuntu связывает / bin / sh с тире
В зависимости от того, сколько вы хотели бы знать о тире и почему тире используется для системных или демоновых оболочек, см .:
Страница руководства Ubuntu dash
Bash - это оболочка по умолчанию, используемая большинством пользователей Linux, и у нее другие функции, чем у dash. Сценарий, написанный для bash, может или не может работать должным образом, если он запускается с тире. Чем сложнее сценарий, тем меньше вероятность, что он будет запущен.
Сценарий, написанный для perl, python и т. Д., Вообще не будет работать с / bin / sh или / bin / bash .
Итак, когда вы пишете сценарий, вы определяете, какой интерпретатор следует использовать с shee-bang
Выбор того, что использовать, сделаны автором сценария, и один не лучше другого, все они имеют различные особенности, преимущества и недостатки.