popen最简单但仅支持单向通信；需用pclose获取退出码，注意缓冲区安全；复杂需求应选fork+exec+pipe；system无法捕获输出且不安全；c++标准库至今无std::process。
用 popen 最简单，但只支持单向通信
想在 C++ 里执行 shell 命令并拿到输出，popen 是最直接的选择。它本质是创建一个管道，把子进程的 stdout 连接到当前进程可读的文件描述符上。
注意：popen 只能读或只能写（取决于 mode 参数），不能同时读写；也不能获取子进程退出码以外的错误细节（比如 stderr 不会自动捕获）。
- mode 用
"r"表示读取命令 stdout，用"w"表示向命令 stdin 写入（较少用） - 返回值是
FILE*，必须用pclose关闭，否则资源泄漏且无法获取 exit status - 别用
fgets读取时忽略缓冲区长度，容易溢出；推荐用getline（C++11+）或带长度限制的fread
FILE* fp = popen("ls -l /tmp", "r");
if (!fp) { /* 处理 fork/exec 失败 */ }
char buf[1024];
while (fgets(buf, sizeof(buf), fp) != nullptr) {
// 处理一行输出
}
int exit_code = pclose(fp); // 注意：exit_code 是 waitpid 返回值，需用 WEXITSTATUS 提取
fork + exec + pipe 更可控，但代码量翻倍
当需要同时捕获 stdout 和 stderr、设置超时、或传递环境变量时，popen 就不够用了。这时得手动 fork 子进程，用 pipe 创建管道，再 dup2 重定向，最后 exec 执行命令。
关键点在于父子进程的 fd 管理：父进程要关掉写端（否则 read 不会 EOF），子进程要关掉读端，并确保所有无关 fd 都被关闭（尤其多线程下容易漏）。
- 务必在
fork后检查返回值：0 是子进程，>0 是父进程 pid，-1 表示失败 - 子进程中
exec失败必须调用_exit（不是exit），避免清空父进程的 atexit 注册函数 - 父进程读取前建议用
poll或select检查可读性，避免阻塞；读完后记得waitpid获取真实 exit code
别用 system 捕获输出——它根本没提供输出接口
system 只返回 shell 的 exit status，stdout/stderr 直接打到终端，完全不可捕获。有人试图重定向到文件再读取，这在多线程或并发调用时极易冲突（比如两个线程同时写同一个临时文件）。
更隐蔽的问题是：system 依赖系统 shell（通常是 /bin/sh），而 shell 解析命令行的方式可能和预期不一致（比如空格、引号、通配符），安全性也差——除非你完全信任命令字符串来源，否则不要拼接用户输入传给 system。
- 错误写法：
system("ls > /tmp/out.txt"); freopen("/tmp/out.txt", "r", stdin);—— 竞态、权限、清理全是坑 - 正确思路：要么用
popen，要么走fork+exec，绕过 shell 解析更安全
C++17 起可用 std::process？不，标准库至今没加
别被某些博客误导：std::process 是提案（P1196R3），尚未进入任何正式 C++ 标准（截至 C++23）。所有声称“C++17 支持 process”的代码，实际都是第三方库（如 boost::process）或自己封装的 popen/fork。
如果你考虑引入 boost::process，注意它默认仍基于 fork+exec，跨平台行为一致，但 Windows 下会转成 CreateProcess；它的流式接口看着简洁，但异常处理和资源释放逻辑比裸 API 更难 debug。
- 轻量项目优先用
popen+ 错误检查；复杂需求再评估 boost - Windows 上若不用 boost，
_popen行为类似 POSIXpopen，但只支持"r"和"w"，不支持"r+"
真正容易被忽略的是信号处理：如果主程序收到 SIGCHLD 且未设 handler，又没及时 waitpid，子进程会变僵尸；而 popen + pclose 内部已帮你等了，这点反而更省心。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
