用fork/exec/wait实现自主Shell：从进程控制到命令行解释器

把 fork、exec、wait 三个系统调用串起来，你会得到一个真正能对话的自主shell命令行解释器。这个项目是我学进程控制时做过最过瘾的练习，它不是抄一段复杂脚本，而是纯粹靠进程调度能力，让一台裸系统“懂”你在终端里敲的每一行命令。Shell 这个名字听起来很玄，拆开看其实就是四件事：打印提示符、读取命令行、解析参数、让子进程去执行。这篇文章适合刚学完进程控制、想用一个大作业验证自己对 fork/exec/wait 理解的读者，也适合想搞懂“命令解释器到底怎么运作”的初学者。我会从设计思路讲到具体实现，再把重定向、管道这些进阶玩法一起带出来，最后把我踩过的坑全部抖给你们。

1. 拆解自主Shell的设计模型

1.1 Shell主循环的三个固定动作

Shell 并不是一个神秘的东西。你可以把命令行解释器理解成一家店的前台：它负责接单（读取命令行）、拆单（解析参数）、分派（创建子进程执行程序），最后还要向你汇报结果（回收子进程状态）。在代码层面，这就是一个不会退出的 while 循环。

while (running) { print_prompt(); read_command(line); parse_command(line, argv); if (is_builtin(argv[0])) { run_builtin(argv); } else { run_external(argv); } }

这个骨架看起来简单，但我建议你把它写到代码注释里，它会防止你迷失在细节中。很多同学做这个项目时会疯狂堆代码，结果主循环写得七歪八扭，甚至把 fork 放到了解析之前，导致每条命令都被执行两次。记住一个核心原则：主循环里应该只有“读、析、执行、回收”这四件事，其余的细节交给子函数处理。

1.2 “自主”到哪种程度：先把功能边界划清

做这种项目最容易翻车的地方，是一上来就想做 bash 的完整克隆。我写过一次教训：第一天就想着支持 tab 补全和通配符展开，结果一周都在跟字符串处理搏斗，反而把进程控制这个主角给忘了。

正确的做法是先分清“必须支持”和“可以后补”。我给自己定的第一版目标是这样：

• 能执行外部命令，比如ls、pwd、grep；
• 支持cd、exit这两个内置命令；
• 命令找不到时给出合理报错，Shell 不能崩；
• 前台命令执行后，Shell 要等它结束再显示下一条提示符。

这个目标列表本身就是“进程控制”的浓缩：创建子进程、替换程序映像、等待子进程回收。你只有在这些基础逻辑稳定之后，才值得去碰重定向、管道、环境变量和后台任务。自定义 Shell 不是要去实现 POSIX 全集，而是要通过一个能跑的项目，把进程生命周期彻底吃透。

1.3 fork+exec 为什么要刻意拆成两步

这是整个项目里最关键的一个“为什么”。如果只需要执行一个新程序，Linux 完全可以提供一个一键式接口，但它偏要把过程拆成 fork 和 exec 两步，目的是给你一个“机会窗口”。

fork 创建子进程时，会把父进程的地址空间、文件描述符、环境变量都复制一份；exec 则把子进程当前的映像整个替换成目标程序。你可以在 fork 之后、exec 之前插入各种进程控制逻辑：重定向文件描述符、修改环境变量、关闭多余的文件、配置信号处理。正是这个窗口，让管道和重定向能够以极简的方式实现。

用生活类比来说，fork 像是把一份图纸复制给了新员工，exec 是让新员工撕掉旧图纸、换上自己的作业蓝图。如果没有这个中间窗口，你想在启动新程序之前调整它的 stdin/stdout，就会无处下手。所以每次写子进程分支时，心里要默念：这个地方是留给我的控制台。

2. 搭建主循环与命令解析器

2.1 交互式读取：为什么用 fgets 而不是 scanf

很多初学者会想当然地用scanf("%s", ...)去读命令，结果遇到ls -l /home这种带空格的命令就彻底乱了。scanf按空白字符切分，还会把换行符残留在缓冲区里，让你后面的逻辑莫名其妙地多出一行空命令。所以在交互式 Shell 里，最稳的做法是用fgets读一整行。

