为什么一个高管“ sh -c a.out”而不是a.out本身？

如何解决为什么一个高管“ sh -c a.out”而不是a.out本身？

我正在https://opensource.apple.com/source/Libc/Libc-167/gen.subproj/popen.c.auto.html研究Apple对popen()的实现，并注意到他们使用execl(_PATH_BSHELL,"sh","-c",command,NULL)而不是execl(_PATH_BSHELL,NULL)。

为什么要（或应该）执行可执行文件，例如通过a.out sh -c而不只是可执行文件本身？

如果您执行的是sh -c a.out而不是a.out本身，那么实际的a.out进程最终是否会成为“孙子”进程而不是 child 进程？

解决方法

为什么要（或应该）执行可执行文件，例如通过a.out sh -c而不只是可执行文件本身？

popen()设计为运行包含诸如>重定向，|管道和&&命令链接之类的shell语法的shell命令。它需要通过sh -c传递字符串以支持这些构造。如果没有，那么这些语法功能将作为参数逐字传递给相关程序。

例如，popen("make clean && make")应该触发两个make调用。如果没有sh -c，它将用三个参数调用make一次，就好像输入了一个

$ make clean '&&' make

在终端上。

如果您执行的是sh -c a.out而不是a.out本身，那么实际的a.out进程最终是否会成为“孙子”进程而不是 child 进程？

是的，这是正确的。当前进程和sh之间将有一个a.out进程。

,

他们使用execl(_PATH_BSHELL,"sh","-c",command,NULL)而不是execl(_PATH_BSHELL,NULL)

后者不会直接执行command，而是将_PATH_BSHELL设置为/bin/sh且没有参数的$0（command），导致shell要求其stdin提供命令。

此外，该语法依赖于NULL被定义为显式指针（例如((void*)0)），而不仅仅是0，这在任何地方都不能保证。尽管他们可以在实现中做到这一点（因为它们可以控制所有标头），但这不是您应该在应用程序代码中执行的操作。

不，execl(command,(void*)NULL)也不会直接执行command，除非command是 a）完整路径和 b）以可执行格式（二进制或以she-bang #!开头的脚本-后者是非标准扩展名）。如果command是要在PATH中查找的简单命令名称（例如pwd或a.out）或不是以she-bang开头的可执行脚本，则应'已经使用execlp代替了execl。

exec[lv]p[e]函数完成了Shell的某些工作（例如浏览PATH），但不是全部（例如运行多个命令或扩展变量）：这就是{ {1}}或system(3)将命令传递给popen(3)。请注意，两者都是/bin/sh -c，而不是用户的登录shell或使用的环境中的/bin/sh。

如果您执行的是$SHELL而不是sh -c a.out本身，那么实际的a.out进程最终会成为“孙子”进程而不是子进程吗？

仅适用于某些外壳，例如a.out。不适用于dash，bash，ksh93，mksh，zsh，yash等，它们将直接执行busybox分叉并等待它。