我会把/bin/sh写成如下的shell脚本：

#!/bin/sh.orig
exec /bin/sh.orig "$@"

在整个系统的上下文中测试它;如果成功了就成功了
脚本的解释器是/bin/sh.orig，它将参数传递给/bin/sh.orig。
如果/bin/sh是Bash，请注意Bash会根据其名称更改其行为。众所周知，当以sh运行时，它禁用了一些非POSIX行为。我怀疑，如果它以sh.orig运行，它的行为将与Bash及其所有扩展一样。
如果这个黑客被部署为一个更大的系统的一部分，其中与您的解决方案无关的程序依赖于一个类似POSIX的/bin/sh解释器，这可能会破坏。一个可能的解决方案是假设Bash并将/bin/sh设置为：

#!/bin/bash
exec /bin/bash --posix "$@"

还要注意，如果我们知道我们的 Package 器是由Bash运行的，我们可以使用exec的-a选项，这在POSIX中是没有的。-a选项允许exec独立于可执行文件路径指定argv[0]：

#!/bin/bash
exec -a /bin/sh /bin/bash "$@"

在这里，我们执行Bash，而不是使用--posix，使得它的argv[0]是/bin/sh，然后它的行为应该类似于直接作为/bin/sh运行。
我看不出他的确切行为。当我以交互方式输入我的假sh时，提示符是sh-4.4$，而当/bin/sh是实际的Bash可执行文件而不是 Package 器时，我得到的是普通的$提示符。POSIXLY_CORRECT=y是以任何方式设置的，但这是一个明显的差异。
如果您的目标系统的/bin/sh不是Bash，显然您必须遵循一些替代的推理路线。