Linux进程控制：手写迷你bash，彻底搞懂exec程序替换

1. 开头：先解决那个“fork完子进程，然后呢”的疑问

很多人学完进程控制前两篇之后，都会卡在同一个地方：fork出来的子进程跟父进程长得一模一样，可我需要的是一个完全不同的程序，比如在命令行里敲下ls，它就得去执行ls，而不是继续跑我写的那份代码。这个问题如果不解决，前面学的fork就永远只能停留在“复制自己”的阶段，做不了实际的事。这个过程就是“进程程序替换”（exec系列），也是这一篇的核心概念之一。把它弄明白之后，我们再去手写一个简化版bash解释器——也就是那种你能在终端里看到提示符、敲命令、回车被执行的东西。全程不用依赖系统自带的shell，我们自己从零实现它的主体逻辑。

这个标题适合谁？适合正在学进程控制、对Linux环境有基本了解、但还没真正把“程序如何被启动”这条链路串起来的人。如果你已经会写fork、知道wait的基本用法，那这篇恰好补上最后一块拼图：子进程是怎么“脱胎换骨”去执行一个全新程序的。另外我打算顺手实现一个mini bash解释器，用这个目标把fork、exec、wait、环境变量、命令解析全部串起来。这不是一个demo式的玩具，而是一个能真正跑起来、能在上面扩展管道和重定向的小壳。我自己当初从“能调exec函数”到“能写出可交互的shell”，中间隔了好几个星期，很多坑是翻文档翻不出来的。这篇把该踩的坑直接给你标出来。

你有过这种体验吗——就是一个进程fork完之后，子进程代码里写死的东西，无论怎么改父进程都不生效。原因很简单：fork复制的是“那一刻”的进程映像，后续两边各自修改互不干扰。但真正的动力在于，fork只是复制了自身，而exec才是“换血”。接下来我们从头把“进程程序替换”讲透，再用它来做一个能跑的bash解释器。

2. 程序替换的核心机制：进程如何“换血不换身”

2.1 替换的本质：同一个进程，全新代码段

先讲一个最容易混淆的概念：exec系列不是“启动新进程”，而是“替换当前进程的映像”。你可以这么理解——眼前这个人还站在原处，身份证号码也没变（PID不变），但他把脑子里的记忆、身上的技能、手里拿的剧本全换掉，从此他变成另外一个角色。操作系统做的事完全类似：exec函数执行成功后，当前进程的代码段、数据段、堆、栈全部被新程序对应的内容覆盖，进程控制块（PCB）里大部分信息保留，但程序入口、地址空间映射关系已经指向新程序。

这个“替换”动作决定了它有几个非常诡异的特性。第一，exec成功之后，它不会返回到调用点，因为原来的代码已经被覆盖了，根本没地方“回来”。第二，exec失败才返回-1，所以判断exec是否出错的唯一时机，就是看它有没有返回。第三，替换发生在当前进程，PID没变，打开的fd通常也保留（除非设置了close-on-exec标志，后面细说）。第四，替换前后进程的身份、工作目录、环境变量等大部分属性不变，除非你在exec参数中显式指定了新环境。

这些特性组合起来就引出了fork+exec这套经典搭配：先fork出一个子进程，让子进程调用exec去换血。父进程留下来继续做自己的事，子进程变成了目标程序。如果你直接在父进程里exec，那父进程自己就没了，之后再也回不到原来逻辑了。所以凡是需要“启动另一个程序但自己还活着”的场景，一律得先fork再exec。

2.2 为什么需要“替换”而不是“加载另一个程序”？

有人会问：为什么不能设计成让一个进程同时运行多个程序？操作系统还真的做不到。进程模型抽象出来的单位就是“一个地址空间 + 一组执行流”，你如果往一个地址空间里塞两套程序，共享同一个栈和堆，不出三秒就会互相踩踏。因此Unix的设计哲学非常暴力：你想跑新程序，就得把旧的东西整个扔掉，重新映射地址空间。严格来说，exec做的事是：清空当前进程的地址空间内容，按新可执行文件的段布局重新映射，再跳转到新入口。这个清空动作很快，因为大部分是页表操作。

