Linux进程替换：exec系列函数原理与实战

如果你写过 Linux 上的 C 程序，大概率迟早会遇到这样一个问题：fork 出来的子进程，除了复制一份父进程的地址空间之外，它仍然在继续执行父进程的代码。想让子进程去跑一个全新的程序，而不是继续“父进程的剧本”，怎么办？答案就是 Linux 进程替换，也就是以 execl、execlp、execv、execle 为代表的 exec 系列函数。

这篇文章适合刚学系统编程的初学者，也适合在写后台服务、嵌入式工具、自定义 shell 时想把子进程执行逻辑搞扎实的开发者。我会从原理到实际写法，把这组函数讲透，包括 PATH 查找、环境变量传递、缓冲区陷阱、文件描述符继承这些平时文档里不会细说、但实际总会踩到的点。

1. 先搞清楚进程替换到底替换了什么

很多初学者第一次看到“进程替换”这四个字，第一反应是“这不就是开新进程吗”。要命的是这个直觉恰好是反的。exec 系列函数执行成功之后，当前进程的 PID 不会变，进程关系不会变，打开的文件描述符默认也不会变，变的只有进程的用户态映像：代码段、数据段、堆、栈全部被新程序替换。

1.1 换头术：进程还是那个进程，程序已经换了

我习惯用一个类比：fork 是“影分身”，exec 是“让分身接受新的任务”。父进程调用 fork 之后，内核复制出一个子进程。子进程从 fork 返回点继续执行。这个时候子进程本质上就是父进程的复制品。如果想让子进程去执行 /bin/ls，你需要让子进程调用 exec 系列函数。exec 成功之后，子进程的地址空间里不再有原来父进程的任何用户态代码，指令指针直接跳到新程序的入口，也就是新程序的 main 函数。

这里的重点是，exec 不会“创建”出一个新的进程。它只是在当前进程基础上原地更换程序。所以 fork + exec 才是一套完整动作：先用 fork 产生子进程，再用 exec 把子进程变成你想要的程序。如果你不想保留原进程，直接在一个进程里调用 exec 也可以，比如很多登录程序就是这样，认证通过后直接把自己替换成用户的 shell。

1.2 内核视角：换了哪些东西，没换哪些东西

从内核角度看，execve（真正的系统调用）会释放原进程的虚拟内存空间，重新建立新的内存映射，加载新程序的代码段、数据段、BSS 段，初始化堆和栈。不会变的是进程描述符里和“身份”相关的部分：PID、PPID、进程组、会话、当前工作目录、根目录、umask、以及已经打开且没有设置 close-on-exec 标志的文件描述符。

这个“文件描述符默认不关”的特性特别容易被忽略。比如你在父进程里打开了一个日志文件，fork 之后子进程继承了这个 fd，然后 exec 跑了一个新程序。新程序照样可以往这个 fd 里写东西，因为 fd 没有被关闭。后面的 5.3 我会专门讲到怎么利用这个特性做 shell 重定向，以及怎么用 FD_CLOEXEC 来阻止它。

1.3 为什么 exec 成功没返回值，失败才返回 -1

很多从普通函数入门的人习惯性认为成功返回 0，失败返回 -1。exec 不是这样。它的返回值只有一种可能性：失败。因为一旦 exec 成功，新的程序从入口开始执行，压根没有任何“回到 exec 函数”的机会，返回值自然也就不存在。只有失败时，exec 才会返回 -1，并且设置 errno。所以正确用法是：

if (execv("/bin/ls", args) < 0) { perror("execv failed"); exit(1); }

常见的 errno 有 ENOENT（文件不存在）、EACCES（没有执行权限）、ENOEXEC（文件格式无法识别）、ENOMEM（内存不足）。这对排查问题非常有用：明明写了这个函数，子进程却一片黑屏，先看 errno 往往比读半天 man page 更见效。

2. execl、execlp、execv、execle：四个函数一张表理清

