Linux下C语言实现Minishell：如何指定进程处理用户输入

这个问题在开发自定义shell时太典型了！本质上是终端输入的归属权没理清，我给你几个实用的解决思路：

1. 后台进程启动时重定向标准输入到/dev/null #

后台进程的设计初衷就是不需要和用户交互，所以直接切断它从终端读输入的路径是最直接的办法。在fork出后台子进程后、调用exec之前，把它的标准输入重定向到/dev/null：

// 子进程中执行
int null_fd = open("/dev/null", O_RDONLY);
if (null_fd == -1) {
    // 处理错误
    perror("open /dev/null");
    exit(EXIT_FAILURE);
}
dup2(null_fd, STDIN_FILENO);
close(null_fd);
// 然后执行exec系列函数
execvp(...)

这样后台进程尝试读输入时会直接得到EOF，不会卡住等待，更不会抢父shell的输入。

2. 用进程组和终端控制权管理（更符合标准shell行为） #

终端的输入默认只会发送给前台进程组，父shell作为启动者，本身属于前台进程组。我们可以把后台进程放到单独的进程组，并且确保父shell始终持有前台终端控制权：

• 在fork子进程后，子进程调用setpgid(0, 0)创建新的进程组（自己作为组长）
• 父进程调用tcsetpgrp(STDIN_FILENO, getpgrp())，确保自己的进程组是前台进程组
• 当后台进程尝试读终端时，会收到SIGTTIN信号，默认行为是暂停进程（和bash等标准shell一致）

这时你的shell可以维护一个jobs列表，显示这个暂停的后台进程，用户输入fg命令时，再把该进程组切换为前台，让它继续读取终端输入。

3. 可选：处理SIGTTIN信号 #

如果不想让后台进程暂停，也可以让子进程忽略SIGTTIN信号：

// 子进程中执行
signal(SIGTTIN, SIG_IGN);

但这样后台进程读stdin会返回错误，需要子进程自己处理这种情况，一般不推荐，因为不符合用户对shell的预期行为。

总结一下，最常用的是前两种方法结合：后台进程默认重定向stdin到/dev/null，同时通过进程组管理终端控制权，既避免输入冲突，又符合标准shell的交互逻辑。

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