Что я должен использовать для строки хижины сценария Perl?
Какой из них лучше или быстрее для использования в качестве строки хижины для сценария Perl?
#! perl
#! perl.exe
#! fullpath/perl(/perl.exe)
#! partialpath/perl(/perl.exe)
И, при использовании #!perl, когда это работает над конкретной системой, как я узнаю в сценарии, какой интерпретатор жемчуга я использую так, я могу поместить тот в строку хижины?
И, при использовании a /path/path/perl, * или ... позволенный использоваться для папок?
5 ответов
Шутка Windows (выведенная из бита perl.exe ) кажется неуместной, поскольку ваша (кхм)" оболочка ", вероятно даже не анализирует его (поправьте меня, если я ошибаюсь, могло быть изменено в последнее время).
Некоторые флаги командной строки все еще могут быть уловлены самим Perl ( согласно этому потоку ).
Это одна из вещей, которые мне не нравятся в Perl .
В Windows, если вы используете по крайней мере ActiveState Perl, если файл заканчивается на .pl, то реестр Windows будет запускать интерпретатор Perl для вас, независимо от строки shebang. На Cygwin я не знаю почему, но #! perl тоже работает. В Unix вы должны указать полный путь к исполняемому файлу Perl в строке shebang. Идея Шверна об использовании env удобна, но имеет некоторую опасность, как я указал в комментарии.
Вот почему я предлагаю вам лучшее решение - упаковать ваши сценарии Perl в виде модулей CPAN . Установщики CPAN, такие как Module :: Build, затем изменят строку shebang на полный путь к вашему интерпретатору Perl. (Я не уверен, делает ли это установщик Schwern, ExtUtils :: MakeMaker, или использует env , поскольку я его не использую.)
Если вам нужно жестко закодировать #!, используйте #!/usr/bin/env perl. Зачем? Вы хотите, чтобы Perl-программа запускалась с предпочитаемым пользователем Perl. Он будет первым в их PATH. #!perl не делает того, что я имею в виду, он не ищет PATH пользователя, #!/usr/bin/env perl - вот как вы это сделаете. /usr/bin/env всегда будет там на Unix-системах.
Если пользователь использует Windows, как отмечали другие, это не имеет значения. Windows не использует #! она использует ассоциации расширений файлов. Убедитесь, что ваша программа называется foo.pl или как-то иначе, и все будет работать. Но строку #! все равно включите, так как некоторые утилиты и редакторы используют ее.
Если вы поставляете код, позвольте программе установки позаботиться об этом. И MakeMaker/Makefile.PL, и Module::Build/Build.PL изменят вашу строку #! так, чтобы она соответствовала тому perl, который пользователь использовал для установки. Они решат эту проблему за вас.
Если вы устанавливаете код для собственного производственного использования, вы должны использовать полный путь к определенной копии perl. Какой копии perl? К конкретной для вашего проекта. Значит ли это, что вам нужно компилировать perl для каждого проекта? Нет, вы можете сделать симлинк. Проект foo может иметь /usr/local/bin/fooperl, указывающий на /usr/bin/perl5.18. Use #!/usr/local/bin/fooperl. Теперь, если вы решите обновить perl, вы можете сделать это для каждого проекта, изменив симлинк.
И, при использовании "#! perl", когда он работает на определенной системе, что такое print() для показа полного пути к perl.exe, который может быть включен в строку Shebang?
Ну, если вы используете оператор print, вы уже выполняете код perl, так что...
Как отметил ChristopheD, я могу подтвердить из практики (ActivePerl на XP), что строка shebang не является действительно необходимой в Windows.
Строка shebang указывает оболочке Unix, какому интерпретатору передать сценарий.
В Windows программа, которой нужно передать сценарий, будет определена ассоциациями на основе расширения.
На Unix лучше всего использовать третий вариант (полный путь к
исполняемому файлу perl).И да, теоретически вы можете использовать "." (shell не волнует), но на самом деле вам не следует использовать относительный путь - вы никогда не знаете, каким будет ваш текущий рабочий каталог при выполнении скрипта.