显然,这同样适用于替代 perl 的 python、bash、sh 等!
下面昆汀的回答显然是正确的,所以我接受了它,但我想我的真正意思是'两种使用方式的优缺点是什么!调用 perl/python/bash 作为脚本的解释器?
一个引用了安装 perl 的常见位置。另一个引用了一个安装 env 的公共位置,并询问它默认 perl 的路径是什么。
这些都是很好的规则,如果您有充分的理由打破它们,请不要犹豫:
尽可能用于#!/usr/bin/env perl
异构系统之间的可移植性。但这是一种愚蠢的做法,因为它假设路径中的第一个 Perl 也是您一直想要的 Perl。情况可能并非如此,而且通常当系统上有多个 Perls 时,它们的存在是出于某种原因。
更好的方法是将脚本打包到 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
使用env
查找可执行文件而不是自己查找可执行文件会执行额外的执行,但这在大多数情况下并不重要。很方便,我自己也经常用。
但是,我遇到了人们env
在系统脚本中使用的问题。有一次,安装一个/usr/local/bin/perl
损坏了我的系统,所以在我解决问题之前我无法更新它。在另一种情况下,安装了/usr/local/bin/python
我正在使用的 ID3 标记器。我认为这更像是一个包装问题,而不是env
. 如果您要在系统上安装某些东西,那么为什么要仔细检查它是否具有满足所有依赖项的 Python 版本,如果您只是要留下一条每次都在寻找任何旧版本 Python 的 shebang 行它运行了吗?
我可以给你一个具体的例子:
想象一下,您在 /opt/(即 XAMPP)中安装了一个 LAMP 包,其中包括它自己的 perl 可执行文件、库和包管理器。
您实际上想要运行该可执行文件,因此您在 PATH 环境变量 (PATH="/opt/XAMPP/bin:$PATH") 中添加 LAMP 可执行文件的路径。
现在,任何使用“#!/usr/bin/env perl”的脚本都将执行 LAMP 堆栈目录中的 perl 二进制文件。另一个路径将执行系统中预安装的 perl 二进制文件,位于“/usr/bin/perl”中。
由您决定什么对您的 perl 脚本更好。