C语言通过pipe+dup2+execvp调用交互式/bin/sh运行异常排查

问题1：执行第一条命令后无法运行后续指令、输入exit后挂死的原因 #

核心是两点逻辑缺陷：

• 阻塞IO顺序执行逻辑不合理：现有代码按「先读父进程标准输入→再读子进程输出」的固定顺序执行，两个read调用均为阻塞模式。若子进程有输出待返回，但父进程正阻塞在读取标准输入的调用上，就会出现输出卡住、看起来无法执行后续命令的假象。
• 未处理管道对端关闭的场景：当子进程执行exit退出后，子进程持有的管道写端会被系统自动关闭，此时父进程调用read读取子进程管道会返回0（表示流结束），但现有代码只处理了count>0和count<0的分支，count=0时直接跳过进入下一轮循环，又会阻塞在读取标准输入的调用上，永远不会退出，直接表现为挂死。

问题2：运行命令时程序被自动挂入后台的原因 #

这是终端作业控制机制触发的结果：

• 交互式shell默认会启用作业控制，需要关联控制终端、属于前台进程组才能正常访问终端资源。你fork出的子进程sh和父进程属于同一个进程组，父进程才是前台进程组的成员，子进程不在前台进程组。
• 即使你重定向了stdin和stdout，交互式shell依然会尝试直接访问控制终端处理信号、输出stderr（你没有重定向stderr），当非前台进程组的进程尝试访问控制终端时，内核会发送SIGTTIN/SIGTTOU信号，该信号的默认处理动作是暂停进程，最终表现为整个程序被挂入后台。

修复建议 #

• 替换IO模型：使用select/poll/epoll同时监听标准输入和子进程输出管道两个文件描述符，哪个有数据就读哪个，避免顺序阻塞导致的输出卡住问题。
• 补充流结束处理：当读取子进程管道返回0时，直接退出父进程循环，避免挂死。
• 修复终端进程组问题：启动sh时添加+m参数关闭作业控制（修改为char *argv[]={ "sh","-i","+m",0};），或者fork后子进程调用setsid()创建新会话并设置为控制终端的前台进程组。
• 补充异常处理：重定向子进程的stderr到管道，捕获SIGCHLD信号回收子进程，捕获SIGPIPE信号避免写入关闭的管道时父进程异常退出。

内容的提问来源于stack exchange，提问作者sayer