char line[1024]; printf("mysh> "); fflush(stdout); if (fgets(line, sizeof(line), stdin) == NULL) { printf("\n"); break; } line[strcspn(line, "\n")] = 0;

这里有几个细节必须说明。第一次看到fflush(stdout)时，很多人不理解为什么要手动刷，其实是因为printf("mysh> ")没有以换行符结尾，终端可能会把这段提示文字留在缓冲区里，导致你盯着黑色屏幕不知道程序在等你输入。fgets会把换行符也算进字符串里，所以要用strcspn(line, "\n")找到换行位置并替换成字符串结束符。

如果用户按了 Ctrl+D，fgets返回 NULL，此时要 break 退出主循环，否则程序会在读不到输入的情况下空转。千万不要忽略这个分支，没有它你的 Shell 就无法干净退出。

2.2 最简单的 argv 拆分方式

命令行解析最直接的实现就是用strtok按空格和制表符切分。代码很短，但背后有个重要约定：execvp需要的是一个以 NULL 结尾的字符串数组，也就是argv[argc]必须指向 NULL。

char *argv[MAX_ARGS + 1]; int argc = 0; char *token = strtok(line, " \t"); while (token != NULL && argc < MAX_ARGS) { argv[argc++] = token; token = strtok(NULL, " \t"); } argv[argc] = NULL;

这段代码有两个注意点。第一，strtok会修改原字符串，所以line不能是常量字符指针，否则会触发段错误。第二，strtok会吞掉连续的分隔符，比如ls -l也能正确解析，但代价是你无法表达空参数，比如echo "hello world"里的引号语义在这里是做不到的。

如果你只想把进程控制吃透，这个粗糙解析器完全够用。如果你后续想扩展，可以自己写一个按引号状态切分的函数：用一个布尔变量记录当前是否在双引号内，遇到引号切换状态，遇到空格且不在引号内就切分。这个升级不涉及进程控制，但会让你的 Shell 更像真的。

2.3 内置命令分流：为什么不能在子进程里执行

解析完成之后，第一步不是 fork，而是判断命令是不是内置命令。原因很简单：像cd这种命令，必须由 Shell 进程自己执行，因为它要修改的是当前进程的工作目录。如果把它放进子进程里，子进程改了目录，父进程的目录纹丝不动，你执行一百次cd /tmp也还是在原地。

所以在主循环里要有一个分流函数：

int is_builtin(const char *cmd) { return strcmp(cmd, "cd") == 0 || strcmp(cmd, "exit") == 0 || strcmp(cmd, "export") == 0; }

这个函数的作用不是炫技，而是避免外部命令执行路径里出现“为什么 cd 不管用”这种经典 bug。你只要记住：外部命令需要新建子进程，内置命令则是 Shell 自己的内部函数调用。这两种模式的边界，就是进程控制里“本地操作”和“代理执行”的分界。

3. 进程控制核心：创建子进程、替换程序、回收状态

3.1 fork 返回值检查是第一条安全红线

外部命令执行函数是整个项目的精华。它的骨架长这样：

void run_external(char *argv[]) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return; } if (pid == 0) { execvp(argv[0], argv); perror("execvp"); exit(127); } int status; waitpid(pid, &status, 0); print_exit_status(status); }

很多初学代码里只判断pid == 0和pid > 0，把负数情况漏了。这个漏判不是理论问题：当系统进程数达到上限或内存不足时，fork 会返回 -1，此时如果你不管它，代码会走进父进程分支并对 -1 调用 waitpid，等于在不存在的孩子上等一个永远等不到的结果，Shell 就卡死了。perror("fork")能让你在异常时立刻看到原因。

3.2 execvp：让子进程真正“变成”目标程序

exec 函数族有很多变体，为什么这里推荐execvp？因为它会自动从 PATH 环境变量指定的目录列表里搜索可执行文件。如果你用execv，就必须自己拼完整路径，这对一个新手 Shell 来说太不友好。

execvp的签名是int execvp(const char *file, char *const argv[])。它的行为很特殊：调用成功时不返回任何值，调用失败时才返回 -1。所以你必须在 execvp 之后立刻处理错误，否则子进程会继续执行 fork 后面的代码，造成父子进程同时执行后续代码的严重后果。

