我不是系统管理员，但我的组织正在考虑将 Red Hat Enterprise Linux 6+ 中的 /bin/sh 替换为 /bin/ksh 的硬链接。这该是多么的鲁莽啊？
这个问题的背景是我们正在将第三方应用程序从 AIX 5.3 迁移到 RHEL 6+。该应用程序通过调用 sh 来执行 shell 命令。 shell 命令本身是用户定义的，并且实际上是为 Korn shell (ksh) 编写的。这在 AIX 中有效，因为 IBM 将 sh 作为 ksh 的硬链接提供。多年来，我们的团队创建并存储了数千个用户定义的命令。
我们发现其中一些命令在 Red Hat 中失败，因为 Redhat 中的 sh 是 bash 的符号链接。当作为 sh 调用时，bash 以 sh 模拟模式运行。问题在于，我们以前在 AIX 中的“fake sh”中工作的特定于 ksh 的命令（例如 print）在 Red Hat 中的“fake sh”中不起作用。我们还不知道不兼容性的全部范围。
在《学习 Korn Shell》（ISBN 0-596-00195-9）的第 10 章中，Bill Rosenblatt 和 Arnold Robbins 说：“我们想强调一些关于 Korn shell 的内容，但它并不适用于大多数其他 shell：你可以像安装标准 Bourne shell 一样安装它，即 /bin/sh。” ...“许多装置都做到了这一点，绝对没有产生任何不良影响。”
在红帽中这样做是多么的鲁莽？我担心的是，Red Hat 安装中的系统或第 3 方脚本可能取决于 bash 模拟 sh 的特性。如果是这样，使用 ksh 的硬链接解决我们眼前的问题可能会导致整个系统出现未知的损坏。
答案1
在系统范围内，这将是非常鲁莽的，正如您所怀疑的那样——它将导致依赖于 sh 兼容行为的启动脚本和系统实用程序的大量损坏。正如 Ulrich 所说，更安全的替代方法是创建一个 chroot，或者简单地将所有新用户的默认 shell 设置为 /bin/ksh，尽管这可能无法完全满足您的要求。