问题描述
我正在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
分叉并等待它。