在我见过的大多数shell脚本中（除了我自己没有写过的脚本之外），我注意到shebang设置为#!/bin/sh。对于旧的脚本，这并不令我感到意外，但是在相当新的脚本中也是如此。

是否有理由宁愿使用/bin/shover /bin/bash，因为bash在十年前的许多Linux和BSD机器上，它普遍存在并且通常是默认的吗？

1. 有些系统默认情况下不运送bash（例如FreeBSD）。
2. 即使已安装bash，它也可能不在中/bin。
3. 大多数简单的脚本不需要bash。
4. 使用POSIX shell更可移植，脚本可以在多种系统上运行。

Linux（与Debian有关：Ubuntu，Mint等）中的大多数系统脚本都编写为以更快的破折号运行，破折号是这些系统中的默认/ bin / sh。原因是双重的：

• 系统速度。较小的破折号代码加载速度更快，运行速度也更快。用一些（小的？）额外的努力（成本）给shell脚本的程序员。

• 安全。外壳的多样性有助于抵御错误。Debian系统大多不容易受到shellshock的攻击，因为默认的shell没有这样的漏洞。

Bash确实是用户的默认外壳程序，因为它功能更强大，并且具有更多的元素来简化编码。sh在Mac OS中，它也是默认值（从/ bin / sh链接的一个）。但是，bash使用链接名称of sh进行调用会使它以与posix兼容的外壳开始。

其他人指出，问题的前提是Bourne Again外壳是默认的并且无处不在，这是完全错误的。

除此之外，确实有充分的理由使用Bourne Again shell之外的其他东西来解释shell脚本。这些原因促使Ubuntu和Debian的大型项目在过去的几年中消除了Bashisms，并使许多shell脚本通过系统初始化运行（System 5中有很多 Shell脚本rc），并且软件包安装/删除使用了Debian Almquist外壳，而不是Bourne Again外壳。

简而言之：Bourne Again shell本身就充满了交互式功能，对于符合POSIX的shell脚本而言，它并不是最快的shell解释器。因此，如果可以使自己的shell脚本符合POSIX，并使用更轻量级的程序（例如Debian Almquist shell）对其进行解释，则系统的性能将更好。（最后，Debian必须对Almquist shell进行些微调整，以增加对几个非POSIX shell结构的支持，这些结构太深，太广泛地嵌入并且太有用了以至于无法摆脱。）

这一切的结果是大大提高了引导程序性能。

因此，这里要考虑两种不同的外壳类别：

• 具有所有出色交互功能的外壳，这些功能被配置为帐户数据库中用户的交互式登录外壳。
• 快速解释大量脚本的shell，shell脚本程序将其用作脚本解释器。

请注意，将其称为“首选/bin/sh”过于简单了。Debian实际上至少有两个目标：

1. 面对使用Debian Almquist Shell，Z Shell（处于POSIX模式），Bourne Again Shell（处于POSIX模式），MirBSD Korn Shell以及其他名称的管理员/bin/sh，要么是……

   1. ……使脚本尽可能地可移植，以便切换/bin/sh映射到的内容不会破坏内容；要么

   2. …使非便携式脚本明确地针对正确的解释器程序，而不是简单地期望/bin/sh映射到它。

2. 有制作的Debian Almquist外壳的默认映射/bin/sh，而不是Bourne shell的，所以，那些脚本是 POSIX的符合性（或者，更确切地说，Debian策略手册符合性）更快速地跑了。

当然，一旦有人涉足这一领域，就可以做得更多。如考虑的喜欢的效率的权衡/bin/true，并/usr/bin/clear为shell脚本或编译的程序。幸运的是，这超出了此答案的范围。☺

当然，这些都不是新事物，也不是特定于Unix的。早在世纪之交之前，我编写并发布了一种命令行解释器，该解释器具有“交互式”和“非交互式”两种风格，解释了doco中的这种区别，并注意到COMSPEC和OS2_SHELL环境变量之间的区别。同样，在Debian的System V中删除Bashism的讨论rc和软件包安装/删除脚本的历史可以追溯到1990年代。

进一步阅读