exec 系列不是只有一个函数，而是一族封装。底层真正的系统调用只有 execve，其他几个全是 libc 的包装。理解这一层，至少能回答面试里那个经典问题：“execv 和 execve 有什么区别？”答案是：execve 是系统调用，execv 是调用了 execve 的库函数，后者自动从全局 environ 里取当前环境变量传给内核。

2.1 原型逐个拆解

先看原型，最好把所有这些记在一块：

#include <unistd.h> extern char **environ; int execl(const char *path, const char *arg, ...); int execlp(const char *file, const char *arg, ...); int execv(const char *path, char *const argv[]); int execle(const char *path, const char *arg, ..., char * const envp[]);

另外还有两个常见变体 execvp、execve，一个用 PATH 查找命令名，一个是唯一的系统调用入口。你可以把 execl、execlp、execv、execle 看作在四个维度上的组合：参数按“列表”还是“数组”传递，命令按“路径”还是“PATH 查找”，环境按“继承”还是“自定义”。

2.2 l 与 v：参数列表和参数数组是一回事

l 代表 list，v 代表 vector。参数组织方式不同，实际效果完全等价。举个例子，你想执行 ls -l /tmp，用 execl 就是一个个把参数列出来：

execl("/bin/ls", "ls", "-l", "/tmp", (char *)NULL);

用 execv 则是把所有参数放进一个以 NULL 结尾的字符串数组里：

char *args[] = {"ls", "-l", "/tmp", NULL}; execv("/bin/ls", args);

注意一个特别容易犯迷糊的点：第一个参数 “ls” 并不是真的要传入的文件路径，而是 argv[0]，也就是新程序看到的“命令名”。有些程序的行为会根据 argv[0] 变化，典型例子是嵌入式环境里常用的 BusyBox，同一个二进制通过 argv[0] 决定自己是 ls、cp 还是 mv。所以不要把 argv[0] 写成 NULL，也不要把这个位置省掉，否则新程序拿到的参数就从第二个元素开始，行为会非常诡异。

还需要留意：可变参数的最后一定要以 (char *)NULL 结尾，不是 NULL。这句话我后面会反复强调。原因是 execl、execlp、execle 都是变参函数，变参在类型上不经过编译器检查，如果直接写 NULL，在部分平台上 NULL 会被当成整数 0 传递，而可变形参在 x86-64 上读取整数和指针的位置不同，可能会读到垃圾指针导致段错误。

2.3 p：加了 p 就多了 PATH 查找

execlp 和 execvp 里那个 p 代表 PATH。它们的第一个参数不再要求是完整路径，而是允许只传命令名。比如：

execlp("ls", "ls", "-l", "/tmp", (char *)NULL);

只要环境变量 PATH 里有 /bin，这个调用就会成功。execl 里写 “ls” 通常只能得到 ENOENT，因为它在当前目录找 ls，显然找不到。如果你已经知道命令的绝对路径，想跳开 PATH 查找，就用 execl、execv；如果你想模拟 shell 里直接敲命令名的行为，就选 execlp、execvp。

注意 PATH 查找的细节：如果 file 本身包含斜杠，比如 “/opt/mytool/bin/run”，execlp 会直接把 file 当作路径传给 execve，不再去 PATH 里翻。只有 file 不包含斜杠时，才逐个扫描 PATH 目录。

2.4 e：自定义环境变量的入口

execle 和 execve 把 e 做成了第四个/最后一个维度：可以给新程序指定一份完整的环境变量表。所谓完整，意思是新程序看到的 environ 就是这份表，而不是父进程原来的环境。这个能力在你想为目标程序定制一个干净环境时非常有用，但也意味着你必须自己考虑 PATH、HOME 这类基础变量，否则目标程序可能连命令都找不着。

一份典型的 execle 调用：