从资源角度来看，exec还有一个好处：不需要重新创建进程描述符，不需要重新经过fork那一整套复制过程，因此开销比“创建新进程+加载程序”低。这也是为什么用bash跑命令时，每个命令子进程都是先fork再exec的组合。也就是说，你平时在终端里敲的每一条命令，背后几乎都是这种“克隆一次，然后变身”的流程。

那这里还有一个很现实的坑：fork之后，子进程复制了父进程的全部内存映像，如果父进程本身很大，复制成本会很高。现代Linux用了写时拷贝（Copy-on-Write）技术，fork时共享物理页，只有某个进程要写的时候才真正复制。所以大多数情况下fork是轻量的。但如果你在fork之后立即exec，子进程把整个映射换掉，那么之前“写时拷贝”做的页表共享就全部作废重建。这个细节在极端性能场景下值得注意，但对理解功能没有影响。

2.3 替换前后进程状态的变化

列一下替换前后，哪些东西变了，哪些没变。变了的是：代码段、数据段、堆、栈、程序计数器、寄存器状态。没变的是：PID、PPID、进程组ID、会话ID、当前工作目录、文件描述符表（默认）、信号处理设置（部分会重置，取决于信号类型）、umask、环境变量（可被exec参数覆盖）。

这里最容易出问题的是“文件描述符表保留”。假设你的父进程打开了一个日志文件fd=3，fork出来的子进程也会持有fd=3的引用。如果子进程exec一个命令，这个命令如果不知道fd=3的存在，通常没有影响；但如果它遍历/proc/self/fd并处理里面的fd，或者某个库函数“顺手”向所有fd写入内容，就会造成脏数据。尤其当父进程是守护进程时，启动的子进程可能意外继承不该继承的fd，这是生产环境常见的坑。解决办法是在open调用时设置O_CLOEXEC，或者在fcntl里设置FD_CLOEXEC标志，让exec执行时自动关闭这个fd。

另一个变化是“信号处置”。被捕获的信号（signal handler）在exec之后会恢复为默认行为；而忽略的信号（SIG_IGN）会继续保持忽略。这个规则导致一个经典问题：如果父进程忽略SIGPIPE，fork出的子进程exec一个命令后，该命令里使用管道时可能不会收到SIGPIPE，写操作直接返回EPIPE错误。你如果不清楚这条规则，调试时会觉得莫名其妙。

3. exec系函数族详解：六个函数，一套逻辑

3.1 execl、execv、execvp……它们到底差在哪

Linux下exec系列共有六个函数：

• execl(path, arg0, arg1, ..., NULL)
• execlp(file, arg0, arg1, ..., NULL)
• execle(path, arg0, arg1, ..., NULL, envp[])
• execv(path, argv[])
• execvp(file, argv[])
• execve(path, argv[], envp[])

表面看是六个，实际上核心只有一个：execve。它是系统调用，另外五个都是libc封装，最终都会调到execve。命名规则特别简单：带l（list）表示参数一个个列出来，带v（vector）表示参数放在字符串数组里；带p（path）表示可以在PATH环境变量中搜索目标程序，不带p就必须给绝对路径或相对路径；带e（environment）表示可以手动传入环境变量数组，不带e就用当前进程的environ。

用哪个取决于你的调用习惯。如果你已经有一个字符串数组argv，用execv最顺手；如果参数数量固定且少，execl写起来更直白；如果你想用它去执行用户输入的命令名，但又不想自己解析PATH，用execvp最省事——它会自动按PATH顺序查找可执行文件。

3.2 用一张表看清函数差异

