为什么最好使用“＃！/ usr / bin / env名称”代替“＃！/ path / to / NAME”作为我的shebang？

#1 楼

客观标准/要求：
在确定在爆炸中使用解释器的绝对路径还是逻辑路径（/usr/bin/env）时，有（2）个关键注意事项：
a）可以找到解释器在目标系统上
b）可以在目标系统上找到正确的解释器版本
如果我们同意“ b）是可取的，我们还同意：
c）我们的脚本更可取失败而不是使用错误的解释器版本执行，并且可能会导致不一致的结果。
如果我们不同意“ b）”的问题，那么找到的任何解释器就足够了。
测试：
自在she-bang中使用逻辑路径-到解释器的/usr/bin/env是最可扩展的解决方案，它允许相同的脚本在具有指向相同解释器的不同路径的目标主机上成功执行，我们将对其进行测试-由于Python的流行-查看其是否符合我们的标准。

/usr/bin/env是否居住在POPULAR（n还是“每个”）操作系统？是：


RHEL 7.5
Ubuntu 18.04
Raspbian 10（“ Buster”）
OSX 10.15.02


下面的Python脚本在测试过程中在虚拟信封的内部和外部（使用Pipenv）同时执行：

#!/usr/bin/env pythonX.x
import sys
print(sys.version)
print('Hello, world!')

脚本中的she-bang被所需的Python版本号所切换（全部安装在同一主机上）：


＃！/ usr / bin / env python2
＃！/ usr / bin / env python2.7
＃！/ usr / bin / env python3
＃！/ usr / bin / env python3.5
＃！/ usr / bin / env python3.6
＃！/ usr / bin / env python3.7



预期结果：print(sys.version) = env pythonX.x。每次使用不同的已安装Python版本执行./test1.py时，都会打印出she-bang中指定的正确版本。


测试注意事项：



测试仅限于Python
Perl：像Python一样-根据FHS，必须存在于/usr/bin中

我尚未尝试在每种可能的Linuxy / Unixy操作系统和每种操作系统的版本上进行所有可能的组合。

结论：
虽然#!/usr/bin/env python将使用第一个版本的Linux是正确的它在用户的Path中找到的Python，我们可以通过指定版本号（例如#!/usr/bin/env pythonX.x）来缓和此行为。实际上，开发人员并不关心哪个解释器是“第一个”的，他们关心的只是使用知道的代码与指定的解释器执行代码，以确保结果一致（无论文件系统中可能存在的位置）。 ..
就可移植性/灵活性而言，使用逻辑/usr/bin/env-而非绝对路径不仅符合我在不同版本的Python上进行测试的要求a），b）和c），而且还具有以下优点：即使它们在不同操作系统上的不同路径中，它们也将使用模糊逻辑查找相同的版本解释器。而且尽管大多数发行版都尊重FHS，但并非所有发行版都如此。
因此，如果二进制文件位于随后在shebang中指定的不同绝对路径中，则脚本将失败，同一脚本将使用逻辑路径SUCCEEDS，直到发现匹配，从而提供跨平台的更高可靠性和可扩展性。

#2 楼

它不一定更好。

#!/usr/bin/env python的优点是它将使用在用户python中首先出现的$PATH可执行文件。

#!/usr/bin/env python的缺点是它会请使用在用户python中首先出现的$PATH可执行文件。这意味着脚本的运行方式会有所不同，具体取决于运行它的人员。对于一个用户，它可能会使用与操作系统一起安装的/usr/bin/python。另外，它可能会使用无法正常工作的实验性/home/phred/bin/python。

如果仅在python中安装了/usr/local/bin，则在/usr/local/bin中没有$PATH的用户将无法使用运行脚本。 （在现代系统上可能不太可能，但是对于较晦涩的解释器来说很可能会发生。）

通过指定#!/usr/bin/python，您可以确切指定将使用哪个解释器在特定系统上运行脚本。

另一个潜在的问题是#!/usr/bin/env技巧不允许您将参数传递给解释器（脚本名称除外，该名称是隐式传递的）。这通常不是问题，但是可以。许多Perl脚本都是使用#!/usr/bin/perl -w编写的，但是如今推荐使用use warnings;替代。 Csh脚本应使用#!/bin/csh -f-但不建议首先使用csh脚本。但是可能还有其他示例。

我在个人源代码控制系统中有许多Perl脚本，当我在新系统上设置帐户时会安装这些Perl脚本。我使用一个安装程序脚本来修改每个脚本的#!行，因为它会将其安装在我的$HOME/bin中。 （最近我不需要使用#!/usr/bin/perl以外的任何东西；它可以追溯到默认情况下通常未安装Perl的时代。）