char *envp[] = { "PATH=/usr/bin:/bin", "HOME=/home/demo", "LANG=C", NULL }; execle("/usr/bin/env", "env", (char *)NULL, envp);

执行/usr/bin/env可以打印出新程序的环境变量，方便验证。

我把四个函数放在一起比较：

还有 execvp，它就是“PATH 查找 + 参数数组”；execve 是真正的系统调用，其他函数最终都要基于它实现。日常使用写 execvp 的情况反而很多，比如 5.2 里的简易 shell 就靠它。

3. PATH 查找机制手搓演示：理解 execlp 的“偷懒”原理

加了个 p 就自动满世界找可执行文件，这听起来很爽。但作为写代码的人，我建议把 PATH 查找的原理拆开看一眼。原因很实际：一旦你调用 execlp 之前用过 execle 或者随便改过环境变量，PATH 变了，execlp 的行为也会跟着变。不懂底层机制，出了问题只能瞎猜。

3.1 execlp 到底按什么顺序找命令

POSIX 对 execlp/execvp 的要求大致是：先用 getenv("PATH") 拿到路径列表，按冒号分隔成若干目录，依次把文件名拼到每个目录后面尝试执行；如果 PATH 里存在空字符串，比如 “:/usr/bin:/bin”，空字符串代表“当前目录”；如果 PATH 没设置，由具体 libc 决定默认搜索路径，glibc 常见是 /bin:/usr/bin。这点可以作为了解，但不要依赖它，养成自己显式设置 PATH 的习惯更稳。

3.2 自己实现一个简易版 execvp

为了验证上面的逻辑，我平时会让学生手写一个 shim_execvp。它的思路很简单：在 execv 外面套一层路径搜索，遇到包含斜杠的命令直接 execv，否则逐个目录尝试。下面是一个演示版，考虑到篇幅只做单线程假设：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> int shim_execvp(const char *file, char *const argv[]) { /* 如果命令名里面本身带斜杠，就当作路径处理 */ if (strchr(file, '/') != NULL) { execv(file, argv); return -1; } const char *path = getenv("PATH"); if (path == NULL) { path = "/bin:/usr/bin"; } char *path_copy = strdup(path); if (path_copy == NULL) { errno = ENOMEM; return -1; } char *dir = strtok(path_copy, ":"); while (dir != NULL) { size_t len = strlen(dir) + strlen(file) + 2; char *candidate = malloc(len); if (candidate == NULL) { free(path_copy); errno = ENOMEM; return -1; } snprintf(candidate, len, "%s/%s", dir, file); execv(candidate, argv); free(candidate); dir = strtok(NULL, ":"); } free(path_copy); return -1; }

这个版本和 glibc 的真实实现有差距：真实库函数要考虑当前用户是否对目录有执行权限、遇到空路径段时使用当前目录、判断 EACCES 和 ENOENT 哪个错误优先级更高，以及避免 strtok 的不可重入问题。但作为理解机制，它已经足够：所谓 PATH 查找就是“一个目录一个目录试 execv，直到某一次 execv 成功不再返回”。

3.3 命令名可以搜，路径不该随便信

使用 execlp、execvp 时要明白一个边界：它们搜索的是调用进程的 PATH。如果你的程序在 execle 里给目标程序设置了一个很小甚至不合理的 PATH，目标进程再自己去 execlp 时，可能什么都找不到。反过来，如果你在处理用户输入的命令名，特别是一个不可信来源的命令名，不要直接把它丢给 execlp 然后寄希望于 PATH 安全。作为工具开发者，我更倾向于对内部关键路径使用绝对路径调用 execl，避免受外部环境变量影响。

这种对“从哪里找命令”的控制力，是理解 p 修饰符后真正该达成的目标。不是你多记住几个函数名，而是你能预判同样一行调用，在不同 PATH 下会产生哪些不同结果。

4. 环境变量传递与 execle 的完整指南