这种 bug 我见过太多次了。有同学在子进程分支里执行完execvp("ls", argv)后忘记写perror和exit，结果子进程又跑回了主循环，再 fork 一次，形成一种“隐性进程膨胀”。最稳妥的写法是在 execvp 后面紧跟两行：

perror("execvp"); exit(127);

这里 exit(127) 是约定俗成的“命令找不到”退出码。这个 127 会让父进程的 waitpid 状态解析变得很有意义。

3.3 waitpid 状态解析：退出码、信号与僵尸进程

父进程调用waitpid(pid, &status, 0)时会阻塞，直到指定的子进程退出。这个阻塞行为非常符合前台 Shell 的直觉：你执行sleep 5，Shell 就会等你 5 秒再把提示符还给你。status 里面塞了一大堆位信息，不能直接当整数用，必须通过宏来解析。

void print_exit_status(int status) { if (WIFEXITED(status)) { int code = WEXITSTATUS(status); printf("[exit code] %d\n", code); } else if (WIFSIGNALED(status)) { printf("[signal] %d\n", WTERMSIG(status)); } }

WIFEXITED判断进程是否正常退出，WEXITSTATUS取出退出码。WIFSIGNALED判断进程是否被信号终止，WTERMSIG取出信号编号。比如你执行一个被 Ctrl+C 中断的程序，这里就能显示出它死于 SIGINT。

再说不 wait 的后果。如果父进程 fork 之后不管子进程，子进程退出时就会变成僵尸进程。僵尸进程已经死亡，但它的进程表项还留在系统里，直到父进程调用 wait 或 waitpid 回收。如果你写了一个循环创建子进程却从不 wait 的 Shell，很快你就会在另一个终端看到大量<defunct>进程。所以 waitpid 不是可选项，它是进程生命周期闭环的最后一环。

3.4 给练习加一点挑战：后台运行与僵尸

做完基础版之后，很多人会想支持&后台运行。这个扩展并不难，只需要在解析时判断argv最后一个参数是不是&，如果是就移除并标记background=1。然后父进程分支里这样处理：

if (background) { printf("[bg] %d\n", pid); } else { waitpid(pid, &status, 0); print_exit_status(status); }

但留个作业给你：后台子进程退出后，谁来回收它？如果父进程完全不 wait，它就成了僵尸。最简单的应对方式是注册 SIGCHLD 信号处理函数，在每个子进程退出时自动调用waitpid(-1, NULL, WNOHANG)。这种玩法已经超出了基础练习的范围，但做完你会更深刻理解“进程同步必须配合信号机制”这句难懂的话。

4. 父进程该干的活：内置命令的实现原理

4.1 为什么 cd 只能在 Shell 进程本身里做

进程的工作目录是进程自身属性。也就是说，每个进程都有一份“我在哪个目录”的档案，这份档案不会跨进程共享，只能由父进程传给子进程。当前 Shell 启动的所有子进程，天然继承 Shell 的当前目录；反过来，子进程改了目录，父进程不会感知。

所以内置 cd 的正确实现是直接在 Shell 函数里调用chdir：

int builtin_cd(char *argv[]) { const char *path = argv[1]; if (path == NULL) { path = getenv("HOME"); } if (chdir(path) != 0) { perror("cd"); } return 0; }

注意处理cd不带参数的情况，自动切回家目录。这里不需要 fork，也不需要 wait，它就是一次当前进程的系统调用。

4.2 export 的底层逻辑是环境变量表

环境变量同样具有“进程私有”属性。Shell 进程有一张环境变量表，每次 fork 子进程时，子进程会复制这份表，exec 新程序时新程序可以通过 environ 拿到它。如果 export 放在子进程里改，改的只是子进程自己的表，Shell 主进程的表纹丝不动。

通过setenv可以修改当前进程的环境变量表：

int builtin_export(char *argv[]) { if (argv[1] == NULL) { extern char **environ; for (char **env = environ; *env != NULL; env++) { printf("%s\n", *env); } return 0; } char *eq = strchr(argv[1], '='); if (eq != NULL) { *eq = '\0'; setenv(argv[1], eq + 1, 1); } return 0; }

