清单：何时编写便携/ POSIX兼容的shell代码？

Question

许多shell开发人员花费大量精力开发可移植代码，避免使用例如Bashisms，我想知道这种增加的工作量对于满足软件需求有多大帮助。

我想知道是否可以提供一个简单的需要便携式代码的条件清单。我们假设

• 使用shell而不是$BETTER_LANGUAGE实际上是有道理的，
• 每个shell在所有目标系统上都具有相同的版本（即shell版本差异不是可移植性的一部分），
• 目前不考虑可读性/可变性（便携式代码可能比最新的Bash RegEx功能更容易阅读/理解）。

到目前为止，我已经想到了这一点：

• 代码实际上（或可能在将来）并且故意在不同的shell中执行（例如，因为目标平台仅限于不同的shell，或者因为代码可能必须在更快的shell中执行，如dash在未来）并提供不同的实现是不可行的。
• 代码是旨在自行移植的框架的一部分
• 代码是必须可在各种平台上构建的源包的一部分
• 该软件作为各种目标系统的软件包进行分发，开发人员不希望对特定shell进行依赖

是否有任何我没想过的明显条件，或者是否可以更普遍地表达？ POSIX合规性是否需要与一般可移植性不同的清单？是否有任何文献或其他资料来源推荐？

Answer 1

  

我想知道这种增加的努力有多少真正有助于满足软件要求。

这 - “这种增加的努力” - 表明首先选择shell作为编程语言是错误的。 Shell是管道的语言：你没有在其中实现工具 - 你用它来控制其他工具。如果shell脚本需要很长时间来开发，如果遇到POSIX shell的限制，那么shell很可能是错误的语言。

唯一的例外，就是你的清单中缺少的东西，是一个裸露的环境，好像刚安装好的商业UNIX系统（可能还有一些* BSD系统）。如果你为这样的系统开发软件，那么你可能不得不使用POSIX shell，因为系统上可能没有安装任何其他东西（就像在字面上“字面上没有任何东西”）。

最后，所有软件都附带了依赖项和先决条件列表。如果你将bash作为依赖项包含在内，那就不会打扰* NIX admin：bash通常是此类系统上安装的第一个第三方软件包。此外，与其他第三方软件相比，bash（与其他流行的shell一样，例如csh，tcsh，ksh）实际上没有安装和依赖性问题。

  

POSIX合规性是否需要与一般便携性不同的清单？

没有“一般便携性”这样的东西。可移植性总是特定。

广泛定义的软件可移植性是软件在两个或多个不同操作系统上运行的能力。 POSIX是一种操作系统标准，为用户和软件开发人员定义了OS接口的一部分。它是一个平台基础，而不是它自己的平台。

POSIX合规要求我只在一些利基市场看到过。通常唯一的原因是它是唯一存在的操作系统ISO标准。

对于没有“POSIX合规性”硬性要求的软件，通常建议针对特定平台。公分母可能仍然是POSIX标准，但操作系统特定的功能，自定义和处理只是使软件更好地为特定平台的用户。

最后，用户不关心POSIX。 POSIX是开发人员的工具。开发人员使用它来降低为多平台开发和维护软件的成本。因此，来自用户的要求是对特定平台的支持，而不是“POSIX合规性”。