注意一个细节：凡是带p的函数，查找逻辑并不是“在某个固定目录里找”，而是按照PATH环境变量里的目录列表依次尝试。如果PATH里没有这个目录，就算文件就在当前目录，也找不到。你在shell里敲./a.out能执行，是因为你显式给出了“当前目录下的a.out”，而不是靠PATH。反之，直接敲a.out若PATH里没有“.”，就会提示command not found。这个机制解释了为什么很多新手在写execvp时，明明文件在同一目录却找不到：因为他传的是 "a.out"，而不是 "./a.out"，且PATH里没有当前目录。

还有一个更容易踩的坑：execvp执行时会把当前进程的环境变量传给新程序，可如果PATH本身就被你改了或清了，那么带p的函数也会失效。比如你在程序里先unsetenv("PATH")，再调用execvp("ls", argv)，它什么都找不着。这个特点在实现shell时一定要记住：外部命令的搜索依赖PATH，而PATH是父进程环境变量，你的shell在启动时就应该完整继承它。

3.3 参数传递的细节：argv与NULL结尾

exec系列不管是list形式还是vector形式，都要求参数列表以NULL结尾。NULL在这里就是哨兵值，表示“参数到此结束”。在C语言里，NULL表示空指针，它和数字0在绝大多数平台上等价，但在可变参数函数里，编译器对类型检查有严格要求。

一个典型错误：execl("/bin/echo", "echo", "hello", NULL);这个用法是对的。但如果你写execl("/bin/echo", "echo", "hello", 0);，当"hello"后面跟的是int类型0时，在某些体系结构上因为可变参数类型提升问题，可能正常工作，但在严格模式下不可靠。正确做法永远是用(char *)0或直接NULL。如果漏掉这个NULL，printf格式的变参扫描会漫无边际地往后读内存，轻则参数错乱，重则段错误。我在给别人review代码时，见过不下三次这种漏了NULL的问题，现象都很诡异。

argv[0]的坑比很多教程写的还要深一层。argv[0]理论上可以是任意字符串，比如你写execvp("ls", argv)且argv[0]="echo", 那么新程序的argv[0]就是echo，但实际执行的还是ls的代码。很多命令行工具会用argv[0]来决定自己的行为模式，比如busybox就是靠argv[0]判断自己扮演哪个工具的角色。因此实现shell时，务必把用户输入的第一个词原样放进argv[0]。如果你图省事把它写死，某些程序会出现各种怪异行为。

3.4 exec的返回值和错误处理

exec成功后不返回，只有失败才返回-1，并且设置errno。常见的errno有：

在实际代码中，你写exec那句的时候，后面通常紧跟着一段perror输出和exit，因为如果exec成功，这段代码根本不会执行。这个模式也叫“exec后的死代码”。很多人第一次写时会对这个结构感到困惑——明明期望它跑完后面的代码，结果它直接没了。理解了“成功即不返回”，这个模式就是最自然的：失败时必须打印原因并退出子进程，否则ret = execvp(...) 之后子进程还会继续往下执行父进程的代码，两个进程跑一份逻辑，必出乱子。

4. 自己动手实现bash解释器

4.1 从“程序替换”到“解释器”，中间只差一个循环

bash本身也是一个进程，它做的事就是一直在循环：打印提示符 -> 读取用户输入 -> 解析输入 -> 执行 -> 回到打印提示符。这个过程没有任何魔法。你平时天天用bash，却很少去想它在操作系统层面到底做了什么。现在我们把视角翻转过来，从进程管理的角度重新审视bash：它是用户空间程序，靠read从标准输入拿命令，靠fork创建子进程，靠exec让子进程执行命令，靠wait回收子进程。也就是说，你在命令行里敲一条命令，bash并不是自己去执行这个命令，而是“雇佣”了一个新进程来执行，自己在旁边等着收结果。

这也是为什么终端里跑的命令和bash解释器是两个不同的PID。如果你去ps看，就会发现bash的PID和当前前台命令的PID差1左右，因为连续fork出来的一般相邻。理解了这一层，手写bash解释器就变成了一道“循环 + 进程管理”的综合应用题。

4.2 设计迷你shell：先想清楚要支持什么、不做什么

