2

每当我编写 shell 脚本（主要是软件开发实用程序或构建工具）时，我通常会尽量避免使用 bash，而是使用普通的旧 sh 来实现可移植性。但是最近我遇到了越来越多的问题，其中有用的功能不可用，或者使用 sh 的系统之间的行为实际上不太一致，而不是使用 bash，因为 sh 被别名为不同的外壳......

据我了解，sh 是最古老的 Unix shell，精心编写的 sh 脚本理论上应该可以在几乎所有系统上运行......但似乎每个主要 shell 也有大约 9000 种不同的变体。使用 bash 作为脚本解释器不会有效地限制脚本的可移植性吗？当然，在 OS X 或几乎任何 Linux 上都没有问题，但是 BSD 呢？Solaris、AIX、HP-UX？如果你真的想在所有东西上运行，你会怎么做？

我知道 bash 几乎可以安装在任何操作系统上，但它真的是所有相关现代系统的一等公民吗？它是预装的吗？我只是不确定是否最好避免或接受 bash 以获得最一致和便携的整体体验。

4

3 回答 3

2

如果你真的想在所有东西上运行，你会怎么做？

您遵循（以及您正在调用的工具）的POSIX 标准，sh并希望目标操作系统也这样做。任何称为“UNIX”的现代产品都必须遵循这个标准，并且习惯上（尽管不是普遍的）标准外壳将被称为/bin/sh. BSD 和 Linux 发行版也倾向于针对 POSIX 兼容性。

于 2012-06-19T06:32:41.767 回答
2

使用 bash 作为脚本解释器不会有效地限制脚本的可移植性吗？

是的，但这取决于您提到的目标受众。如果它是一个简短的脚本，那么值得在dash（Ubuntu 和 Debian 的默认 shell）下测试 POSIX 兼容性。

每当我开始考虑我的 shell 脚本中的可移植性问题时，我都会切换到另一种语言。Perl 广泛可用，通常是脚本的不错选择，但如果您的工具要被 Python、Ruby、$lang 开发人员使用，请充分利用 $lang。

于 2012-06-19T06:39:01.433 回答
0

bash 本身只是一个普通的 C 程序，不需要特殊权限即可运行，可以放在任何位置。您可以轻松地从源代码构建它。基本上，如果您需要并且不需要系统管理员来安装它，您可以运行 bash。

只要它在您的路径中，您始终可以使用该行编写脚本。

#!/usr/bin/env bash
于 2012-06-19T07:42:42.697 回答