这段代码演示了一个很关键的概念：内置命令不是用来“执行某条程序”，而是用来调整 Shell 自身状态的。理解了这一点，你就知道为什么export FOO=bar之后，后续执行的子进程能看见 FOO，但 Shell 之外的程序看不见它。

4.3 用命令表组织内置命令，别堆 if-else

当内置命令多了之后，最朴素的写法是在主循环里堆一长串strcmp。我强烈建议你至少用结构体数组整理一下：

struct builtin { char *name; int (*func)(char *argv[]); }; struct builtin builtins[] = { {"cd", builtin_cd}, {"exit", builtin_exit}, {"export", builtin_export}, {NULL, NULL} };

主循环里搜寻命中即可。这种写法不涉及复杂进程控制，但它会让项目后续扩展顺滑很多，也能让你避免在“判断命令类型”这件事上一次次重复劳动。对初学者来说，函数指针不一定是要掌握的深度内容，但这是一个很好的实际应用场景。

5. 进阶打通：标准重定向与管道

5.1 文件描述符在 fork 后被继承：既是便利也是坑

进程控制能实现重定向的底层原理，是文件描述符在 fork 之后会被子进程继承。这意味着你在子进程里打开一个文件、把它复制到 stdout 的位置，exec 之后的新程序就会把输出写到文件中，父进程的 stdout 不受影响。

具体代码通常在子进程分支里完成：

if (pid == 0) { int fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); exit(1); } dup2(fd, STDOUT_FILENO); close(fd); execvp(argv[0], argv); perror("execvp"); exit(127); }

这段代码中的dup2(fd, STDOUT_FILENO)是关键：它让 fd 和标准输出指向同一个打开文件描述，之后你再关掉原来的 fd，stdout 依然指向那个文件。为什么要 close 原来的 fd？如果不关，一个进程里同时有两个描述符指向同一个文件，在缓冲刷新的时序上会出现奇怪的问题，比如输出没落盘或写重复。

5.2 重定向的实现时机：必须在 exec 之前

“在 exec 之前完成重定向”这句话，是理解管道和重定向的一把钥匙。exec 会替换进程映像，但它不会重置文件描述符表，所以你在 exec 之前做的dup2会原样保留给新程序。可以说 exec 之前的子进程环境设置，就是新程序的“出生设置”。

如果你想支持>>追加，只需要把 open 的 O_TRUNC 换成 O_APPEND。2>则是在 dup2 时把目标指向STDERR_FILENO。这些变体看起来多，本质都是围绕 fd 0、1、2 做替换，掌握这一个点就能举一反三。

5.3 管道实现：两个子进程如何共享数据通道

管道是进程间通信里最简单的一种，也是考察进程控制理解深度的经典环节。它的核心思路是用pipe(fds)创建一对 fd：fds[0] 是读端，fds[1] 是写端。你接下来要做的是“把第一个命令的 stdout 接到第二个命令的 stdin”。

以ls | grep .c为例，拆成四步：

1. 创建管道。
2. fork 第一个子进程，执行 ls；在子进程里把 fds[1] 复制到 STDOUT_FILENO，关掉 fds[0]。
3. fork 第二个子进程，执行 grep；在子进程里把 fds[0] 复制到 STDIN_FILENO，关掉 fds[1]。
4. 父进程关闭管道两端，分别 waitpid 两个子进程。

对应伪代码如下：

