通过/usr/bin/env运行命令的好处是它会在当前env环境中查找程序的默认版本，因此你不必在系统上特定的位置搜索它，由于这些路径在不同系统上可能位于不同的位置。只要它在你的路径中，就可以找到它。
其中一个缺点是如果你想支持Linux，你将无法传递多个参数（例如，你将无法编写/usr/bin/env awk -f），因为POSIX对如何解释这行的方式有歧义，而Linux将第一个空格后面的所有内容都解释为单个参数。你可以在某些版本的env上使用/usr/bin/env -S来解决这个问题，但脚本将变得更加不可移植，并且在相当新的系统上（例如，甚至是Ubuntu 16.04）也会出现问题。
另一个缺点是，由于你没有调用显式可执行文件，所以很容易出现错误，对于多用户系统来说还存在安全问题（例如，如果有人在你的路径中调用了名为bash的可执行文件）。
#!/usr/bin/env bash #lends you some flexibility on different systems
#!/usr/bin/bash #gives you explicit control on a given system of what executable is called
#!/usr/bin/env echo Hello会报错：/usr/bin/env: echo Hello: No such file or directory。显然，它将 echo Hello 视为 /usr/bin/env 的单个参数。 - Keith Thompsonenv命令确实允许将参数传递给命令。问题在于#!行的语义，这取决于内核。最近的Linux内核确实允许像#!/usr/bin/env command args这样的东西，但旧的Linux内核和其他系统则不行。 - Keith Thompson#!/usr/bin/env NAME可以使shell在$PATH环境变量中查找第一个匹配的NAME。如果您不知道绝对路径或不想搜索绝对路径，它可能会很有用。"./script.sh"没有被标记为可执行文件（因此你不能单独执行它）。"bash ./script.sh"可以愉快地接受非可执行脚本文件。（解决方案：chmod +x ./script.sh） - DevSolar#!/bin/bash作为shell脚本的开头，它们将始终在/bin中运行bash。但如果使用#!/usr/bin/env bash开始，它们会在$PATH中搜索bash，然后使用找到的第一个来启动。~/bin中。你还可以修改.bash_profile文件中的$PATH变量，将~/bin作为第一个条目（PATH=$HOME/bin:$PATH，因为~在$PATH中不会扩展）。现在，如果你调用bash，shell会首先按顺序在$PATH中查找，所以它会从~/bin开始，在那里能够找到你的bash。如果脚本使用#!/usr/bin/env bash搜索bash，则同样的事情会发生，因此这些脚本现在将使用你自定义的bash版本在你的系统上工作。env的最大缺点是某些系统仅允许一个参数，因此你不能这样做：#!/usr/bin/env <interpreter> <arg>，因为系统将把<interpreter> <arg>视为一个参数（它将像表达式被引用一样处理），因此env会搜索名为<interpreter> <arg>的解释器。请注意，这不是env命令本身的问题，因为它始终允许通过多个参数传递，但是系统的shebang解析器会在调用env之前解析该行。目前，这已在大多数系统上得到解决，但如果你的脚本想要超级可移植，你不能依赖于该问题已经在你将要运行的系统上得到解决。sudo没有配置为清理环境或者将$PATH排除在清理之外。举个例子：/bin是一个受保护的位置，只有root能够更改其中的内容。但你的主目录不是，任何你运行的程序都可以对其进行更改。这意味着恶意代码可以将一个虚假的bash放置到某个隐藏的目录中，并修改你的.bash_profile，将该目录包含在你的$PATH中，因此所有使用#!/usr/bin/env bash的脚本都会以该虚假的bash运行。如果sudo保留了$PATH，那#!/bin/bash
if [ $EUID -eq 0 ]; then
echo "All your base are belong to us..."
# We are root - do whatever you want to do
fi
/bin/bash "$@"
让我们编写一个简单的脚本sample.sh：
#!/usr/bin/env bash
echo "Hello World"
证明概念（在一个 sudo 保持 $PATH 的系统上）：
$ ./sample.sh
Hello World
$ sudo ./sample.sh
Hello World
$ export PATH="$HOME/.evil:$PATH"
$ ./sample.sh
Hello World
$ sudo ./sample.sh
All your base are belong to us...
Hello World
/bin，如果由于某种原因不想将它们放在那里，可以在/bin中放置指向其实际位置的符号链接（或者/bin本身就是一个符号链接），所以我总是使用#!/bin/sh和#!/bin/bash。如果这些东西不能工作，太多问题会出现。虽然POSIX不要求这些位置（POSIX不标准化路径名，因此根本不标准化shebang功能），但它们是如此常见，即使系统没有提供/bin/sh，它也可能仍然理解#!/bin/sh并且知道该做什么，甚至可能仅为了与现有代码兼容性。/usr/bin中，也可能在/usr/local/bin中，或者在完全不同的层次结构分支中（/opt/...，/Applications/...等）。这就是为什么它们经常使用#!/usr/bin/env xxx shebang语法的原因。. 是一个非常糟糕的做法。即使你将其放在 PATH 的最后一位，它以后可能不再是最后一位了。 - Anders与其明确定义解释器的路径，例如/usr/bin/bash/，使用env命令会在第一次发现它的位置搜索并启动解释器。 这种方法既有优点也有缺点。（了解更多）
type nodejs > scriptname.js #or any other environment
然后我在文件中修改了那一行变成了shebang。
我这样做是因为我不总记得nodejs在我的电脑上的位置是 /usr/bin/ 还是 /bin/，所以对我来说 env 非常有用。可能有细节需要注意，但这就是我的原因。
#!/usr/bin/bash可能无法正常工作。在我的系统（Ubuntu 17.04）上，bash是/bin/bash，而没有/usr/bin/bash。/bin和/usr/bin之间的区别在很大程度上是随意的。另外，大多数系统将env命令放在/usr/bin中，但这并不保证。 - Keith Thompson