"#!/ usr/bin/env bash"和"#!/ usr/bin/bash"有什么区别?

tar*_*lah 319 unix linux bash shell shebang

bash脚本的标题中,这两个语句之间的区别是什么?

  1. #!/usr/bin/env bash

  2. #!/usr/bin/bash

当我试图看到env手册页时,我得到了这个定义:

 env - run a program in a modified environment
Run Code Online (Sandbox Code Playgroud)

这是什么意思?

Ale*_*ett 284

通过运行一个命令/usr/bin/env有找不管程序的默认版本是在当前的利益ENV ironment.

这样,您不必在系统上的特定位置查找它,因为这些路径可能位于不同系统上的不同位置.只要它在你的道路上,它就会找到它.

一个缺点是,/usr/bin/env awk -f如果你想支持Linux,你将无法传递多个参数(例如,你将无法编写),因为POSIX对于如何解释该行是模糊的,并且Linux在第一个之后解释所有内容空间表示单个参数.您可以/usr/bin/env -S在某些版本上使用它env来解决这个问题,但随后脚本将变得更不便携,并在相当近期的系统上中断(例如,即使不是更晚的话,甚至是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
Run Code Online (Sandbox Code Playgroud)

在某些情况下,第一个可能是首选(如运行python脚本与多个版本的python,而不必重做可执行行).但是在以安全性为重点的情况下,后者将是首选,因为它限制了代码注入的可能性.

  • 另一个缺点是您无法将另一个参数传递给解释器. (21认同)
  • @GauravAgarwal:不在我的系统上.一个只包含这一行的脚本:`#!/ usr/bin/env echo Hello`抱怨:`/ usr/bin/env:echo Hello:没有这样的文件或目录`.显然它将`echo Hello`视为`/ usr/bin/env`的单个参数. (4认同)
  • @AndréLaszlo:`env` 命令当然允许将参数传递给命令。问题在于 `#!` 行的语义,这取决于内核。最近的 Linux 内核确实允许诸如 `#!/usr/bin/env command args` 之类的东西,但较旧的 Linux 内核和其他系统不允许。 (3认同)
  • @KeithThompson:信息不正确..您可以使用 /usr/bin/env 将选项传递给底层解释器! (2认同)

Dol*_*iac 54

使用#!/usr/bin/env NAME使shell在$ PATH环境变量中搜索NAME的第一个匹配项.如果您不知道绝对路径或不想搜索它,它会很有用.

  • 至少你必须知道env在哪里:). (8认同)
  • @EricKani:很可能您的“./script.sh”确实未选中其可执行标志(因此您无法自行执行它)。`"bash ./script.sh"` 愉快地接受不可执行的脚本文件。(解决方案:`chmod +x ./script.sh`) (3认同)
  • 优秀的答案。简洁地解释了 env shebang 的作用,而不是说“根据您的系统配置选择程序” (2认同)

Mec*_*cki 21

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

为什么这会有用?假设您要运行bash需要 bash 4.x 或更高版本的脚本,但您的系统仅bash安装了 3.x,并且目前您的发行版不提供更新版本,或者您不是管理员并且无法更改该系统上安装的内容.

当然,您可以下载 bash 源代码并从头开始构建自己的 bash ~/bin,例如将其放置到。您还可以修改文件中的$PATH变量以将.bash_profile其包含~/bin为第一个条目(PATH=$HOME/bin:$PATH因为~不会在 中扩展$PATH)。如果您现在调用bash,shell 将首先$PATH按顺序查找它,因此它以 开头~/bin,它将在其中找到您的bash. 如果脚本搜索bashusing #!/usr/bin/env 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,你就有大麻烦了。

例如,考虑一个工具创建一个~/.evil/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 "$@"
Run Code Online (Sandbox Code Playgroud)

让我们做一个简单的脚本sample.sh

#!/usr/bin/env bash

echo "Hello World"
Run Code Online (Sandbox Code Playgroud)

概念证明(在sudokeep的系统上$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 "$@"
Run Code Online (Sandbox Code Playgroud)

通常经典的 shell 都应该放在里面/bin,如果你不想把它们放在那里,无论出于什么原因,在/bin其中放置一个指向它们真实位置/bin的符号链接(或者它本身就是一个符号链接)真的不是问题,所以我总是和#!/bin/sh和一起去#!/bin/bash。如果这些不再起作用,就会有太多的东西会崩溃。并不是 POSIX 需要这些位置(POSIX 没有标准化路径名,因此它甚至根本没有标准化 shebang 功能)但是它们非常普遍,即使系统不提供/bin/sh,它可能仍然会理解#!/bin/sh并知道如何处理它,它可能只是为了与现有代码兼容。

但是对于更现代的、非标准的、可选的解释器,如 Perl、PHP、Python 或 Ruby,并没有真正指定它们应该位于的任何地方。它们可以是/usr/bin,但他们可能也处于/usr/local/bin或完全不同的层级分支(/opt/.../Applications/...,等)。这就是为什么这些经常使用#!/usr/bin/env xxxshebang 语法的原因。


saf*_*fay 11

/usr/bin/bash/通过使用env命令,不是通过使用env命令显式定义解释器的路径,而是从首次找到解释器的任何地方搜索和启动解释器.这有好处和缺点

  • “可以通过提供解释器的完整路径来指定解释器,而无需使用env。问题是,在不同的计算机系统上,确切路径可能不同。通过使用env,可以搜索解释器并将其定位在脚本运行的时间。这使脚本更易于移植,但也增加了选择错误解释器的风险,因为它会在可执行文件搜索路径中的每个目录中搜索匹配项。每台机器的环境二进制路径也可能不同。”-Wikipedia (2认同)