我有一种情况,我想在shell可执行文件启动(/bin/sh或bash)之前运行少量的自定义逻辑,我正在考虑编写一个 Package 器,以便我可以将shell二进制文件移动到/bin/sh.orig,并将我的二进制文件放置在/bin/sh,并让它通过每次调用/bin/sh。这看起来很简单,但我想了解执行此操作的最佳/最可靠的方法,并确保正确的参数、信号和I/O操作。
我是用args执行()新进程就可以了,还是需要fork()/等待信号/退出代码被正确处理?我不想过多考虑这个问题,但我希望在大多数情况下,我的 Package 器能够正确地在shell可执行文件的位置运行。
1条答案
按热度按时间tct7dpnv1#
我会把
/bin/sh
写成如下的shell脚本:在整个系统的上下文中测试它;如果成功了就成功了
脚本的解释器是
/bin/sh.orig
,它将参数传递给/bin/sh.orig
。如果
/bin/sh
是Bash,请注意Bash会根据其名称更改其行为。众所周知,当以sh
运行时,它禁用了一些非POSIX行为。我怀疑,如果它以sh.orig
运行,它的行为将与Bash及其所有扩展一样。如果这个黑客被部署为一个更大的系统的一部分,其中与您的解决方案无关的程序依赖于一个类似POSIX的
/bin/sh
解释器,这可能会破坏。一个可能的解决方案是假设Bash并将/bin/sh
设置为:还要注意,如果我们知道我们的 Package 器是由Bash运行的,我们可以使用
exec
的-a
选项,这在POSIX中是没有的。-a
选项允许exec
独立于可执行文件路径指定argv[0]
:在这里,我们执行Bash,而不是使用
--posix
,使得它的argv[0]
是/bin/sh
,然后它的行为应该类似于直接作为/bin/sh
运行。我看不出他的确切行为。当我以交互方式输入我的假
sh
时,提示符是sh-4.4$
,而当/bin/sh
是实际的Bash可执行文件而不是 Package 器时,我得到的是普通的$
提示符。POSIXLY_CORRECT=y
是以任何方式设置的,但这是一个明显的差异。如果您的目标系统的
/bin/sh
不是Bash,显然您必须遵循一些替代的推理路线。