При написании сценариев какая разница между #! / Usr / bin / perl и #! / Usr / bin / env perl? - PullRequest
Новая
       15

При написании сценариев какая разница между #! / Usr / bin / perl и #! / Usr / bin / env perl?

8 голосов
/ 30 сентября 2011

Очевидно, что это в равной степени относится к python, bash, sh и т. Д., Заменяющим perl!

Ответ Квентина, приведенный ниже, был явно правильным, и поэтому я принял его, но я думаю, что на самом деле я имел в виду «чтоплюсы и минусы двух способов использования #!вызвать perl / python / bash как интерпретатор скрипта? '

Ответы [ 4 ]

9 голосов
/ 30 сентября 2011

Один ссылается на общее место, где установлен Perl.Другой ссылается на общее место, где установлен env, и спрашивает, каков путь к стандартному perl.

7 голосов
/ 30 сентября 2011

Это хорошие правила, если у вас есть веская причина нарушить их, не стесняйтесь делать это:

Используйте #!/usr/bin/env perl, где это возможно, для переносимости между гетерогенными системами.Но это глупый способ сделать это, потому что он предполагает, что Perl, который является первым в пути, также является Perl, который вы всегда хотите.Это может быть не так, и обычно, когда в системе есть несколько Perls, они по какой-то причине присутствуют.

Лучшим подходом является упаковка сценариев в дистрибутив с поддержкой CPAN.Распределите дистрибутивы по системам, где вы хотите их установить, и установите их обычным способом (вручную или с помощью цепочки инструментов CPAN), указав , указав полный путь от до perl или cpan.Во время этого процесса строка Шебанга переписывается в правильный путь к Perl.

Примеры: 

tar -xvf Local-OurCompany-Scripts-1.000.tar.gz
cd Local-OurCompany-Scripts-1.000

## automated installation
/usr/bin/cpan .
# or perhaps
/opt/ourcompany/perls/perl-5.14.2/bin/cpan .

## manual installation
/usr/bin/perl Makefile.PL ; make ; make install
# or perhaps
`which perl5.14.2` Makefile.PL ; make ; make install
3 голосов
/ 30 сентября 2011

Использование env для поиска исполняемого файла, вместо того, чтобы находить его самостоятельно, делает дополнительный exec, но это не должно иметь большого значения в большинстве случаев.Это удобно, и я часто использую его сам.

Однако у меня были проблемы с людьми, использующими env в системных скриптах. Однажды установка /usr/local/bin/perl сломала мою систему, и я больше не мог ее обновлять, пока не решу проблему. В другой раз установка /usr/local/bin/python сломала тэгер ID3, который я использовал.Я думаю, что это скорее проблема упаковки, чем внутренняя проблема с env.Если вы устанавливаете что-то в систему, почему вы тщательно проверяете, что она имеет версию Python, которая удовлетворяет всем вашим зависимостям, если вы просто собираетесь оставить строку shebang, которая каждый раз выискивает любую старую версию Pythonон запущен?

1 голос
/ 30 сентября 2011

Я могу привести конкретный пример:

Представьте, что у вас установлен пакет LAMP в / opt / (то есть XAMPP), который включает в себя собственный исполняемый файл perl, библиотеки и менеджер пакетов.

Вы действительно хотите запустить этот исполняемый файл, поэтому вы добавляете путь к исполняемым файлам LAMP в переменной среды PATH (PATH = "/ opt / XAMPP / bin: $ PATH").

Теперь любой сценарий, который использует "#! / usr / bin / env perl "выполнит двоичный файл perl в каталоге стека LAMP.Другой путь выполнит предустановленный двоичный файл perl в вашей системе, в "/usr/bin/perl".

Вам решать, что лучше для вашего сценария perl.

...