• https://superuser.com/a/696310/38062
• https://unix.stackexchange.com/a/193210/5132
• 如破折号/bin/sh。Ubuntu Wiki。
• 如破折号/bin/sh。Debian Wiki。
• 洗礼。格雷格的Wiki。
• 布莱恩·卡尔森（2005年7月29日）。关于政策10.4的公共服务公告。<1122626433.30217.39.camel@stonewall.crustytoothpaste.ath.cx>。debian-devel。
• Raphael Geissert（2009-04-12）。破折号作为默认的/ bin / sh和无Bashisms的归档RG。<200904121359.09387.atomo64@gmail.com> debian-devel。
• debian-policy：请不要声明破折号下的脚本“可能”符合政策。Debian错误＃490604。
• 关于Debian的Debian软件包报告
• debian-policy：请不要使用echo -n，并且一般不要使用echo。Debian错误＃490605。
• 丽贝卡·索博（Rebecca Sobol）（2009-07-29）。 关于两个弹壳的故事：bash或dash。LWN。
• Justus Pendleton（1997-04-22）。包中的bash-ism。<E0wJjkL-0001II-00@ryoohki.res.cmu.edu>。debian-devel。
• 乔纳森·德·博伊纳·波拉德（2000）。“命令解释器前端”。命令解释器命令参考。32位命令解释器的在线文档。
• 约翰·钱伯斯（1990）。/ bin / true命令和版权

有什么理由让shebang指向/ bin / sh而不是/ bin / bash吗？

是。@Marco的出色答案很好地概括了这一点。

我应该在shebang中使用什么？

在编写自己的脚本时，应将shebang指向要测试的最通用的东西。

在我的系统（Centos 6.6）上，sh符号链接到bash：

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Dec  2  2014 /bin/sh -> bash

这意味着#!/bin/bash除非确认我的脚本中没有巴希姆，否则我总是在我的shebang中使用。

通过将shebang设置为#!/bin/sh您，您可以保证该脚本将适用于的所有实现sh。

这比说脚本可以与bash配合使用要大得多。

这是一个脚本示例，根据sh系统使用的实现，脚本的行为可能不正确：

#!/bin/sh
n=1
a=$((++n))
echo $n

使用bash脚本时将打印：

2

使用dash脚本时将打印：

1

如果我想使用#!/bin/sh我该怎么办？

• 使用checkbashisms- 检查脚本-请注意，这不会找到所有bashims。在上面的脚本中没有找到重击
• 使用另一个sh实现测试脚本。我通常使用进行测试dash，但是我希望某些Bashism或dashim仍然可以通过。

该DashAsBinSh页面上的Ubuntu的wiki有许多有趣的信息。

编写shell脚本（而不是使用更强大和更符合人体工程学的语言编写的脚本）的唯一剩余原因是，与具有任何其他因素的相比，向具有未知安装软件集的遗留系统的可移植性是否更重要。

/bin/sh是一个唯一的脚本解释器，可用于所有自称Unix的东西。但是，在大量的旧系统上，/bin/sh相关的实用程序甚至都不符合POSIX.1-1996“外壳和实用程序”规范，更不用说更现代的了。符合标准的工具是可选的附加组件，可以安装在/usr/xpg4此类位置或非显而易见的位置。¹ 与使用POSIX Shell语言编写脚本相比，使用可移植子外壳语言编写脚本更加乏味且容易出错。（configure如果您不相信我，请通读Autoconf生成的脚本。只需进行设置就足以说服您。）

但是，如果可以假定安装了其他任何脚本解释器（例如Bash），则可以假定安装了用于更好脚本语言的解释器。例如，Perl 比Bash 更可能可用。

因此，您永远不要编写#! /bin/bash脚本，因为如果这是一个选择，那么更好的语言也是一个选择。

¹例如，Solaris 10和更早版本的原始Bourne shell随附为/bin/sh。得知Solaris 11将其更新为ksh93。

您实际上应该使用

#! /bin/env sh

要么

#! /bin/env bash

这样，您就可以通过将它们安装在该系统上的方式来调用它们。

为了超级安全（例如在单用户重新启动的情况下），请sh使用bash。