一个次要点：#!/usr/bin/env技巧可以说是对env命令的滥用，它最初旨在（顾名思义）用于在环境改变的情况下调用命令。此外，某些较旧的系统（如果我没记错的话，包括SunOS 4）在env中没有/usr/bin命令。这些都不大可能成为重大问题。 env确实以这种方式工作，许多脚本确实使用了#!/usr/bin/env技巧，并且操作系统提供程序不太可能采取任何措施来破坏它。如果您希望脚本在真正的旧系统上运行，则可能会出现问题，但是您仍然可能需要对其进行修改。

另一个可能的问题，（感谢Sopalajo de Arrierez提供了在注释中指出）是cron作业在受限的环境下运行。特别地，$PATH通常类似于/usr/bin:/bin。因此，即使包含解释器的目录恰好不在这些目录之一中，即使它位于用户外壳程序的默认$PATH中，也无法使用/usr/bin/env技巧。您可以指定确切路径，也可以在crontab中添加一行以设置$PATH（有关详细信息，请参见man 5 crontab）。

#3 楼

因为/ usr / bin / env可以解释您的$PATH，这使脚本更易于移植。 bin。

#!/usr/local/bin/python

将解释您的$PATH，并在$PATH的任何目录中找到python。可以在无需将python安装为/usr/bin/python或/usr/local/bin/python或什至是自定义目录（已添加到$PATH）的系统（如/opt/local/bin/python）上安装的系统上进行修改。硬编码路径。

#4 楼

在给定的系统上，指定绝对路径更为精确。缺点是它太精确了。假设您意识到Perl的系统安装对于脚本来说太旧了，而您想使用自己的脚本：那么您必须编辑脚本并将#!/usr/bin/perl更改为#!/home/myname/bin/perl。更糟糕的是，如果在某些计算机上的/usr/bin中有Perl，在其他计算机上的/usr/local/bin中有Perl，而在其他计算机上的/home/myname/bin/perl中有Perl，则必须维护三个单独的脚本副本，并在每台计算机上执行相应的脚本。

如果#!/usr/bin/env不好，则PATH会中断，但是几乎所有操作都会中断。尝试以错误的PATH进行操作很少有用，并且表明您对脚本所运行的系统了解得很少，因此无论如何您都不能依赖任何绝对路径。

有您可以依赖几乎所有unix变量的两个程序：/bin/sh和/usr/bin/env。一些晦涩且大多已淘汰的Unix变体具有/bin/env而没有/usr/bin/env，但是您不太可能遇到它们。正是由于在shebang中的广泛使用，现代系统才有/usr/bin/env。您可以依靠/usr/bin/env。

除了/bin/sh之外，唯一一次在shebang中使用绝对路径的情况是脚本不是可移植的，因此您可以依靠口译员的已知位置。例如，仅在Linux上运行的bash脚本可以安全地使用#!/bin/bash。仅用于内部的脚本可以依赖内部解释器的位置约定。

#!/usr/bin/env确实有缺点。它比指定绝对路径更灵活，但仍然需要知道解释器名称。有时您可能想运行不在$PATH中的解释器，例如在相对于脚本的位置中。在这种情况下，您通常可以制作一个可以由标准外壳程序和所需解释程序解释的多语言脚本。例如，要使Python 2脚本可移植到python是Python 3和python2是Python 2的系统以及python是Python 2和python2不存在的系统：

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "q4312078q" "$@"
else
  exec python "q4312078q" "$@"