实现之前先定规格。我这里的目标是做一个“单行命令执行器”，不支持管道、不支持重定向、不支持脚本，但支持：外部命令执行、内置命令（exit, cd）、后台任务（尾部加&）、并行任务的简单尝试。这样设计是刻意的：管道和重定向涉及文件描述符的搬运和进程间通信，属于“第二批”复杂度，如果一开始就全上，你会分不清到底是shell解析的问题还是exec的问题。

网上很多教程会直接给你一个几百行的完整bash实现，但我建议你像我一样先做一个最小核心版本。原因很简单——你只有先确保fork、exec、wait这条链路在自己的代码里是清晰的，后面加再复杂的功能才不会翻车。先跑通“输入ls回车，屏幕上出现文件列表”这个场景，其他都好说。

4.3 主循环与命令解析：读进来，拆开，去执行

主循环结构不复杂：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/wait.h> #define MAX_LINE 1024 #define MAX_ARGS 64 void run_external(char **argv, int background) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return; } if (pid == 0) { execvp(argv[0], argv); perror("execvp"); exit(127); } if (background == 0) { waitpid(pid, NULL, 0); } else { printf("[bg] pid=%d\n", pid); } } int main(void) { char line[MAX_LINE]; char *argv[MAX_ARGS]; char *token; int background; while (1) { printf("mysh$ "); fflush(stdout); if (fgets(line, sizeof(line), stdin) == NULL) { printf("\n"); break; } line[strcspn(line, "\n")] = '\0'; if (strlen(line) == 0) { continue; } int argc = 0; token = strtok(line, " "); while (token != NULL && argc < MAX_ARGS - 1) { argv[argc++] = token; token = strtok(NULL, " "); } argv[argc] = NULL; if (argc == 0) { continue; } background = 0; if (strcmp(argv[argc-1], "&") == 0) { background = 1; argv[argc-1] = NULL; argc--; } if (strcmp(argv[0], "exit") == 0) { break; } else if (strcmp(argv[0], "cd") == 0) { if (argc < 2) { fprintf(stderr, "Usage: cd <dir>\n"); } else if (chdir(argv[1]) != 0) { perror("chdir"); } } else if (argv[0][0] == '/' || strncmp(argv[0], "./", 2) == 0) { run_external(argv, background); } else { run_external(argv, background); } } return 0; }

这个版本可以直接编译运行，gcc -o mysh mysh.c，然后进入交互界面。它已经具备bash最基础的行为：打印提示符、解析一行命令、fork子进程、exec执行命令、父进程等待结果。敲ls、date、whoami都没问题。cd是内置的，因为工作目录是进程的属性，fork出的子进程改自己的cwd影响不了父进程，所以只能由shell自己执行然后再让子进程继承。

我还特意保留了一个细节：末尾&支持后台运行。这个功能看似只是多一个参数判断，实际上背后是waitpid的行为差异。前台命令要阻塞等待，后台任务不等待立刻打印PID。最终的wait与否决定了进程会不会变成僵尸，这就是下一章要聊的坑。再往后想加管道，本质上就是在子进程之间串联fd，壳只需要做fork和exec以及dup2，解析部分要拆开命令。我后续会写扩展思路。

4.4 为什么要fork后再exec，能不能不fork？

这是新手最容易问的问题。如果你直接在主循环里调用execvp，那么exec成功的那一刻，你的shell就被替换成外部命令了，提示符循环永远不会再回来。这不是“退出shell再执行命令”，而是shell进程本身没了。所以必须fork出一个子进程，让子进程去exec。父进程（shell）通过waitpid等子进程结束，然后继续打印下一个提示符。这个过程就是“shell活着，子命令去死”。

从进程树角度看，你运行mysh后，它fork出子进程执行ls，ls结束，mysh继续。如果你在mysh里敲bash，那么新的bash也是mysh的子进程，两个bash的进程树呈父子关系。这些现象在ps里一看便知，建议你亲手跑一遍并对照进程PID，感受会比纸上谈兵深刻得多。

