Блог

Главная - Вопросы по программированию - При написании сценариев, в чем разница между #!/usr/bin/perl и #!/usr/bin/env perl?

При написании сценариев, в чем разница между #!/usr/bin/perl и #!/usr/bin/env perl?

#perl #shell #shebang

#perl #оболочка #дело

Вопрос:

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

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

Комментарии:

1. Этот вопрос на самом деле не имеет никакого отношения к конкретным языкам сценариев, но я оставил его с пометкой perl, потому что это пример, используемый в названии.

Ответ №1:

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

Ответ №2:

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

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

Лучший подход — упаковывать скрипты в готовый к CPAN дистрибутив. Распределите дистрибутивы по системам, в которых вы хотите их установить, и установите их обычным способом (вручную или с помощью набора инструментов CPAN), указав полный путь к perl или cpan . Во время этого процесса строка shebang переписывается на правильный путь к 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

Комментарии:

1. Но вы забываете, что манипулировать путем легко — использование env позволяет использовать разные perls для разных программ (или даже одну и ту же программу в разное время). Использование жестко запрограммированного пути perl и возможности перезаписи пути CPAN предполагает, что perl, используемый для установки, — это тот perl, который вам всегда нужен, что, я бы сказал, является большим (и худшим) предположением, чем предположение, сделанное env , поскольку для его переопределения требуется изменение исходного кода, а не простое»ПУТЬ =/путь/ к/ другому / perl:$PATH some_perl.pl «.

2. Я согласен с этой частью: «Но это глупый способ сделать это, потому что предполагается, что Perl, который является первым в пути, также является тем Perl, который вам всегда нужен». и добавил бы, что предполагается, что ваш скрипт будет нормально работать с любым заданным экземпляром Perl (и Perl-Модули) он находит.

Ответ №3:

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

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

Комментарии:

1. Я не вижу причин env , по которым следует разветвлять другой процесс. Вы имели в виду «execs», или, альтернативно, вы не могли бы расширить тему?

Ответ №4:

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

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

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

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

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