“#有什么区别！/usr/bin/envbash”和“#！/usr/bin/bash”？

Question

在Bash脚本的头中，这两个语句之间有什么区别：

>

#！/usr/bin/envbash

#/usr/bin/bash

当我查阅env手册页时，我得到了以下定义：

 env - run a program in a modified environment

这是什么意思？




Answer 1

匿名用户

如果shell脚本以#开头/bin/bash，它们将始终与/bin中的bash一起运行。但是，如果它们以#开头/usr/bin/env bash，他们将在$PATH中搜索bash，然后从他们能找到的第一个开始。

为什么这会有用？假设您想要运行需要bash4的bash脚本。x或更高版本，但您的系统只有bash3。已安装x，但当前您的发行版不提供更新版本，或者您不是管理员，无法更改该系统上安装的内容。

当然，您可以下载bash源代码并从头开始构建自己的bash，例如将其放置到~/bin。您还可以在中修改$PATH变量。bash_profile文件以包含~/bin作为第一个条目（PATH=$HOME/bin:$PATHas~不会在$PATH中展开）。如果现在调用bash，shell将首先按顺序在$PATH中查找它，因此它以~/bin开头，在那里它将找到您的bash。如果脚本使用#搜索bash，也会发生同样的情况/usr/bin/env bash，因此这些脚本现在可以使用自定义的bash构建在您的系统上运行。

一个缺点是，这可能会导致意想不到的行为，例如，在同一台机器上运行相同的脚本可能会使用不同的解释器为不同的环境或具有不同搜索路径的用户运行，从而导致各种头痛。

env的最大缺点是，某些系统只允许一个参数，因此不能执行此操作/usr/bin/env

它甚至可能有安全隐患，例如，如果未将sudo配置为清理环境，或者$PATH被排除在清理之外。让我示范一下：

通常/bin是一个保护良好的地方，只有root能够更改那里的任何内容。但是，主目录不是您运行的任何程序都可以对其进行更改的。这意味着恶意代码可能会将一个假的bash放入某个隐藏目录，修改您的。bash_profile将该目录包括在$PATH中，因此所有脚本都使用#/usr/bin/env bash将以该伪bash结束运行。如果sudo保留$PATH，您就有大麻烦了。

例如，考虑一个工具创建一个文件~/. vil/bash，内容如下：

#!/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 "$@"

让我们制作一个简单的脚本示例。上海：

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

通常，经典shell都应该位于/bin中，如果出于任何原因不想将它们放在那里，那么在/bin中放置一个指向它们真实位置的符号链接（或者可能/bin本身就是一个符号链接）并不是一个问题，所以我总是选择\/bin/sh和#/bin/bash。如果这些都不起作用的话，会有太多的东西坏掉。并不是POSIX需要这些位置（POSIX没有标准化路径名，因此它甚至没有标准化shebang特性），而是它们非常常见，即使系统不提供/bin/sh，它也可能理解#/bin/sh并知道如何使用它，可能只是为了与现有代码兼容。

但是对于更现代的、非标准的可选解释器，如Perl、PHP、Python或Ruby，它并没有真正指定它们应该位于的任何地方。它们可能在/usr/bin中，但也可能在/usr/local/bin中，或者在完全不同的层次分支中（/ap/...，/应用程序/...，等等）。这就是为什么这些经常使用#！/usr/bin/envxxx的语法。

Answer 2

使用#/usr/bin/env NAME使shell在$PATH环境变量中搜索名称的第一个匹配项。如果您不知道绝对路径或不想搜索它，那么它可能很有用。

Answer 3

通过/usr/bin/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

在某些情况下，第一种可能是首选的（比如使用多个版本的python运行python脚本，而不必重新编写可执行行）。但在安全性是重点的情况下，后者将是首选，因为它限制了代码注入的可能性。