4.5 设计思路的关键点：什么该由shell做，什么该由子进程做

Shell的职责边界值得想清楚。以cd为例，它必须由shell执行，因为子进程改了目录对shell无效。以export为例，它设置环境变量，也必须由shell执行，否则子进程修改自己的环境变量，shell一点好处捞不到。反过来，外部命令基本都丢给子进程跑，因为shell只负责启动和等待。

这个边界在实现mini bash时尤其重要。如果你把cd命令也丢给execvp，cd不会更改当前shell的工作目录，效果就是cd永远“不生效”。这是很多初学者写shell时遇到的第一个逻辑错误：命令确实执行了，但没有任何可见变化。

内在原因很简单：环境变量和工作目录是进程私有属性，不是共享状态。外部程序修改不到调用它的shell。理解了这一点，你自然就知道为什么cd要内置，为什么export要内置，为什么命令替换的副作用要小心。

5. 扩展：输入输出重定向与管道

5.1 重定向的本质是文件描述符替换

基础版本跑通后，下一个值得加的功能是输出重定向。比如ls > out.txt，换成shell语言的描述就是：把标准输出（fd 1）重定向到out.txt这个文件上。在进程实现上，就是打开文件，然后用dup2把文件描述符复制到fd 1，让原本写到stdout的数据全部写进文件。

实现思路是在fork出的子进程中、exec之前做重定向。原因在于重定向只对要执行的命令生效，如果shell自己改了fd 1，以后所有命令的输出都会被污染。在子进程里做，就可以保证影响只限于这次exec的程序。

// 简化示意：解析出 command, outfile if (outfile) { int fd = open(outfile, O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); close(fd); } execvp(argv[0], argv);

这里有个顺序问题：必须先dup2，后exec，且两个动作都要在子进程里做。整个过程中argv和outfile的位置解析属于shell解析层，重定向实施属于执行层。这个分层思想在全套shell实现里至关重要。

5.2 管道：让一个进程的输出成为另一个进程的输入

管道实现的最小单位是pipe()。调用pipe后你得到两个fd：一个是读端，一个是写端。要让cmd1 | cmd2生效，你需要创建管道，让cmd1的stdout指向写端，让cmd2的stdin指向读端，然后父进程关闭管道两端，等待两个子进程结束。

这里坑很多。第一个是fd的关闭时机的管理。pipe出来后，父进程要close，两个子进程也各自要close自己不需要的那一端。任何一个fd没关，管道都不会正确发EOF，接收端会一直阻塞。第二个是fork时机。必须先创建管道，再fork两个子进程，因为子进程要继承管道两个端口的fd才能工作。如果你一个进程fork完再创建管道，两个子进程持有的就不是同一个pipe了。第三是等待顺序，bash一般同时wait两个子进程，避免一个收不到输出另一个收不到输入。

我不打算在这里给完整代码，因为写出来又是一百多行，且涉及进程组、信号处理的边界问题，容易劝退。但核心概念就是上面这些。后面单独写一篇“shell管道实现细节”时，我会把死锁、关闭时机这些坑全部铺开讲。

5.3 从单命令到完整bash：解析器的复杂度控制

真正的bash解析器能做分词、引号配对、转义、多命令、复合命令、函数定义、变量展开。如果你一上来就试图实现全套，很快会陷入“怎么处理嵌套引号”这类泥潭。我建议的路线是：

• 第一版：单命令，无参数，无引号
• 第二版：支持参数分割、&后台
• 第三版：支持输出重定向
• 第四版：支持单管道
• 第五版：支持环境变量展开和引号
• 第六版：支持for循环、if等复合命令

每一步都保持可运行可验证，不要试图一步到位。写bash解释器最大的价值不在于“造出另一个bash”，而在于通过实现它，把进程控制、文件描述符、环境变量这些零散知识像串珠子一样串起来。等你真正实现到管道那一步，你对操作系统“文件与进程统一”的理解会有一个质的飞跃。