fi
'''
# real Python script starts here
def …

#5 楼

专门针对perl，使用#!/usr/bin/env是一个坏主意，原因有两个。

首先，它不可移植。在某些晦涩的平台上，env不在/ usr / bin中。其次，正如基思·汤普森（Keith Thompson）所指出的那样，在shebang线上传递论点可能会造成麻烦。最大的可移植解决方案是：

#!/bin/sh
exec perl -x "q4312078q" "$@"
#!perl

有关其工作方式的详细信息，请参见'perldoc perlrun'及其有关-x参数的说明。

#6 楼

两者之间有区别的原因是因为脚本的执行方式。

由于需要，因此需要使用/usr/bin/env（在其他操作系统中，/usr/bin并不如此）。只需在#!后面放置一个可执行文件名称-它必须是绝对路径。这是因为#!机制的工作水平低于外壳程序。它是内核二进制加载程序的一部分。可以测试。将此文件放入文件中并标记为可执行文件：

#!bash

echo 'foo'

尝试运行该文件时，它会显示如下错误：

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

如果文件被标记为可执行文件并以#!开头，则内核（不了解$PATH或当前目录：这是用户权限概念）将使用以下命令查找文件绝对路径。因为使用绝对路径存在问题（如其他答案所述），所以有人想出了一个窍门：您可以运行/usr/bin/env（几乎总是在该位置）来使用$PATH进行运行。

#7 楼

使用#!/usr/bin/env还有两个问题



它不能解决为解释器指定完整路径的问题，它只是将其移至env。

env不能保证在/usr/bin/env中，而bash不能保证在/bin/bash或/usr/bin/python中可以保证python。解释器（例如bash或python）。

这样可以防止您的脚本名称出现在env输出（或更改其显示方式/位置）中，并且无法使用例如，ps


[更新2016-06-04]

第三个问题：



更改PATH不仅仅是编辑脚本的第一行，还需要更多的工作，尤其是在编写脚本时，这种编辑很简单。例如：

ps -C scriptname.sh

将目录追加或预先添加到$ PATH很容易（尽管您仍然需要编辑文件以使其永久化-printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py或其他任何东西-而且编写脚本很难编辑，因为PATH可以在脚本中的任何地方设置，而不是在第一行中设置。而且比编辑~/.profile行要困难得多。

您仍然遇到使用#!会给您带来的所有其他问题。

@jlliagre在评论中建议#!/usr/bin/env很有用要使用多种解释程序版本测试脚本，“只需更改PATH / PATH顺序”即可。

如果需要这样做，在脚本顶部仅添加几行#!/usr/bin/env会更容易（它们只是第一行以外的任何地方的注释），然后将您要使用的内容剪切/复制并粘贴到第一行。

在#!中，这就像将光标移动到所需的vi行，然后键入#!或dd1GP一样简单。即使使用与Y1GP一样琐碎的编辑器，使用鼠标进行复制和粘贴也要花费几秒钟。




总体而言，使用nano的优势充其量是最小的，而且当然甚至无法抵消弊端。甚至“便利”优势在很大程度上是虚幻的。

IMO，这是一种特殊的程序员提倡的愚蠢的想法，他们认为操作系统不是要使用的东西，而这是一个需要解决的问题PS：这是一个简单的脚本，可一次更改多个文件的解释器。

#!/usr/bin/env：

#!/bin/bash

interpreter=""
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

以change-shebang.sh或change-shebang.sh python2.7 *.py
的方式运行

#8 楼

在此处添加另一个示例：

例如，当您想在多个env环境之间共享脚本时，使用rvm也很有用。

在cmd行上运行此命令，显示哪个ruby版本将在脚本内使用#!/usr/bin/env ruby时使用：

env ruby --version

因此，当您使用env时，可以通过rvm使用不同的ruby版本，而无需更改脚本。 br />

#9 楼

如果您纯粹是为自己或工作而写，而您要呼叫的口译员的位置始终在同一地方，则一定要使用直接路径。在所有其他情况下，请使用#!/usr/bin/env。这是为什么：在您的情况下，无论您使用哪种语法，python解释器都位于同一位置，但对于许多人来说，它可能已安装在不同的位置。尽管大多数主要的程序解释器都位于/usr/bin/中，但是许多较新的软件默认为/usr/local/bin/。

我什至会争辩说总是使用#!/usr/bin/env，因为如果您安装了同一个解释器的多个版本，并且您不知道shell将默认使用什么版本，那么您应该应该对此进行修复。 >

#10 楼

出于可移植性和兼容性原因，最好使用

#!/usr/bin/env bash

而不是

#!/usr/bin/bash

有很多可能性，二进制文件可能位于Linux / Unix系统上。请查阅hier（7）联机帮助页以获取文件系统层次结构的详细说明。例如，FreeBSD将所有软件（不是基本系统的一部分）安装在/ usr / local /中。由于bash不属于基本系统，因此bash二进制文件安装在/ usr / local / bin / bash中。

当您需要可移植的bash / csh / perl /任何可运行的脚本时在大多数Linux发行版和FreeBSD中，您应该使用＃！/ usr / bin / env。

还要注意，大多数Linux安装也将环境二进制文件（硬）链接到/ bin / env或将/ usr / bin软链接到/ bin中，但不要在shebang中使用。所以不要使用＃！/ bin / env。