execle 是题目里四个函数中最难用得顺手的一个，因为它把环境变量表完全交到你手里。如果理解不透，会出现“子进程为什么没有 HOME 了”“为什么 PATH 失效”这类诡异问题。

4.1 environ 与 envp：一个全局变量，一个新程序入口

C 程序里有个全局变量extern char **environ，它默认就是当前进程环境变量的指针数组。任何一个 exec 变体如果没带 e，最终传给新程序的环境就是 environ。execle 传入的 envp 则直接成为新程序的 environ，父进程自己的 environ 不会被带过去。

这引出一个非常核心的认知：execle 的新环境不是“增量修改”，是“整体替换”。如果你想保留父进程一大半环境、只改其中几个变量，必须自己拼接新数组。这也是很多人第一次用 execle 时踩坑的地方：以为它和 setenv 差不多，结果新程序的环境变成了一穷二白。

4.2 用 execle 给目标程序准备一份干净环境

我经常需要跑一些隔离测试程序，希望它们不要受当前 shell 里一堆奇奇怪怪的变量影响。这时候 execle 就是顺手工具：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(void) { char *envp[] = { "PATH=/usr/bin:/bin", "LANG=C", "RUN_MODE=test", NULL }; pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } if (pid == 0) { execle("/usr/bin/env", "env", (char *)NULL, envp); perror("execle"); _exit(127); } /* 父进程等待子进程结束 */ int status; waitpid(pid, &status, 0); return 0; }

你可以编译运行，输出里只会看到 PATH、LANG、RUN_MODE 这三个变量。用来验证环境变量到底传成了什么样，/usr/bin/env是最好的调试工具。

4.3 想继承现有环境再追加变量，怎么拼

实际项目里“保留原有环境，追加几个变量”的需求更常见。思路是遍历 environ，把里面每一个字符串指针复制到一个新数组，最后再拼上你自定义的 KEY=value，以及 NULL 结尾。下面是一个简化示意，生产环境里要注意把 malloc 失败处理好：

#include <stdlib.h> #include <string.h> extern char **environ; char **build_env_with_add(const char *keyval) { int count = 0; while (environ[count] != NULL) { count++; } /* 原有变量 + 1 个新变量 + 1 个 NULL */ char **envp = malloc((count + 2) * sizeof(char *)); if (envp == NULL) { return NULL; } for (int i = 0; i < count; i++) { envp[i] = environ[i]; } envp[count] = (char *)keyval; envp[count + 1] = NULL; return envp; }

然后用的时候：

char **envp = build_env_with_add("APP_LOG_LEVEL=debug"); if (envp == NULL) { perror("malloc"); return 1; } execle("/opt/tools/worker", "worker", (char *)NULL, envp);

因为 environ 里的字符串本身生命周期贯穿整个进程，所以直接拿指针放进新数组没问题。但如果你自己 malloc 出来动态字符串，要保证它在 exec 之前一直有效。

4.4 定制 envp 时最容易忘记的两个东西

我在代码评审里见过太多次这种场景：团队要用 execle 给自己写的后台程序设置一个专属变量，于是 envp 里只写了那一项，结果新程序启动后连 PATH 都没有，程序里一旦调用 system、popen 或者其他 exec 变体就找不到命令。所以只要目标是跑一个相对正常的程序，PATH、HOME、LANG 这类基础变量至少也要给上去，除非你真的想要一个极端精简的裸环境，并且目标程序完全不需要依赖外部命令。

另外，环境变量表里单个字符串必须是KEY=value格式。如果你手滑写了"PATH"而不是"PATH=/usr/bin"，新程序 getenv("PATH") 拿到的值会是非法的，更严重的是有些程序会把这种格式当成不可用，直接走默认行为，你连报错都看不到。

5. 配合 fork 落地：写一个最小 shell 的 exec 部分

讲了这么多，最后自然要落到代码上。我会带着你写一个最精简的“命令执行器”，它能读一行用户输入、把字符串拆成 argv、然后 fork + exec + wait。这个骨架其实就是玩具 shell 的核心。能把这里搞明白，之后看 bash、dash 的源码都不至于迷路。