int pipefd[2]; pipe(pipefd); pid_t p1 = fork(); if (p1 == 0) { dup2(pipefd[1], STDOUT_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(cmd1[0], cmd1); exit(127); } pid_t p2 = fork(); if (p2 == 0) { dup2(pipefd[0], STDIN_FILENO); close(pipefd[0]); close(pipefd[1]); execvp(cmd2[0], cmd2); exit(127); } close(pipefd[0]); close(pipefd[1]); waitpid(p1, NULL, 0); waitpid(p2, NULL, 0);

这里最容易翻车的点是“父进程不关闭写端”。如果父进程一直握着 fds[1]，那么管道永远不会出现“所有写端都已关闭”的 EOF，grep 就会一直阻塞在读取态，表现为整个 Shell 卡住。这也是我当时排了一整晚才明白的坑。

5.4 一条命令里同时带重定向和管道怎么办

实际操作中，很多命令同时包含管道和重定向，比如ls -l | grep txt > out.txt。我的建议是你不需要第一时间实现完整的语法解析，先做一个“按 | 拆分命令段，再为每段处理重定向”的简化解析器。用strchr(line, '|')找到管道符位置，把字符串劈成两半，两个半边分别走前文的重定向逻辑。每半边里的>或>>通过定位符拆分，提取出文件名。

这个阶段代码会显得有点乱，但思路清晰：管道负责连接前一段的 stdout 和后一段的 stdin，重定向则是在每段 exec 之前替换对应的标准 fd。两个特性组合在一起，无非是“两端截留”：从文件读、往管道写、或者从管道读、往文件写。

6. 调试经验与排错手册

6.1 命令找不到时，子进程为什么还要挣扎几下

最常见的诡异现象：输入一段不存在的命令后，Shell 没有退出，反而像进入了什么死循环，不断重复报错。百分之九十的原因就是 execvp 失败后没有 exit。子进程没退出，会继续执行 fork 之后的父进程逻辑，包括再次进入主循环读取命令。这么一来，一个错误的命令就能让 Shell 变成一台“无限生成子进程的机器”。

所以每次写完execvp那行，都要习惯性地接上perror("execvp"); exit(127);。这个习惯能救你很多次。

6.2 提示符不出现：别忘了 fflush(stdout)

如果你运行 Shell 后屏幕上只有光标在闪烁，却没有任何提示符，第一反应不应该是怀疑代码逻辑，而是检查你有没有写fflush(stdout)。终端对没有换行符结尾的输出通常不做实时刷新，尤其当你把输出重定向到文件或管道时，这个问题会更明显。printf("mysh> ")之后加一句fflush(stdout)，提示符立刻出现。

6.3 僵尸进程丛生，waitpid 放错了位置

用ps aux | grep defunct能看到一堆僵尸进程，说明父进程回收子进程的时机不对。常见错误包括：只 fork 不 wait；把 waitpid 写在某一个条件分支里；或者 waitpid 的参数传成了 -1，导致回收了所有子进程但没办法匹配具体的那个。等你做到后台任务时，这个问题会被放大。

如果你暂时不想接信号处理，最简单的做法是：前台命令必须waitpid(pid, &status, 0)；后台命令先允许僵尸存在，但要在代码里用注释标出来“这里未来要加 SIGCHLD 逻辑”。不要试图用 sleep 来绕过回收，那只会让问题更隐蔽。

6.4 用 strace 观察整个 fork/exec/wait 全流程

调试进程控制类项目，strace 是最有用的工具。启动你的 Shell 时这样运行：

strace -f -e trace=process,file,desc ./myshell

-f表示跟踪子进程，-e trace=process会捕捉 fork、execve、wait4 等系统调用，desc会显示文件描述符的 dup2、close、open 等操作。执行一条ls后，你能看到清晰的调用链：shell 先 fork，子进程里 execve/usr/bin/ls，父进程再 wait4。如果某一步缺失，比看代码找 bug 快得多。

6.5 功能测试用例：别只验证命令会不会报错

我习惯把测试用例固定成一个表格，逐条跑，逐条勾。少做这种系统化验证，容易陷入“功能好像能用，但一遇边界就翻车”的状态。

当你把这张表里每一行都跑通，你手里的自主 Shell 就已经配得上“进程控制实战”这个标签了。

做这个项目最大的收获，是让我把“进程”两个字从抽象概念变成了肌肉记忆。一开始我以为难点在解析命令格式，真正动手才发现，难点全在“谁创建了谁、谁在等谁、哪个描述符该关、哪条分支必须退出”。如果你也正在学进程控制，我的建议是把目标切成三块：先能用 fork 把ls跑起来，再加上 wait 控制同步关系，最后才去碰重定向和管道。这三步走通，你的自主 shell 就站稳了。后续引号解析、环境变量展开、作业控制都可以慢慢补，但核心始终不是功能多，而是每一次 fork 背后，你都清楚自己到底在干什么。