在 unix 中从 C 运行外部可执行文件似乎有两种常见的方法，
system()
打电话和
pid = fork()
switch(pid)
//switch statement based on return value of pid,
//one branch of which will include and exec() command
在功能相同的情况下（父进程等待子进程完成，子进程没有返回复杂信息），是否有任何理由更喜欢 fork/exec 而不是系统？
问问题
24442 次
4 回答
20
system执行命令解释器，即 shell，它 (a) 比直接 fork/exec 慢，(b) 在不同系统上的行为可能不同，(c) 如果您将来自不受信任的字符串传递给它，则存在潜在的安全隐患来源。此外，system等待子进程退出，而您可能希望它与父进程同时运行。
更一般地说，低级 fork/exec 为您提供了额外的控制：在两个操作之前或之间，您可能想要chdir打开管道、关闭文件描述符、设置共享内存等。
（通过不同的系统，我不是指 Windows 与 Unix（因为 Windows 甚至没有 fork）：我说的是 Red Hat Linux 与 Ubuntu。前者使用 Bash 执行传递给system的内容，后者是轻量级 POSIX 兼容外壳。）
于 2013-02-12T10:47:24.273 回答
4
fork()创建一个新进程。如果您不需要这样做，只需使用system()（或popen()）。您可能需要第二个进程来实现并行性，或者对作业进行更细粒度的控制，但如果作业是同步的，您通常不会关心这一点。
另一方面，我发现 95% 的使用system()是不必要的，或者以某种方式更好地使用另一种方式（例如使用 zlib 而不是system("gzip")）。所以也许最好的答案是两者都不使用！
于 2013-02-12T10:47:42.750 回答
1
通过system()另外调用一个 shell 进程，这可能不是你想要的。
此外，仅当此类 shell 死亡时才通知调用进程，而不是当 shell 运行的实际进程死亡时才通知调用进程。
于 2013-02-12T10:47:38.230 回答
-1
system() 将输入命令并像用户输入的那样执行它。我大多看到它喜欢system("pause"); system("cls");
但是如果你需要控制子进程，你要fork。
于 2013-02-12T10:47:24.633 回答