＃！/ bin / sh与＃！/ bin / bash相比具有最大的可移植性

我通常使用Ubuntu LTS服务器从我了解的符号链接的工作/bin/sh来/bin/dash。通过符号链接/bin/sh到其他许多发行版本/bin/bash。

从中我了解到，如果脚本#!/bin/sh在最上面使用，它可能不会在所有服务器上以相同的方式运行吗？

当人们希望这些脚本在服务器之间具有最大的可移植性时，是否建议使用哪种外壳用于脚本？

Shell脚本的可移植性大约有四个级别（就shebang行而言）：

1. 最便于移植：使用#!/bin/shshebang并仅使用POSIX标准中指定的基本shell语法。这几乎可以在任何POSIX / unix / linux系统上运行。（好吧，除了Solaris 10和更早的版本具有真正的旧版Bourne shell，它早于POSIX就不兼容/bin/sh）。

2. 第二个最轻便：用一个#!/bin/bash（或#!/usr/bin/env bash）家当线，并坚持bash的V3功能。这将在具有bash（在预期位置）的任何系统上工作。

3. 第三大可移植性：使用#!/bin/bash（或#!/usr/bin/env bash）shebang行，并使用bash v4功能。在具有bash v3的任何系统上（例如macOS，出于许可原因必须使用它），该操作都将失败。

4. 最少可移植：使用#!/bin/shshebang并使用bash扩展来扩展POSIX shell语法。在/ bin / sh的bash以外的任何系统（例如最新的Ubuntu版本）上，这将失败。永远不要这样做；这不仅是兼容性问题，而且是完全错误的。不幸的是，这是很多人犯的错误。

我的建议：使用前三个中最保守的那个，它提供了脚本所需的所有shell功能。为了获得最大的可移植性，请使用选项＃1，但是以我的经验，一些bash功能（如数组）非常有用，因此我将选择＃2。

您能做的最坏的事情是＃4，使用错误的shebang。如果您不确定哪些基本功能是POSIX，哪些功能是bash扩展，请坚持使用bash shebang（即选项＃2），或者使用非常基本的shell（如Ubuntu LTS服务器上的破折号）彻底测试脚本。Ubuntu Wiki上有很多值得关注的bashisms列表。

在Unix和Linux问题“ sh兼容是什么意思？”中，有一些关于外壳的历史和差异的很好的信息。以及Stackoverflow问题“ sh和bash之间的差异”。

另外，请注意，shell并不是唯一一个在不同系统之间有所不同的事物。如果您习惯使用Linux，那么您就会习惯于GNU命令，这些命令具有许多非标准扩展名，这些扩展名在其他unix系统（例如bsd，macOS）上可能找不到。不幸的是，这里没有简单的规则，您只需要知道所使用命令的变化范围即可。

就可移植性而言，最讨厌的命令之一是最基本的命令之一：echo。每当您将它与要打印的字符串中的任何选项（例如echo -n或echo -e）或任何转义符（反斜杠）一起使用时，不同的版本都会做不同的事情。任何时候您要打印不带换行符的字符串，或者要在字符串中使用转义符的情况下，请printf改用（并了解其工作原理-比实际echo情况要复杂得多）。该ps命令也很混乱。

另一个需要注意的一般事项是命令选项语法的最新/ GNUish扩展：旧（标准）命令格式是命令后跟选项（带有单破折号，每个选项为单个字母），后跟命令参数。最新的（通常是非便携式的）变体包括长选项（通常在中引入--），允许--选项位于参数之后，并用于将选项与参数分开。

在./configure准备用于构建TXR语言的脚本中，我写了以下序言以提高可移植性。即使#!/bin/sh是不符合POSIX的旧Bourne Shell ，脚本也将自行引导。（我在Solaris 10 VM上构建每个发行版）。

#!/bin/sh

# use your own variable name instead of txr_shell;
# adjust to taste: search for your favorite shells

if test x$txr_shell = x ; then
  for shell in /bin/bash /usr/bin/bash /usr/xpg4/bin/sh ; do
    if test -x $shell ; then
       txr_shell=$shell
       break
    fi
  done
  if test x$txr_shell = x ; then
    echo "No known POSIX shell found: falling back on /bin/sh, which may not work"
    txr_shell=/bin/sh
  fi
  export txr_shell
  exec $txr_shell $0 ${@+"$@"}
fi

# rest of the script here, executing in upgraded shell

这里的想法是，我们找到一个比正在运行的外壳更好的外壳，然后使用该外壳重新执行脚本。在txr_shell环境变量设置，使重新执行脚本知道它是重新执行递归实例。

（在我的脚本中，txr_shell变量也随后用于两个目的：首先，将其作为信息输出的一部分打印在脚本的输出中。其次，将其作为SHELL变量安装在中Makefile，因此make将使用此变量也可以执行食谱。）

在/bin/sh破折号的系统上，您可以看到上述逻辑将找到/bin/bash并重新执行该脚本。

在Solaris 10机器上，/usr/xpg4/bin/sh如果未找到Bash ，则将启动。

序言是用保守的Shell方言编写的，test用于文件存在性测试，以及${@+"$@"}用于扩展参数的技巧，以适应一些残破的旧Shell（"$@"如果我们使用的是POSIX兼容Shell ，则可能只是这样）。

与现代脚本语言（例如Perl，Python，Ruby，node.js甚至是Tcl）相比，Bourne Shell语言的所有变体在客观上都非常糟糕。如果您需要做的事情甚至有些复杂，那么从长远来看，如果您使用上述方法之一而不是Shell脚本，那么您会感到更快乐。

唯一的一个优势的shell语言仍然有对这些新的语言是什么自称/bin/sh是保证在任何宣称是Unix的存在。但是，有些东西甚至可能不符合POSIX。许多旧有的专有Unix /bin/sh在Unix95要求进行更改之前（是二十年前的Unix95，并且还在不断增加），在默认PATH中冻结了由PATH 实现的语言和实用程序。可能有一组Unix95，或者甚至是POSIX.1-2001，如果幸运的话，这些工具不在默认PATH（例如/usr/xpg4/bin）上的目录中，但不能保证它们存在。

但是，与Bash相比，在任意选择的Unix安装中更可能出现Perl的基础知识。（通过“ Perl的基础知识”，我的意思是/usr/bin/perl存在并且是Perl 5的某些版本，也许是很旧的版本；如果您很幸运，该版本的解释器附带的模块集也可用。）

因此：

如果您要编写的东西在所有看起来都是Unix的地方都可以使用（例如“ configure”脚本），则需要使用#! /bin/sh，而无需使用任何扩展名。如今，在这种情况下，我将编写兼容POSIX.1-2001的外壳，但是如果有人要求支持生锈的铁，我将准备修补POSIXism。

但是，如果您没有编写必须在所有地方都可以使用的东西，那么一旦您想使用所有Bashism，就应该停下来，并用更好的脚本语言重写整个内容。您未来的自我会感谢您。

（因此，当被它适合使用猛砸扩展第一顺序：从未二阶：只延长猛砸交互式环境-例如，提供智能标签完成和花哨的提示？。）