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