5.1 标准姿势：fork + exec + wait

一个合格的命令执行函数，至少要做到三点：fork 失败要处理，子进程 exec 失败要立刻退出并返回错误状态，父进程要等待子进程结束并取回退出码。下面是骨架：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> int run_command(char *const argv[]) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return -1; } if (pid == 0) { execvp(argv[0], argv); perror("execvp"); _exit(127); } int status; if (waitpid(pid, &status, 0) < 0) { perror("waitpid"); return -1; } if (WIFEXITED(status)) { return WEXITSTATUS(status); } if (WIFSIGNALED(status)) { printf("child terminated by signal %d\n", WTERMSIG(status)); } return -1; }

这里的 execvp 之所以用 v，是因为命令参数天然就是一个数组；之所以用带 p 的版本，是因为用户输入的是ls而不是/bin/ls，符合 shell 的直觉。如果这一层明显要执行固定路径的内部工具，不要用 p，直接 execv 更可控。同样，错误出口用 _exit(127) 而不是 exit(127)，127 是 shell 习惯里“命令找不到”的退出码。子进程 exec 失败后，原来 fork 出来的进程已经没有继续跑父进程代码的必要了，立刻退出是最干净的选择。

5.2 拆一行命令，喂给 execvp

命令拆分的完整工程化做法要考虑引号、转义、管道符，但这里我只处理最简单的按空格拆分。用 strtok 比较粗暴，但在演示场景足够：

#define MAXLINE 1024 int main(void) { char line[MAXLINE]; printf("demo$ "); fflush(stdout); while (fgets(line, sizeof(line), stdin) != NULL) { line[strcspn(line, "\n")] = '\0'; char *argv[64]; int argc = 0; char *tok = strtok(line, " "); while (tok != NULL && argc < 63) { argv[argc++] = tok; tok = strtok(NULL, " "); } argv[argc] = NULL; if (argc > 0) { run_command(argv); } printf("demo$ "); fflush(stdout); } return 0; }

注意命令行提示符后面紧跟的 fflush(stdout)。如果你不刷新，很可能提示符还没打到终端就会卡在 fgets 等待用户输入，看起来像程序“死”了。这种小问题看着低级，但在交互程序里非常容易遇到。用 fgets 而不是 gets 或 scanf("%s")，是为了避免缓冲区溢出和吞空格的问题。输入的空行会被 argc == 0 过滤掉，不执行任何命令。

这个玩具 shell 已经能解析ls -l /tmp这样的命令，并且让 ls 正常输出。你可以编译跑一下，体验到“喂参数、执行、返回退出码”的完整闭环。

5.3 文件描述符为什么在 exec 之后还活着

经常有学员问我：exec 之后整个进程映像都被换掉了，为什么打开的文件描述符没丢？因为文件描述符表位于内核中，属于进程的内核数据结构，不在用户态内存里。exec 只换用户态地址空间，不重建文件描述符表。这既是坑，也是机会。

坑在于：如果你在父进程里打开了数据库连接、网络 socket、临时文件，没有设置 close-on-exec，子进程 exec 跑别的程序后，这些 fd 依然存在，既不能释放，还会增加误操作风险。严谨一点的工具会在每个可能 exec 的目标进程里检查已打开的 fd 有没有超出预期。如果希望某个 fd 在 exec 时自动关闭，可以在 open 时加上 O_CLOEXEC，或者事后用 fcntl 设置 FD_CLOEXEC：

int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); fcntl(fd, F_SETFD, FD_CLOEXEC);

机会在于，shell 的重定向就是靠“子进程先改 fd，再 exec”实现的。你只需要在子进程 exec 之前，把想要重定向的目标 fd 用 dup2 放到标准输出的位置：

