tox*_*lot 18 shell scripting bash portability
我编写的大多数代码都是用 PHP 编写的。我最近开始学习 shell 脚本。我遇到的大多数资源和教程都是针对 Bash 的。有些人对 bashisms 提出警告，有些人则没有。我在这里和 Stack Overflow 上读了很多。
每当答案使用bashisms 时，总会有人评论说：
你不应该使用 <insert bashism here>。它不便携。
即使问题被标记为 ，也会发生这种情况bash。对我来说，这就像告诉 PHP 程序员他们不应该使用 PHP 5 中的新代码，因为它不能与 PHP 4 一起使用。或者告诉某人他们不应该为 Mac 编写一些东西，因为它不能使用在 Windows 上。
当我用 PHP 编写时，我会选择一个最低要求并编写向前兼容的代码。我不担心让它向后兼容。
如果我#!/bin/bash用作shebang，为什么不应该使用bashisms？我开始觉得有些人只是为了它而喜欢抨击bashisms（双关语）。
人们经常使用bash和shell互换——可能是因为 bash 是许多系统上的默认 shell。所以我可以理解添加注释来警告代码使用 bashisms，但我不明白使用它们是错误的含义。
显然，如果我编写的脚本严格供个人使用，我可以用我想要的任何语言编写它。但我想我写的一些代码可能对其他人有用。
在发布之前，我尝试搜索我的问题的答案。我找到了很多关于如何测试可移植性的信息，但找不到任何关于何时这样做很重要的信息。
那么，何时编写可移植脚本很重要？
例如，
jor*_*anm 15
作为这个社区的一员，我不经常看到人们因为针对 bash 的事情而无视 bashism。在谈论可移植性时，GNUisms 比 bashisms 糟糕得多。只要您bash用于您的shebang，您就可以期望脚本使用bash. 但是，除非您明确检查，否则您无法保证版本。Bash 版本 4 带来了一些有用的特性，例如关联数组，但 Bash v3 仍然广泛用于 OS X 和 RHEL 5。
什么类型的脚本应该尽可能可移植？
这更多地是关于您的需求以及您作为开发人员选择支持的内容。如果您正在为支持所有 *NIX 类型的应用程序编写安装脚本，那么可移植性将非常重要。
没有安装 Bash 的系统有多常见？
FreeBSD 和 Solaris 10 是默认情况下未安装 bash 的系统示例。大多数 Linux 系统都有它，嵌入式系统除外。
如果系统安装了 Bash，它还会有 GNU 版本的 find 和其他实用程序吗？
不，这是便携性的真正问题。如果可移植性很重要，您应该只使用由 POSIX 标准定义的 shell 命令功能。GNU 实用程序可以安装在非 GNU 系统上，例如 FreeBSD，但它们不太可能是 PATH 中的第一个，并且您不能依赖这些工具来安装。
那么，何时编写可移植脚本很重要？
什么类型的脚本应该尽可能可移植？
当您将它们用于您的工作环境，并且您在不同的机器上工作（或将来可能）时 - 并且，您不想在开始工作之前重写您的工具。
例如：垃圾脚本/rm替换
马克·斯图尔特：
...对于我的故障排除工具包，我假设我只有 vi 和 Korn shell。我尝试使用适用于大多数 Unix 版本的命令。