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

我注意到，我从其他人那里获得的一些脚本具有shebang，#!/path/to/NAME而另一些（使用相同工具NAME）具有shebang #!/usr/bin/env NAME。

两者似乎都能正常工作。在教程中（例如，在Python上），似乎有人建议后者shebang更好。但是，我不太明白为什么会这样。

我意识到，要使用后一个shebang，NAME必须在PATH中，而第一个shebang没有此限制。

另外，对我来说，第一个似乎是更好的shebang，因为它精确指定了NAME的位置。因此，在这种情况下，如果存在多个版本的NAME（例如/ usr / bin / NAME，/ usr / local / bin / NAME），则第一种情况指定要使用的版本。

我的问题是，为什么第一个shebang优先于第二个？

不一定更好。

这样做的好处#!/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脚本。我使用安装程序脚本来修改#!每个脚本的行，因为该脚本会将其安装到我的计算机中$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有关详细信息）。

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

#!/usr/local/bin/python

仅当在/ usr / local / bin中安装了python时，才会运行脚本。

#!/usr/bin/env python

将解释您的内容$PATH，并在您目录中的任何目录中找到python $PATH。

所以，你的脚本更便于携带，且无需在哪里蟒蛇被安装为系统的修改就可以/usr/bin/python，或者/usr/local/bin/python，甚至是自定义目录（已加入$PATH），喜欢/opt/local/bin/python。

可移植性是使用env优先于硬编码路径的唯一原因。

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

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

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

除了之外/bin/sh，您唯一应该在shebang中使用绝对路径的时间是脚本不是可移植的，因此您可以依靠解释器的已知位置。例如，只能在Linux上运行的bash脚本可以安全使用#!/bin/bash。仅打算在内部使用的脚本可以依赖于内部解释器位置约定。

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

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

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

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

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

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

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

需要使用/usr/bin/env（如其他答案中所述，/usr/bin某些操作系统上没有此功能），因为您不能只是在可执行文件名的后面放置可执行文件名#!-它必须是绝对路径。这是因为该#!机制在比Shell更低的级别上起作用。它是内核二进制加载程序的一部分。可以测试。将其放在文件中并标记为可执行文件：

#!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。

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

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

   env是没有更多的保证是在/usr/bin/env比bash保证是在/bin/bash或在python /usr/bin/python。

2. env 用解释器的名称（例如bash或python）覆盖ARGV [0]。

   这样可以防止您的脚本名称出现在例如ps输出（或更改其显示方式/位置）中，并且无法通过以下方式找到它：ps -C scriptname.sh

[更新2016-06-04]

第三个问题：

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

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py

   将目录追加或预添加到$ PATH非常容易（尽管您仍然必须编辑文件以使其永久化-您~/.profile或其他人-而且编写脚本远非易事，因为PATH可以在脚本中的任何位置进行设置，不在第一行）。

   更改PATH目录的顺序要困难得多#!。

   而且您仍然遇到使用#!/usr/bin/env带来的所有其他问题。

   @jlliagre在评论中建议#!/usr/bin/env“通过仅更改其PATH / PATH顺序”对测试具有多个解释器版本的脚本很有用。

   如果您需要这样做，则#!在脚本顶部仅添加几行（除了第一行之外，它们只是在任何地方的注释），然后剪切/复制并粘贴您现在想要使用的那一行要容易得多。第一行。

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

总的来说，使用的优势#!/usr/bin/env充其量是最小的，甚至肯定无法抵消其劣势。甚至“便利”优势在很大程度上也是虚幻的。

IMO，这是一种特殊的程序员提倡的一个愚蠢的想法，他认为操作系统不是要使用的东西，而是要解决的问题（或者最好是忽略不计）。

PS：这是一个简单的脚本，可一次更改多个文件的解释器。

change-shebang.sh：

#!/bin/bash

interpreter="$1"
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 python2.7 *.py或change-shebang.sh $HOME/bin/my-experimental-ruby *.rb

在此处添加另一个示例：

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

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

env ruby --version

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

如果您纯粹是为自己或工作而写，而您要呼叫的口译员的位置始终在同一地方，则一定要使用直接路径。在所有其他情况下使用#!/usr/bin/env。

原因如下：在您的情况下，python无论您使用哪种语法，解释器都位于同一位置，但对于许多人来说，它可能已安装在其他位置。尽管大多数主要的程序解释器都位于/usr/bin/许多较新的软件中，但默认情况下为/usr/local/bin/。

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

出于便携性和兼容性的原因，最好使用

#!/usr/bin/env bash

代替

#!/usr/bin/bash

有很多可能，二进制文件可能位于Linux / Unix系统上。查看hier（7）联机帮助页以获取有关文件系统层次结构的详细说明。

例如，FreeBSD将所有软件（不是基本系统的一部分）安装在/ usr / local /中。由于bash不属于基本系统，因此bash二进制文件安装在/ usr / local / bin / bash上。

如果您想在大多数Linux发行版和FreeBSD下运行可移植的bash / csh / perl /任何脚本，则应使用＃！/ usr / bin / env。

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