if (pid == 0) { int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); _exit(1); } dup2(fd, STDOUT_FILENO); close(fd); execl("/bin/ls", "ls", "-l", (char *)NULL); _exit(127); }

恰好是因为 exec 不关闭普通 fd，dup2 之后即使执行了 ls，标准输出也仍然指向 out.txt 这个文件。很多人写 shell 重定向一头雾水，根源就是没想明白 fd 表在新旧程序之间是连续存在的。理解这条，你才算真正把 exec 机制串起来了。

5.4 缓冲区陷阱：exec 前 printf 没刷新，内容直接丢了

C 标准库的 stdio 缓冲是用户态数据，exec 替换地址空间时不会帮你把缓冲区里的内容“保存”下来。最常见的翻车现场：

printf("before exec"); execl("/bin/echo", "echo", "hi", NULL);

如果 stdout 是行缓冲，前面那句没有换行就执行 exec，exec 成功后缓冲区被丢弃，“before exec”永远打不到终端。不是它没执行，而是它待在了一个已经消失的缓冲区里。解决办法很简单：在 exec 前补个换行或者 fflush(NULL)。

更隐蔽的版本是在 fork 前打印了东西。fork 会把缓冲区也复制一份，结果父进程和子进程各有一份相同内容，最后输出可能打两次。如果子进程还要 exec，同样存在旧缓冲被丢弃的问题。所以我的习惯是：涉及 fork/exec 的程序里，打印重要日志尽量加换行，或者在 fork 前主动 fflush。特别提醒，子进程 exec 失败后也别用 exit 清理父进程留下的缓冲区，直接 _exit 更安全。exit 会刷新当前进程所有 stdio 缓冲，可能在子进程里把父进程的数据写重。

5.5 我在实际项目里见过的 exec 误用案例

用错第一参数。有人写 execl("ls", "ls", NULL)，然后百思不得其解为什么 ENOENT。原因就是第一参数必须是路径，不是命令名。要么写成 /bin/ls，要么改用 execlp。这类问题用 strace 一看就明白，execve 系统调用确实传入了 “ls” 这个相对路径。

忘记可变参数结尾。execl 系列参数数量不固定，必须用 (char *)NULL 告诉函数“参数到底到哪结束”。漏掉之后，函数会继续沿着栈把后面无关数据当成参数指针，轻则参数错乱，重则段错误。这个坑我见过不止一次，还特别难查，因为编译能过，运行也未必稳定。

子进程 exec 失败后继续跑父进程代码。有些人写完 fork 后不做错误判断，exec 失败又直接 return，结果父子进程一起往下执行，把日志写两遍。标准做法是 exec 之后立即 perror 然后 _exit，不要让子进程顺着往下跑。

被环境变量坑。给 execle 传了一个漏掉 PATH 的环境数组，新程序一执行外部命令就失败。如果你做的只是“继承父进程环境再追加”，可以用 4.3 的方式构建数组，但至少要确认 PATH 存在。

在常用路径上放了一个同名的假程序。因为 execvp、execlp 会按 PATH 查找，如果你的程序允许用户设置 PATH 或者当前目录在 PATH 里排最前，别人可能在当前目录放一个和系统命令同名的可执行文件，你的工具一执行就被“劫持”。对于安全敏感的关键程序，我宁可写死绝对路径用 execv，也不要依赖“环境像预期那样”。

把所有这些串起来，你会发现 Linux 进程替换并不复杂，只是细节密度高。真正熟手和初学者的区别，不在于背下来四个函数原型，而是在遇到子进程行为诡异时，能迅速判断出是参数传递问题、PATH 问题、环境变量问题还是缓冲区问题。我的建议是读完这篇文章后，亲手把 3.2 的 shim_execvp 和 5.2 的玩具 shell 都写一遍，再故意制造几个错误跑一跑。等你能准确预测 exec 函数在每种情况下的返回值、errno 和输出位置，这套机制就真的长在你手里了。