6. 排查实录与常见坑清单

6.1 现象一：execvp提示找不到命令，但文件明明就在当前目录

这不是execvp出bug，而是PATH不含当前目录。当你在bash里执行ls，bash解析后调用execvp("ls")，execvp按PATH找/bin/ls、/usr/bin/ls等目录。如果你的shell启动时没有继承PATH，或者你自己把它覆盖了，那么ls当然找不到。解决办法是在shell启动时，用getenv("PATH")获取父进程的环境变量并保存。另一个盲区是相对路径：如果你传给execvp的是test.sh，它不会像bash那样默认在当前目录找。bash会自动处理“命令名中带/则直接用，不带/则PATH查找”的逻辑。你的mini shell默认调用execvp，实际上execvp已经做了这个查PATH动作，但你需要保证PATH存在。

6.2 现象二：exec之后shell崩溃或者输出异常

大概率是exec前面拼接参数时指针出了问题。常见的是argv数组没以NULL结尾，或者argv[0]指向了被修改的buffer。还有一个隐蔽问题：你在主循环里用strtok切割line，然后把指针存进argv。strtok会修改原字符串，如果你后面又对line做二次处理，指针就失效了。建议每次循环开始时重新解析原始输入，不要复用同一块buffer。

6.3 现象三：子进程变成僵尸进程

不调用wait或waitpid，子进程结束之后会留下僵尸状态，被init收养前一直占着进程表项。你在shell里跑了命令但从不wait，当你敲几十条命令后，你会发现一堆PID残留。解决方法是每条前台命令结束后，用waitpid回收。这里有个细节：waitpid的pid参数应该是fork返回的子进程PID，而不是-1。如果同时有多个后台任务，waitpid(pid...)要确保等待的是当前任务，而不是随便回收一个。

6.4 现象四：重定向时顺序错误，stdout和stderr混写

如果你先dup2再把原fd close，没什么问题。但如果你先close(1)再dup2(fd, 1)，在极端并发的场景下，新fd可能不是1，因为fd分配规则是“最小可用fd”。尽管dup2可以直接指定目标fd，在管道和重定向组合使用时，还是建议先dup2再close，避免fd表指针穿插产生脏状态。这个小顺序问题会直接导致一种诡异现象：明明重定向到文件，命令输出还在终端上。

6.5 速查表：exec程序中的经典错误

6.6 排查技巧：strace、gdb与最小复现

遇到莫名其妙的进程行为，第一件事是strace。strace -f -e execve ./mysh可以看到每次exec的系统调用参数和返回值。如果你发现execvp传入的argv和你想象的不一样，多半是解析层的问题。另一招是gdb：在fork的子进程里加sleep(100)，然后在另一个终端gdb -p PID附加进去，单步查看exec前后的代码路径。这个方法对分析“为什么子进程走到了不该走的逻辑”特别有效。

调试这种进程控制代码，我有一条铁律：永远做最小复现。不要在一个复杂shell上添加新功能后再调试新bug，而是先把原来的功能注释掉，写一个20行的测试程序复现问题。能复现，再逐步加回代码缩小范围。很多看起来像“玄学”的进程错误，最终都是fd泄漏、信号处理、变量覆盖这种老问题。

7. 最后分享一点个人体会

从我自己的学习路径来看，进程控制这一块，真正让我“开悟”的不是读了哪篇文档，而是亲手写完一个能跑命令的小shell。当你看到自己写的解释器fork出子进程、子进程变身成ls、然后输出结果回到提示符的那一刻，fork和exec的关系才算真正长进脑子。之后再去看bash的源码，会发现主线异常清晰，之前那些神秘概念全都有了实体。这篇做完之后，我强烈建议你继续加管道功能，因为管道会逼你换一种思路理解文件描述符，那是一种比“重定向”更深的认知升级。如果你在实现过程中遇到任何看起来无法解释的进程行为，先检查fd，再检查环境变量，最后检查信号设置，这三个方向能解决绝大多数疑难杂症。