perl - スクリプトを作成する場合、#!/usr/bin/perl と #!/usr/bin/env perl の違いは何ですか?

Question

明らかにこれは、perl の代わりに python、bash、sh などを使用しても同様に適用されます。

以下のクエンティンの答えは明らかに正しいので、私はそれを受け入れましたが、私が実際に意味したのは、「#! を使用する 2 つの方法の長所と短所は何ですか?」スクリプトのインタプリタとして perl/python/bash を起動するには?'

Answer 1

1 つは、perl がインストールされている共通の場所を参照します。もう 1 つは、env がインストールされている一般的な場所を参照し、デフォルトの perl へのパスを尋ねます。

Answer 2

これらは適切なルールです。破る正当な理由がある場合は、ためらわずに破ってください。

#!/usr/bin/env perl異種システム間の移植性のために、可能な場合に使用します。しかし、これはばかげた方法です。なぜなら、パスの最初にある Perl が常に必要な Perl でもあると仮定するからです。そうではないかもしれません。通常、システムに複数の Perl がある場合、それらは特定の理由で存在します。

より良いアプローチは、スクリプトを CPAN 対応のディストリビューションにパッケージ化することです。インストール先のシステムにディストリビューションを配布し、通常の方法 (手動または CPAN ツールチェーンを使用) で、またはへのフル パスを指定してインストールします。そのプロセス中に、シバン行はPerl への正しいパスに書き換えられます。perlcpan

例:

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

Answer 3

env自分で実行ファイルを見つけるのではなく、実行ファイルを見つけるためにを使用すると、追加の exec が実行されますが、ほとんどの場合、それは実際には問題になりません。便利で、私自身もよく利用しています。

envただし、システム スクリプトで使用している人々に問題がありました。ある時、インストール/usr/local/bin/perl中にシステムが壊れてしまい、問題を解決するまで更新できなくなりました。別の機会/usr/local/bin/pythonに、私が使用していたID3タガーをインストールすると壊れました。これは、固有の問題というよりは、パッケージングの問題だと思いますenv。システムに何かをインストールしている場合、毎回古いバージョンの Python を探し回るシバン行をそのままにしておくのに、すべての依存関係を満たす Python のバージョンがあることを注意深くチェックするのはなぜですか?それは実行されますか？

Answer 4

具体例を挙げることができます：

独自の perl 実行可能ファイル、ライブラリ、およびパッケージ マネージャを含む LAMP パッケージ (つまり XAMPP) が /opt/ にインストールされているとします。

実際にその実行可能ファイルを実行したいので、PATH 環境変数 (PATH="/opt/XAMPP/bin:$PATH") に LAMP 実行可能ファイルへのパスを追加します。

これで、「#!/usr/bin/env perl」を使用するスクリプトは、LAMP スタック ディレクトリで perl バイナリを実行します。もう 1 つのパスは、システムの「/usr/bin/perl」にプリインストールされた perl バイナリを実行します。

あなたの perl スクリプトにとって何が良いかを決めるのはあなた次第です。