不胖妞如果你拿到的是操作系统课上的“实现一个简单的 Shell”作业，第一反应大概和我当年一样：这不就是个能敲命令、能执行程序的黑框框吗，Linux 终端长什么样，我抄一个什么样就行。可真等你坐到编译器前面，敲下第一行 fork() 的时候就会发现，这个作业真正想让你干的，不是“抄一个终端”，而是亲手把“程序怎么变成进程”“进程怎么被创建和回收”“命令的名字怎么被翻译成可执行文件”这一整条链路走通。这篇内容就围绕这份作业展开，给你完整拆解一个最小可用 Shell 的每一步：主循环怎么搭、命令怎么解析、外部命令怎么执行、内建命令和重定向管道又是怎么回事。
这篇文章适合正在写操作系统作业、需要交一个可运行 Shell 的同学，也适合那些想搞明白终端底层到底发生了什么、但不想直接去翻内核源码的读者。我会按我自己当时实现的顺序来讲——先跑起来一个能执行外部命令的“毛坯版”，再一点点往里加 cd、加退出码、加重定向、加管道，最后附上一份调试自测清单，帮你在验收前把雷都踩一遍。
1. 这个作业到底在考什么：Shell 不是“界面”，是内核的翻译官
1.1 从一段最简单的交互开始
你打开终端，看到屏幕上有 user@host:~$，敲一个 ls -l，回车，屏幕输出一堆文件信息，然后提示符又出现了。整个过程看起来像是一个程序在“读入命令—显示结果”，再朴素不过。但你有没有想过一个问题：谁去执行了 ls？
不是 Shell 本身。Shell 只是一个用户态程序，它没有权限也没有能力去遍历目录、读取文件元数据。真正干活的是操作系统内核，Shell 只负责把“你想运行 ls”这个消息转达给内核，再把内核执行完的结果拿回来展示给你。从这个角度说，Shell 更像一个翻译官，夹在你和内核之间，把人的语言翻译成系统调用。
操作系统课让你实现一个简单的 Shell，表面上是在考 C 语言和字符串处理，实际上是想让你理解翻译官这个角色到底要做哪几件事：把命令行字符串拆成程序名和参数、创建一个新进程去运行程序、等待这个进程结束并回收它的状态。这三件事恰好对应了三个系统调用：fork()、execvp()、waitpid()。你把这个铁三角吃透，Shell 的主干就有了。
1.2 Shell 在操作系统中的位置
我在写作业之前曾经有个非常幼稚的理解：既然终端能执行程序，那 Shell 是不是就是操作系统的一部分？后来才知道完全不是。Shell 就是一个普普通通的用户态进程，和记事本、浏览器没有本质区别，只是它的输入输出被绑定到了终端设备上。
这带来一个很有意思的推论：既然 Shell 是进程，那么你在 Shell 里执行的每一条外部命令（比如 ls、grep），都意味着操作系统要再创建出一批新进程。而这个创建动作不能由 Shell 直接“变”出来，必须通过 fork() 让内核复制当前进程、再用 exec 系调用把新进程的代码段替换成目标程序。这也是为什么这个作业几乎是所有操作系统课程里必定出现的题目——它不考你背了多少调度算法，而是逼你真刀真枪地接触进程生命周期。
还有个概念容易被忽略：Shell 不是被内核“特殊照顾”的进程。它一样有 PID，一样有父进程，一样会收到信号。作业里如果你用 kill 去杀自己写的 Shell，它的表现和杀一个普通程序没有区别。理解了这一点，你就知道为什么 Shell 里处理前后台任务会牵扯到信号和进程组了，这部分到后面讲到后台任务时我会再展开。
1.3 极简 Shell 的功能边界
明确一下“简单 Shell”的作业范围。不同学校的实验指导书要求不一样，但大多数聚焦在下面几条：
- 能打印提示符，读取用户输入的一行命令；
- 能按空格（或空白字符）把命令拆分成参数数组；
- 能执行外部命令并等待它结束；
- 提供至少
cd、exit这类内建命令； - 选做加分项通常是重定向（
><）、管道（|）、后台执行（&）。
我建议你先按这个边界实现一个能跑通的基础版，再考虑加分项。很多同学一上来就要写管道，结果卡在文件描述符的关端问题上进退两难，反而把最基础的 fork 模型弄得一团糟。其实一份能稳定执行外部命令 + cd + exit 的作业，已经能拿一个不错的基础分了。在此基础上每增加一个功能，都是一次清晰的增量，心态会完全不一样。
我实现的时候把代码分成三个模块：主循环模块负责读入和分发、解析模块负责把字符串切成参数、执行模块负责 fork 和 exec。这样分不是为了美观，而是为了调试方便——出问题时你能立刻定位到是“没读对”“没切对”还是“没跑对”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把主循环搭起来：读命令、解析、执行的三段式骨架
2.1 为什么用 getline 而不是老式 fgets
绝大多数同学的 Shell 代码会从主循环开始写。伪代码很简单：
c复制while (1) {
print_prompt();
read_command(buffer);
parse_command(buffer, argv);
execute_command(argv);
}
但具体到“读一行命令”这个动作，用哪个函数是有讲究的。教材里很多老代码用 fgets(buffer, MAX_LEN, stdin)，然后手动处理结尾的换行符。这样做不是不行，只是有两个隐患：第一，如果命令行很长超过 MAX_LEN，输入会被截断，程序就可能解析出莫名其妙的半截命令；第二，fgets 要求你预先分配一个固定大小的缓冲区，对作业来说够用，但不够“体面”。
C 标准库提供了 getline()，它内部会动态分配内存，自己扩容，用完以后需要 free()。它的原型是：
c复制ssize_t getline(char **lineptr, size_t *n, FILE *stream);
这里有个特别容易犯的错：lineptr 要传指针的指针，而且如果 *lineptr 为 NULL、*n 为 0，getline 会自己 malloc 一块内存并在 *n 里记录容量。返回值为 -1 表示读到文件末尾或出错。你写 Shell 时如果用户按 Ctrl+D，getline 会返回 -1，这时候正确的做法是打印换行并退出循环，而不是傻傻地把那个未初始化的缓冲区拿去解析。
我当时踩过这个坑，一按 Ctrl+D 程序就崩，原因就是我读完 -1 后没有立刻跳出去，而是继续往下走了解析逻辑。所以主循环第一版一定要处理这个边界：
c复制char *line = NULL;
size_t len = 0;
ssize_t nread;
while (1) {
printf("mysh> ");
fflush(stdout);
nread = getline(&line, &len, stdin);
if (nread == -1) {
printf("\n");
break;
}
// 去掉末尾换行后再解析...
}
free(line);
注意那个 fflush(stdout)，很不起眼但很重要。printf 输出到终端时通常是行缓冲，但为了确保提示符立刻显示出来，主动刷一下总是没错的，不然在某些重定向场景下会出现提示符迟迟不出现的诡异现象。
2.2 解析层的三个取舍
拿到一行字符串之后，下一步是把它拆成参数。这一步的经典做法是用 strtok() 或者更安全的 strtok_r()。但解析之前你必须先想清楚三个问题，否则后面的代码会写得非常拧巴。
第一个问题：多个空格怎么处理？用户敲 ls -l，中间有连续空格，你要不要当成空参数？正确的 Shell 不会，因为空白字符只是分隔符，连续的空格和单个空格等价。strtok 天然帮你处理了这一点，它会把连续分隔符视为一个，不会返回空字符串。如果你自己用 strchr 找空格再手动切割，就必须要额外跳过连续空格，平白给自己增加麻烦。
第二个问题：要不要去掉注释符号？真实 Shell 里 # 开头的部分是注释，但作业一般不需要你支持，甚至不少作业里 # 压根不是特殊字符。为了稳妥起见，你只需在一个地方做处理——如果一行的第一个非空字符是 #，就整行跳过，不执行也不报错。这个处理很便宜，但能让你在测试脚本里写注释。
第三个问题：命令名和参数之间如何存储？你最终要为 execvp 准备一个 char *argv[] 数组，数组最后一个元素必须是 NULL。所以建议解析完直接往这个数组里填。我的习惯是先把 line 用 strtok_r 切成一个个 token，然后逐个 strdup 存进 argv，最后在末尾放 NULL。
strdup 会动态分配内存，所以程序退出前要记得逐个 free，不然 valgrind 会报内存泄漏，虽然不影响功能，但实验报告里那一页内存检测截图就不漂亮了。
2.3 主循环代码骨架
把上面几个点组合起来，一个不算精致但足够跑通的主循环大概是这样的：
c复制#define MAX_ARGV 64
int main(void) {
char *line = NULL;
size_t len = 0;
while (1) {
printf("mysh> ");
fflush(stdout);
ssize_t nread = getline(&line, &len, stdin);
if (nread == -1) {
printf("\n");
break;
}
// 去掉末尾换行
line[strcspn(line, "\n")] = '\0';
// 空命令继续
if (line[0] == '\0' || line[0] == '#')
continue;
// 解析
char *argv[MAX_ARGV + 1];
int argc = 0;
char *saveptr = NULL;
char *token = strtok_r(line, " \t", &saveptr);
while (token != NULL && argc < MAX_ARGV) {
argv[argc++] = token;
token = strtok_r(NULL, " \t", &saveptr);
}
argv[argc] = NULL;
if (argc == 0)
continue;
// 执行
execute(argv);
}
free(line);
return 0;
}
这段代码里的 strcspn(line, "\n") 也是一个小技巧，它可以找到字符串里第一个换行符的位置，把它替换成 \0，等价于手动去掉尾部换行。当然，如果你用 getline 读完，直接用 strtok_r 以 " \t\n" 一分隔，也能把换行自动过滤掉，就不需要先处理换行了。两种写法都行，我是习惯先截断，逻辑更明确。
3. fork/execvp/wait：Shell 赖以生存的进程三件套
3.1 为什么必须 fork，不能直接 exec
等你把 argv 准备好，真正要执行的时候，第一个困惑就来了：为什么不直接调 execvp(argv[0], argv)，还得先 fork() 一下？
因为 exec 系函数的行为是“替换当前进程的代码段、数据段、堆和栈”，一旦调用成功，当前进程就不再是原来的程序了。如果 Shell 不做 fork 直接 exec，那么当你输入 ls 时，整个 Shell 进程会被 ls 的程序镜像替换掉，等 ls 跑完，Shell 也没了，终端窗口就关闭了，什么提示符都不会再出现。这显然不是我们想要的。
fork() 解决的就是这个问题：它先克隆出当前进程的一个子进程，子进程拥有父进程代码段的一份拷贝（实际机制是写时复制，但你可以先理解成拷贝）。这个子进程接下来调 exec，替换的是子进程自己的地址空间，父进程还是那个父进程，可以继续等待、继续读下一条命令。这就是为什么 Shell 执行外部命令必然是“先 fork 再 exec”，缺少任何一步都不行。
借用一句话说：fork 负责让进程“分裂”出执行者，exec 负责让执行者“变身”成目标程序，wait 负责让老爹知道孩子干完了没有。三者是一个组合拳，少了谁都不完整。
3.2 execvp 家族的选择：为什么是带 p 的那个
exec 家族有很多兄弟姐妹：execl、execlp、execle、execv、execvp、execvpe。它们区别在于：参数是以列表（l）还是数组（v）形式传递，是否使用 PATH 环境变量查找程序（带 p），是否传递环境变量（带 e）。
Shell 作业里最合适的是 execvp()，原因有二：其一，它接受 char *argv[] 形式的参数数组，刚好和我们解析出来的结构一致；其二，带 p 意味着它会像 Bash 一样，在系统 PATH 环境变量指定的目录中搜索可执行文件。也就是说，你输入 ls 时，execvp 会自己去 /usr/bin、/bin 这些目录里找有没有叫 ls 的文件，找到后执行。这省去了你手动拼接绝对路径的麻烦。
很多同学在这个阶段会纠结：如果用户直接输入了一个带了路径的命令，比如 /home/user/myprog，execvp 还能工作吗？能。带 p 的函数规则是：如果文件名中包含 /，就把它直接视为路径去执行；如果不含 /，才去 PATH 里搜索。所以 execvp 能同时处理“命令名”和“路径式命令”这两种输入。
3.3 wait 的作用：别让 Shell 变成僵尸收容站
fork 之后，子进程变成目标程序开始运行。但子进程退出后，内核不会马上把它从进程表中清掉，而是保留一个“僵尸进程”的记录，里面存着退出状态，等待父进程来“收尸”。如果父进程不调用 wait 或 waitpid，这些子进程就会以僵尸状态残留在系统里。僵尸进程不占 CPU，但占着一个进程表项，积累多了会影响系统创建新进程。
Shell 必须对前台命令调用 waitpid()。最基础的写法是：
c复制pid_t pid = fork();
if (pid < 0) {
perror("fork");
} else if (pid == 0) {
// 子进程
execvp(argv[0], argv);
perror("execvp");
exit(127);
} else {
// 父进程等待子进程结束
int status;
waitpid(pid, &status, 0);
}
子进程里 perror 后面要紧跟 exit，否则如果 execvp 执行失败（比如命令不存在），子进程会继续往下跑父进程的代码，造成双份 Shell 同时在跑的奇怪局面。约定俗成的退出码是 127，表示命令未找到。这个数字不是乱来的，Bash 里命令不存在时返回 127，很多测试脚本会检查这个值，所以你的 Shell 最好也遵守这个惯例。
waitpid 的返回值也值得检查。如果返回 -1，说明等待过程出错（比如子进程被信号打断），这时候要用 perror 打一下。如果返回的 pid 和你 fork 出来的 pid 不一样，也说明有问题。作业里不用做太复杂的错误恢复，但至少别让错误悄无声息地过去。
3.4 完整执行流程代码
把前三节整合起来，一个最小执行函数是这样：
c复制void execute(char *argv[]) {
pid_t pid = fork();
if (pid < 0) {
perror("fork failed");
return;
}
if (pid == 0) {
// 子进程：变身
execvp(argv[0], argv);
// 到这里说明 exec 失败
fprintf(stderr, "mysh: %s: command not found\n", argv[0]);
exit(127);
} else {
// 父进程：等娃
int status;
if (waitpid(pid, &status, 0) == -1) {
perror("waitpid");
return;
}
// 可选：把子进程退出码记录下来，供 $? 使用
}
}
这个函数一旦写好，你的 Shell 就已经能执行 ls、pwd、date、echo 这些外部命令了。把这段代码编进主循环里编译运行，你会看到提示符出现，敲命令有输出，退出后用 echo $?（如果是你自己的 Shell 就不支持，但至少在系统终端里）能拿到命令的退出状态。到这一步，作业的“地基”已经打完了。别急着得意，因为后面还有几个坑等着你。
4. 运行目录、退出码与内建命令：把“命令解释器”变成环境
4.1 哪些命令必须内建：为什么 cd 不能靠 exec
你把上面的 Shell 编译完，输入 ls 有输出，输入 pwd 有输出，但输入 cd /tmp 却什么反应都没有，再输入 pwd，发现还在原目录。这是为什么？
因为你现在的 execute 对一切命令都走 fork-exec。cd 是先被 fork 出来的子进程执行的，子进程调用 chdir() 只会改变子进程自己的当前工作目录，父进程（也就是 Shell）的目录纹丝不动。等子进程退出，一切恢复原样。这和真实系统里 cd 必须是 Shell 内建命令的原因完全一致：凡是会改变 Shell 自身状态的命令，都不能在子进程里做，必须在 Shell 进程里直接执行。
顺着这个逻辑想，exit 也一样。如果 exit 放进子进程，子进程退出了，父进程 Shell 还活着，没有任何意义。所以 “内建命令”这个概念不是作业故意刁难你，而是由 fork 的子进程隔离模型天然决定的。
通常一个简单 Shell 至少要内建的命令是：
| 命令 | 功能 | 为什么必须内建 |
|---|---|---|
cd |
切换当前目录 | 会修改 Shell 自身工作目录 |
exit |
退出 Shell | 只有 Shell 自己才能结束自己 |
pwd |
打印当前目录 | 不需要 fork，效率考虑，但不是绝对必须 |
export |
设置环境变量 | 环境变量属于进程自身 |
setenv/unsetenv |
类似上者 | 同上 |
很多同学搞混：pwd 其实是可以靠 fork-exec /bin/pwd 来实现的，虽然多此一举但结果正确。真正必须内建的底线是 cd 和 exit。如果实验指导书明确要求“支持环境变量”，那 export 也逃不掉，只是大多数简单 Shell 作业不涉及。
4.2 cd 的实现与 PATH 机制
既然 cd 必须内建，那它的原理就很直白了：在 Shell 进程里直接调用 chdir() 系统调用。
c复制if (strcmp(argv[0], "cd") == 0) {
const char *path = argv[1] ? argv[1] : getenv("HOME");
if (chdir(path) != 0) {
perror("cd");
}
return;
}
if (strcmp(argv[0], "exit") == 0) {
exit(0);
}
注意两个细节。
第一，cd 不带参数时，按照 Bash 的行为应该回到用户主目录，也就是 $HOME 环境变量的值。你可以直接 getenv("HOME") 拿到。虽然作业大多只测 cd /tmp、cd .. 这种，但顺手把无参数的情况处理了肯定加分。
第二，cd 之后，提示符上如果显示了当前目录，比如 mysh:/tmp>，那你还需要在显示提示符前主动调用 getcwd() 获取最新目录。提示符怎么设计作业一般不限制，但既然支持了 cd，提示符能反映当前路径，会给人一种“这个 Shell 是真的”的直观感受。我这里给一个不额外 fork 的取目录方式：用 getcwd(NULL, 0)，它会让系统帮你分配一块内存，用完记得 free。
关于 PATH，execvp 已经自动处理了外部命令的搜索路径，但你可能还想在出错时打印更友好的消息。你可以用 getenv("PATH") 打印出当前路径列表，帮助调试为什么某个命令找不到。如果用户自己改了 PATH 环境变量，只要在 Shell 进程里维护好了，fork 出来的子进程会继承这份环境变量，execvp 的搜索路径也就跟着变了。这是环境变量通过进程继承机制传递的又一个体现。
4.3 退出码约定与作业评分常见考察点
写完内建命令后，你应该认真对待“退出码”这个东西，因为它几乎是作业验收时最容易考你的暗点。
外部命令退出时，会把一个 0~255 的整数状态留给父进程。waitpid 的 status 参数其实是编码过的，你需要用宏来解析。常用的是 WIFEXITED(status) 判断子进程是否正常退出，WEXITSTATUS(status) 取出退出码。如果子进程是被信号杀死的，WIFSIGNALED(status) 为真，WTERMSIG(status) 能拿到信号编号。
一个简单 Shell 至少要做到：前台外部命令结束后，把它的退出码记住。这样你后续如果实现了 echo $? 或者脚本里的退出码判断，才能有据可依。我建议给 Shell 维护一个全局变量 last_status，在执行完一个命令后更新它。
c复制if (WIFEXITED(status)) {
last_status = WEXITSTATUS(status);
} else if (WIFSIGNALED(status)) {
last_status = 128 + WTERMSIG(status);
}
128 + 信号编号 这个规则来自 Bash：如果进程被信号 9（SIGKILL）杀死，Shell 记录退出码为 137。这样做是为了让投递到脚本里的退出码能够传递“是被信号终结”这个信息。
作业验收的时候，写实验的人经常会做几件事：敲 ls /nonexistent、敲一个不存在的命令、敲 Ctrl+C 中断一个 sleep 命令，然后查看你的 Shell 的反应。如果你的 Shell 每次都无脑退出、或者提示符不回来、或者直接崩了，印象分会大打折扣。把退出码逻辑写对，至少你心里有底。
5. 进阶：重定向与管道的文件描述符操作
5.1 重定向的本质是替换文件描述符
做完“能执行命令”的主力功能后，如果时间和精力允许，我强烈建议你挑战一下重定向和管道。这不只是为了加分，更是因为这两个功能是理解文件描述符的绝佳素材。
先看重定向。ls > out.txt 的语义是：把 ls 的标准输出从终端改到 out.txt 文件。从文件描述符的角度看，标准输出固定是文件描述符 1，Shell 要做的就是把子进程里的 1 号描述符指向那个文件，然后执行 ls。
这个动作要用 dup2() 系统调用完成。dup2(oldfd, newfd) 的作用是把 oldfd 这个描述符“复制”到 newfd 上，让 newfd 和 oldfd 指向同一个文件表项。执行 dup2(fd, 1) 之后，所有写到 1 号描述符的内容，都会进入 fd 指向的文件。
所以 > 重定向的实现步骤是：
- 在子进程里（注意，不是在父进程里改）用
open()打开目标文件，得到fd； - 调用
dup2(fd, STDOUT_FILENO)，让标准输出指向文件； close(fd)，因为我们已经不需要原来的 fd 了；- 执行
execvp，目标程序以为自己在往终端写，实际在写文件。
这里有一个重要原则：重定向是子进程自己的事，不要在 fork 之前就去动父进程的标准输出，否则 Shell 自己的输出也会被带偏。正确做法是 fork 之后、exec 之前，在子进程分支里完成 dup2。至于文件名怎么从命令行里分离出来，这是解析层的工作——你在 parse 阶段发现 > 就把它之后的字符串记为输出文件名，并从参数数组中剔除 > 和文件名。我当时用了一个朴素的办法：在 execute 里先扫描整个 argv，找到 >，把它的下一个 token 记录成文件名，然后把这两个位置在 argv 里替换成 NULL，这样 execvp 拿到的就是去掉重定向部分的干净参数。
< 输入重定向的机制完全对称，只是把标准输入 0 号描述符指向文件。
5.2 管道是无名文件，打通两个进程的读与写
如果说重定向是“把标准输出指向文件”，那管道 cmd1 | cmd2 就是“把 cmd1 的标准输出接到 cmd2 的标准输入”。管道本身是内核提供的一块缓冲区，用户态通过 pipe() 拿到两个文件描述符：fd[0] 是读端，fd[1] 是写端。数据从写端流入，从读端流出，先进先出。
实现一个管道需要两个子进程：左边进程把标准输出 dup2 到 fd[1]，右边进程把标准输入 dup2 到 fd[0]。这里面最隐蔽的坑是文件描述符的关闭时机。
父进程调用 pipe() 得到 fd[0] 和 fd[1] 后，这两个描述符是父子进程共享的。如果你 fork 了左进程，但没有在左进程里关闭读端 fd[0]，那么这个读端仍然被左进程持有。当右进程试图从读端读取数据时，由于写端还有一个左进程持有（它自己），系统会认为管道仍然可能被写入，于是读取会一直阻塞等待，而不会收到 EOF。最终表现就是程序卡住。
同样，父进程自己如果不关闭两个端，也会出现类似问题。
所以管道的标准写法有一条非常硬的纪律：
- 创建管道
pipe(fds)； - fork 左进程；
- 在左进程内：
close(fds[0])，dup2(fds[1], STDOUT_FILENO)，close(fds[1])，exec 左侧命令； - fork 右进程；
- 在右进程内：
close(fds[1])，dup2(fds[0], STDIN_FILENO)，close(fds[0])，exec 右侧命令； - 在父进程内：
close(fds[0]); close(fds[1]);然后waitpid等待两个子进程结束。
第 3、5 步子进程里把用不到的读写端关掉，是为了不干扰管道 EOF 的判定；第 6 步父进程关掉两端，是为了确保 Shell 自己不会意外持有管道描述符。这是一个“谁用谁留、不用就关”的原则。多级管道 a | b | c 可以靠递归或循环拼接实现，核心逻辑不变，但每次多一条管道就多两个 fork 和四处 close，建议先把单管道调通再扩展。
5.3 后台执行与进程回收的信号问题
重定向和管道跑通后，如果你还有余力，可以看看后台执行 &。
后台执行的语义是：命令后带 & 时，Shell 不需要等待这个命令结束，而是立刻打印新提示符，让用户可以继续敲下一条命令。实现上很简单——判断 argv 最后一个 token 是不是 &，如果是就把它去掉，然后父进程不调用 waitpid，直接返回主循环，相当于“放养”子进程。
但这里立刻冒出一个问题：你放养的子进程退出后，谁来给它们“收尸”？如果 Shell 不 waitpid 这些后台进程，它们会变成僵尸进程，累积多了会占满进程表。真实 Shell 会安装 SIGCHLD 信号处理器，每当有子进程状态变化就异步调用 waitpid 回收。作业里如果做到这一层，你需要处理信号：
c复制#include <signal.h>
#include <sys/wait.h>
void sigchld_handler(int sig) {
(void)sig;
int status;
while (waitpid(-1, &status, WNOHANG) > 0)
;
}
WNOHANG 表示如果没有已退出的子进程就立即返回，这样在信号处理函数里循环回收所有已就绪的子进程，不会阻塞。装好这个处理器后，前台命令和后台命令的回收逻辑就统一了——区别只在于前台命令在 fork 之后还会主动 waitpid 一次还是把回收完全交给信号处理。
我自己的经验是：后台执行属于典型的“写起来 10 行，调试 2 小时”功能。它牵涉信号、进程组、终端控制，做不好可能连前台的 Ctrl+C 行为都会变得不正常。如果你时间紧，建议先保证前台命令、重定向、管道这三项稳定，再考虑后台任务。很多操作系统实验的评分标准里，管道的权重远高于后台任务。
6. 调试与避坑清单：写完 Shell 之后你需要自测的几件事
6.1 运行时最容易出现的三个 Bug
我身边同学写完 Shell 之后，拿去验收之前最容易翻车的往往不是大功能没做，而是几个小细节。
第一个 Bug 是提示符与输出交错。如果你在等待子进程之前就把提示符打印了，或者子进程执行期间父进程没有阻塞等待，屏幕上的输出顺序会乱七八糟。解决办法是严格遵守“先 fork、子进程 exec、父进程 waitpid 之后，再回到主循环打印下一条提示符”的时序。有些同学喜欢在子进程分支里 printf 调试信息，这会污染输出，排查时建议全部重定向到 stderr 或用调试器。
第二个 Bug 是 exit 之后提示符又蹦出来了。这类问题通常出在解析层：用户输入 exit 后面还跟了别的字符，或者 exit 命令没被识别成内建命令，被当成普通命令 fork 出去执行了。子进程执行 exit(0) 只退出了子进程，父进程还在主循环里，自然又打印一次提示符。
第三个 Bug 是命令找不到时，错误提示打了多遍。原因是你在 fork 之后的子进程里打了 perror，但后续的代码路径又让父进程也执行了同样的打印逻辑。排查方法是每次 fork 之后果断判断 pid == 0，在该分支里 exec、出错、exit，不要让自己有机会滑落到父进程代码里。
6.2 用 valgrind 查内存问题
Shell 这种不断读输入、不断分配内存的程序，最头疼的问题是内存泄漏。操作系统作业通常不强制你用 valgrind，但实验报告上能贴一张“no leaks are possible”的截图，绝对会让老师给你加分。
使用方式很简单，编译时加上 -g，然后：
bash复制gcc -g -o mysh mysh.c
valgrind --leak-check=full ./mysh
进入你的 Shell 后，敲几条命令，然后 exit，valgrind 会打印整个进程的内存分配和释放报告。常见的问题有两种：getline 分配的内存没有 free；你 strdup 解析出来的每个 token 占用的内存没有逐个释放。如果程序内部不主动释放，等到进程退出时内核会回收全部内存，所以功能上完全看不出来，但 valgrind 会毫不留情地逐条列出来。
把这些泄漏全部修干净，对 C 语言能力本身就是一次很好的锻炼。我当时是在 execute 返回前把所有 strdup 出来的参数逐个释放。注意要在 execvp 之前不要释放，因为 exec 成功后进程已经被替换，之前的堆内存会整段被回收，不需要手动释放；只有 exec 失败退出后才需要考虑清理。为了让代码简洁，我的处理策略是：解析时不再 strdup，而是直接让 argv[i] 指向 getline 返回缓冲区中的位置（strtok_r 本来就这么干），最后统一释放 line 一块内存即可。
这个策略能大幅减少自由内存的烦恼，但代价是你必须在一次主循环内完成命令执行并等待结束，不能把 line 缓冲区里的 token 存到下一轮循环中，因为下一轮 getline 可能重写这块缓冲区。
6.3 作业验收自测清单与亮点设计
最后给出一份我在交作业前会从头到尾跑一遍的自测清单。你可以把它整理成测试脚本，也可以手动逐条敲。
第一组，基础命令测试：依次输入 pwd、ls -l、echo hello world、date，观察输出是否正常，提示符是否稳定出现。
第二组，内建命令测试：输入 cd /tmp，再输入 pwd，确认目录确实切换了；输入 exit，Shell 退出；输入 exit 3，如果在系统终端里运行你的 Shell，然后用 echo $? 查看，应该得到 3（前提是你实现了带参 exit）。
第三组，错误场景测试：输入 /nonexistent，程序不能崩；输入一个不存在命令如 foobar123，提示 command not found 且 Shell 继续运行；直接按 Ctrl+D，Shell 退出；按 Ctrl+C，如果还没做信号处理，Shell 会退出，这属于正常，但如果实现了屏蔽，则应只是中断当前前台命令。
第四组，进阶功能测试：ls > out.txt，然后 cat out.txt，检查内容；ls -l | grep out.txt，看管道能否正常出结果；cat < /etc/passwd，检查输入重定向；sleep 2 & 后立即输入 echo ok，看是否 OK 先打印、2 秒后 Shell 有无僵尸残留（可以用另一个终端的 ps -aux | grep defunct 查验）。
上面的测试全部通过，你这份 Shell 作业基本就稳了。
验收之前还有一个低成本高回报的亮点设计：给每个内建命令和外部命令的成功与否打印清晰的状态。比如外部命令找不到时用 mysh: 命令名: command not found，cd 到非法目录时用 mysh: cd: /xxx: No such file or directory。这种模仿 Bash 风格的错误消息不需要多少代码，但会让看实验的人立刻感受到你考虑到了边界情况。
另外，把源码按功能拆成几个文件（比如 main.c、parse.c、execute.c、builtin.c），每个文件头部写注释说明职责，也会让代码的工程感比单文件高一大截。操作系统课虽然不要求你遵循多高的软件工程标准，但一份结构清晰、注释到位的代码，会给实验评分带来实打实的好处。
写到这里，这篇围绕“实现一个简单的 Shell-操作系统Homework”的完整拆解就结束了。我个人在实际完成这份作业后最大的感受是：以前在终端里敲命令，觉得一切都是理所当然的，但当我亲手把 fork、exec、wait、文件描述符这一条链串起来后，再看终端里任何一条命令，脑海里都能浮现出它背后的进程轨迹。作业本身也许只有几百行代码，但它值得你多花几个晚上去打磨，因为你未来理解多进程编程、理解网络服务里常见的父子进程模型，都会从这里起步。