1.1 从一个常见场景说起先抛一个问题你在终端里敲下ls -l然后回车shell 是怎么把这个命令变成实际运行结果的如果你写过一点 C 语言大概知道fork()能创建子进程但fork出来之后子进程执行的还是父进程那套代码它凭什么去执行/bin/ls这个程序答案就是标题里的“进程程序替换”。Linux 下进程控制的基本套路是fork创建子进程子进程调用exec系列函数把自己替换成一个全新的程序父进程负责wait等待并回收子进程。整个过程就是 shell、服务框架、脚本解释器这些程序的核心机制。这篇文章我会把这套机制讲透包括 6 个替换函数的区别、每个参数怎么传、什么时候用哪个、踩过哪些坑适合正在学 Linux 系统编程、准备面试或者想自己写一个 mini shell 的读者。1.2 fork 之后为什么不直接运行新程序先说fork的本质。fork调用一次返回两次它在内核里把当前进程的地址空间复制出一份包括代码段、数据段、堆、栈、打开的文件描述符、信号处理方式等然后把这个副本变成一个调度单位也就是子进程。子进程从fork返回处继续执行和父进程的代码路径完全重合。这里有一个痛点如果子进程只能继续跑父进程的代码那命令行这个生态就根本建立不起来。你敲lsshell 需要的是一个“变成 ls 程序”的子进程而不是一个“继续执行 shell 逻辑”的子进程。虽然理论上可以靠大量条件判断和函数调用来模拟出 ls 的行为但这完全不可行——你不可能把系统里几百个命令全部内嵌进 shell 里。所以fork只管“复制”exec才负责“变换”。两者是一对黄金搭档。实际写代码时的顺序非常固定先fork在子进程分支里调用exec然后父进程wait。这也是为什么几乎所有讲进程控制的资料都把fork和exec放一起讲——单独拎出来任何一个都解释不了完整的命令行执行流程。1.3 替换的本质进程地址空间的整体置换现在说“替换”到底替换了什么。exec系列函数的核心动作是用一个新的可执行文件把当前进程的代码段、数据段、堆、栈全部替换掉然后重新初始化这些区域最后跳到新程序的入口点开始执行。打个比方fork就像你用复印机复制了一份自己的简历纸张、字体、排版都一样exec则是把这份复印件放进碎纸机重新打印一份内容完全不同的简历但文件柜的编号PID没变。进程还是那个进程PID 不变打开的文件描述符默认也不关但进程“内在”的代码和数据已经整容成了新程序。这个设计很精巧。因为内核只要重新做地址空间的映射和初始化不需要重新创建 task_struct、不需要重新分配 PID省掉了一大堆进程创建的开销。exec之后的进程如果执行结束退出状态仍然能通过wait被父进程拿到因为父子关系没有变过。注意exec调用成功后当前进程的代码中exec之后的所有语句都不会执行了。如果某个系统调用成功返回了那它一定没调用成功。这个逻辑看起来很绕但理解了“地址空间整体替换”就很好懂——调用成功后当前进程的指令流已经跳到了新程序的入口旧代码的后续指令都被清掉了根本不可能回来继续跑。2. exec 家族全景6 个替换函数的区别2.1 exec 全家福Linux 的exec是一族函数最常用的有 6 个原型如下函数是否使用 PATH 搜索参数形式环境变量说明execl否需完整路径可变参数列表继承当前环境参数以逗号分隔最后以 NULL 结尾execlp是可变参数列表继承当前环境带 p表示会去 PATH 里找execle否需完整路径可变参数列表自定义环境变量参数列表最后额外传入 envpexecv否需完整路径字符串数组继承当前环境参数以数组形式传递execvp是字符串数组继承当前环境数组形式 PATH 搜索execve否需完整路径字符串数组自定义环境变量真正的系统调用记忆口诀就三个维度l / v、p / 无 p、e / 无 e。l是 list参数用可变参数列表逐个传v是 vector参数全部放到一个指针数组里传p表示有 PATH 环境变量搜索能力e表示可以手动传入环境变量数组。2.2 l 和 v 的区别参数到底怎么传l系列写起来直观像这样execl(/bin/ls, ls, -l, /home, NULL);第一个参数是程序路径第二个参数ls是传给新程序的argv[0]后面-l、/home是argv[1]、argv[2]最后必须用一个NULL表示参数结束。v系列则要求先把参数放进一个数组char *argv[] {ls, -l, /home, NULL}; execv(/bin/ls, argv);数组的最后一个元素也必须是NULL。实际项目里命令参数不可能写死往往来自用户输入、配置文件或者解析出来的参数列表这时用v系列更方便——你只需要动态构造一个char *数组就行而不是在代码里拼一长串参数。我见过不少初学者在execl里忘记最后那个NULL结果程序直接崩溃或者行为诡异。因为exec内部要用这个NULL判断参数边界没有它内核就会一直往后读直到读到某个碰巧是空指针的内存位置。这种 bug 极难排查所以我把这条放在第一条避坑提醒里。2.3 p 的作用PATH 搜索p系列execlp、execvp最大的好处是程序路径不用写全只需要给程序名内核会按 PATH 环境变量里列出的目录逐个去找。execlp(ls, ls, -l, NULL); // 不需要写 /bin/ls execvp(gcc, argv); // 不需要写 /usr/bin/gcc这个特性特别适合写“像命令行一样工作”的程序。你在终端敲的任何命令本质上都是靠 PATH 搜索找到可执行文件的。如果你写一个 mini shell用execvp是最省事的——用户传什么命令名你就原样扔给execvp它自动去 PATH 里找找到就能跑找不到返回 -1。但要注意p系列的行为细节它只在 PATH 里找如果你传的是一个包含/的字符串比如./hello那它就直接把这个字符串当作路径去执行不会再走 PATH 搜索。这一点经常被忽略导致execvp(./my_prog, argv)这种代码行为符合预期而execvp(my_prog, argv)能不能跑完全取决于当前环境 PATH 里有没有包含当前目录。2.4 e 的作用自定义环境变量e系列execle、execve允许你给新程序指定一份全新的环境变量而不是继承当前进程的环境。char *env[] {MY_NAMEzhangsan, MY_FLAG1, NULL}; execle(/bin/bash, bash, -c, echo $MY_NAME $MY_FLAG, NULL, env);bash -c后面的字符串会被 bash 当成命令执行这里用自定义环境变量MY_NAME和MY_FLAG就能在子进程里看到它们。如果这些变量没在当前环境中定义普通execl是传不进去的但execle就可以。什么时候用e典型场景是你不想让子进程继承父进程的所有环境变量尤其是某些可能泄露敏感信息的变量或者你想给子进程构造一个干净的运行环境。还有一个常见需求是给脚本程序传环境变量——脚本里的代码能读到的环境变量完全取决于启动它的进程用exec时传了什么。2.5 execve 是系统调用其余都是封装这 6 个函数里只有execve是真正的系统调用其他 5 个都是 libc 对execve的封装。你可以用man 2 execve查看系统调用本身用man 3 execl查看封装函数的说明。execve的原型是int execve(const char *pathname, char *const argv[], char *const envp[]);其他函数最终都会把参数整理成argv和envp然后调用execve。比如execlp内部要先把可变参数列表收集成数组再查找 PATH最后落到底层还是execve。理解这一点对你调试很有帮助遇到奇怪的错误直接去看execve的手册它是最本质的接口。提示exec系列函数名称后面有没有e决定了是否能自定义环境变量有没有p决定了是否走 PATH 搜索是l还是v决定了参数的组织形式。三者是独立的所以组合出 6 个函数少一个都不行。3. 实操把 6 个替换函数各写一遍3.1 环境准备开始之前确保你的环境里装了 gcc 和常用的系统工具。我用的是 Ubuntu/Debian 系列其他发行版操作也差不多sudo apt update sudo apt install gcc build-essential -y所有代码都放在一个文件里分函数测试或者拆分成多个.c文件都行关键是每个测试程序都编译运行一遍观察输出。文件命名随意我习惯叫exec_test.cvim exec_test.c gcc exec_test.c -o exec_test ./exec_test3.2 用 execl 替换最简单的一版先写一个最直接的替换调用。程序先打印自己然后把自己替换成ls#include stdio.h #include unistd.h #include stdlib.h int main() { printf(替换前我是一个进程PID%d\n, getpid()); execl(/bin/ls, ls, -l, /home, NULL); // 以下代码只有 exec 失败才会执行 perror(execl 失败); exit(EXIT_FAILURE); }编译运行后你看到的输出是替换前我是一个进程PID12345 总用量 ... drwxr-xr-x ... user user ... home1中间没有打印execl 失败说明调用成功了。这里有个细节值得注意进程 PID 在你execl前后是同一个数但“替换前”的 printf 是原程序的代码后面输出的是/bin/ls的代码它们属于两个程序却共享同一个 PID。这就是我前面说的“文件柜编号不变柜子里内容换了”。如果我把代码改成一个不存在的路径execl(/no/such/file, ls, -l, NULL);那execl就会返回 -1你就能看到perror打印的错误信息No such file or directory。与此同时后面的exit会执行程序退出。这也验证了一个知识点exec如果成功进程直接“变身”不返回如果失败返回值是 -1你可以在原进程中继续处理错误。3.3 用 execlp 体验 PATH 搜索把上一节的execl改成execlp只改函数名和第一个参数#include stdio.h #include unistd.h #include stdlib.h int main() { printf(准备执行 ls\n); execlp(ls, ls, -l, /home, NULL); perror(execlp 失败); exit(EXIT_FAILURE); }这里第一个参数是ls而不是/bin/ls。内核会按 PATH 去搜索ls这个可执行文件。你可以打印一下PATH变量看看里面有哪些目录echo $PATH常见的是/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin之类的内核按顺序在每一个目录里找ls找到就执行。如果你运行后又改了 PATH把/bin排除再用execlp(ls, ...)就有概率失败——这在实际调试中是个非常隐蔽的坑我后面会专门讲。3.4 用 execv 和 execvp 传递参数数组参数多的时候一个个写在execl里太痛苦改成数组会清晰很多#include stdio.h #include unistd.h #include stdlib.h int main() { char *argv[] {ls, -l, -a, /etc, NULL}; printf(准备执行 ls -l -a /etc\n); execv(/bin/ls, argv); perror(execv 失败); exit(EXIT_FAILURE); }argv[0]按惯例是程序名但内核其实并不强制它和真实文件名一致。你可以故意写char *argv[] {我不是ls, -l, NULL}; execv(/bin/ls, argv);执行仍然正常只不过在进程列表里这个进程显示出来的名字是“我不是ls”。部分程序会用argv[0]决定自己的行为比如busybox就是根据argv[0]知道自己是ls还是cat的。这个机制在做一些工具包装时很有用但面试时也经常拿来考你。execvp与execv的区别和execlp与execl的区别一样就是多了 PATH 搜索。代码只需要把第一行改成execvp(ls, argv);3.5 用 execle 自定义环境变量#include stdio.h #include unistd.h #include stdlib.h int main() { char *env[] { MY_NAMEzhangsan, MY_ENVhello_world, NULL }; printf(准备执行 bash打印自定义环境变量\n); execle(/bin/bash, bash, -c, echo MY_NAME$MY_NAME MY_ENV$MY_ENV, NULL, env); perror(execle 失败); exit(EXIT_FAILURE); }编译运行后你应该在输出里看到MY_NAMEzhangsan MY_ENVhello_world这表明bash进程读取到了execle传入的自定义环境变量。如果你用普通execl去执行同样命令因为当前 shell 环境里根本没有MY_NAME你看到的就只是MY_NAME MY_ENV。这个特性在跑 CI/CD 脚本时特别常用——你想让某个脚本只看到特定的几个环境变量而不是继承宿主机的所有变量。用execle把环境变量“洗干净”能减少很多因为环境差异导致的不可复现 bug。3.6 execve直接触碰系统调用最后是真正的系统调用。直接用execve把上面几个函数的功能压成一行#include stdio.h #include unistd.h #include stdlib.h int main() { char *argv[] {ls, -l, /home, NULL}; char *env[] {PATH/usr/bin:/bin, NULL}; printf(准备通过 execve 执行 ls\n); execve(/bin/ls, argv, env); perror(execve 失败); exit(EXIT_FAILURE); }这里的env只给子进程准备了一个 PATH如果ls在运行中需要读取其他环境变量比如LANG那它看到的就是空或默认值。这在实际中会引发各种微妙的行为差异比如中文环境下ls正常显示总用量而在没有LANG的环境里显示英文。这也是为什么系统设置环境变量那么讲究——程序跑得好不好不只是可执行文件本身的问题还依赖运行环境。4. fork exec子进程与父进程的标准配合4.1 为什么必须配对使用如果只调exec当前进程就“变身”成新程序了调用者自己也就没了。这通常不是我们想要的——shell 想要的是fork 出一个子进程让子进程去执行用户命令自己留下来继续等待输入。所以标准模式就是fork()创建子进程。子进程分支里调用某个exec函数。父进程分支里调用wait或waitpid等待子进程结束。这样父进程和子进程各司其职。你想想看如果没有fork你敲一个ls命令shell 自己就变成ls了命令执行完shell 也没了。那整个命令行交互就崩溃了。fork的价值就在于提供了“分身”让父进程可以稳定地等待和处理子进程的退出。4.2 代码示例父进程等待子进程写一个完整的例子模拟最朴素的 shell 行为#include stdio.h #include unistd.h #include sys/wait.h #include stdlib.h int main() { pid_t pid fork(); if (pid 0) { perror(fork 失败); exit(EXIT_FAILURE); } if (pid 0) { // 子进程执行 ls printf(子进程 PID%d 开始执行\n, getpid()); execl(/bin/ls, ls, -l, NULL); // 如果 exec 失败子进程自己处理并退出 perror(子进程 exec 失败); exit(EXIT_FAILURE); } else { // 父进程等待子进程 int status; printf(父进程 PID%d 等待子进程 %d\n, getpid(), pid); waitpid(pid, status, 0); if (WIFEXITED(status)) { printf(子进程已退出退出码%d\n, WEXITSTATUS(status)); } else { printf(子进程不是正常退出的\n); } } return 0; }编译运行后输出类似父进程 PID100 等待子进程 101 子进程 PID101 开始执行 总用量 ... ... 子进程已退出退出码0注意顺序不一定总是这样因为父子进程是并发调度的输出顺序会有随机性。但你观察核心逻辑父进程被waitpid阻塞直到子进程的ls跑完才继续。这就是“进程控制”最基础也最重要的骨架。4.3 理解进程替换不回退的特性有个新手经常搞混的点exec成功之后子进程就完全变成新程序了它无法再回到原来的分支继续执行。也就是说exec调用之后的任何代码子进程都不会执行除非exec失败。看这段代码if (pid 0) { printf(A\n); execl(/bin/ls, ls, NULL); printf(B\n); // exec 成功时不会执行 }如果execl成功了你只能看到A和ls的输出看不到B。如果你在某次调试中看到了B那基本可以断定exec失败了而且你错误地忽略了返回值。这也是为什么我习惯在exec后面紧跟一个perror和exit——既能兜底错误又能让代码逻辑清晰。4.4 替换失败时子进程必须自己退出如果exec失败子进程仍然活着并且会继续执行exec之后的代码。如果你不处理子进程可能继续跑fork分支之后的父子共用代码导致逻辑混乱严重的还会造成资源泄漏。所以在子进程分支里exec之后必须加上perror(exec 失败); exit(EXIT_FAILURE);这样即使exec失败子进程也立刻退出退出码非 0让父进程的waitpid拿到一个明确的失败信号。这既是代码习惯也是工程上保证健壮性的关键点。5. 常见问题与排查技巧5.1 找不到文件还是权限不足exec系列函数失败时会将errno设置为具体的错误码。最常见的几个errno 值含义排查方向ENOENT文件或目录不存在检查路径是否写全PATH 里是否有该目录EACCES权限不足或不可执行检查文件是否有执行权限ls -l查看ENOEXEC文件格式无法识别检查是不是可执行文件是不是架构不对E2BIG参数或环境变量过大参数列表太长或环境变量太多ENOMEM内存不足系统资源紧张检查命令我喜欢一条一条试ls -l /bin/ls # 看权限 file /bin/ls # 看文件类型 echo $PATH # 看 PATH 是否包含该目录5.2 exec 成功了但后面的代码还执行了如果你发现exec之后的代码确实执行了那必然是因为exec返回了 -1。这时候你要检查是不是没包perror是不是把返回值忽略了。还有一种可能你在execlp或execvp里传了一个带/的相对路径比如./script.sh但该脚本没有可执行权限或者脚本第一行的解释器路径写错了。这也会导致exec失败但你看到的现象是“程序没有执行预期动作反而继续往下跑了”。5.3 环境变量丢失用execle或execve自定义环境变量后发现程序读取不到某些变量。先检查envp数组最后一个元素是不是NULL再检查新程序是不是依赖了 PATH、HOME、LANG 等基础变量。如果你只传了两个自定义变量那新程序基本处于“荒野求生”模式很多动态库和工具都找不到路径。稳妥做法是把基础变量也加进去char *env[] { PATH/usr/bin:/bin, HOME/home/user, LANGC.UTF-8, MY_NAMEzhangsan, NULL };5.4 参数拼接的常见错误sprintf或snprintf拼接argv时最容易出现的问题是忘记给参数数组结尾加NULL。在 C 语言里数组越界读是一种未定义行为有时碰巧不报错有时就段错误极难排查。我的习惯是构造参数数组的代码单独抽一个函数函数末尾统一argv[argc] NULL;绝不依赖调用方是否记得补 NULL。5.5 定位手段strace 和打印排查exec类问题strace是神器。它能跟踪系统调用直接看到execve传了什么参数、返回了什么错误strace -f -e execve ./exec_test-f表示跟踪子进程-e execve表示只看execve调用。输出里会清晰列出execve(/bin/ls, [ls, -l], 0x7ffc... /* 62 vars */) 0一眼就能看出路径、参数、环境变量对不对。另外在代码里用fprintf(stderr, ...)打印关键变量的值也很有用特别是打印 PATH 和构造好的 argv 数组。多打几个日志问题往往就能定位。注意当你在代码里使用exec时建议用perror包裹不要用printf。因为perror会把errno对应的可读错误信息打印出来而printf不会自动附加错误描述排查时少一步换算。6. 实际应用从 shell 到服务框架6.1 写一个迷你 shell用forkexecvpwaitpid三件套你就能实现一个最简单的 shell 核心。思路不断读取用户输入解析出命令名和参数构造argvfork出子进程后execvp父进程wait。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h #define CMD_MAX 1024 int main() { char cmd[CMD_MAX]; while (1) { printf(mysh$ ); fflush(stdout); if (fgets(cmd, sizeof(cmd), stdin) NULL) { break; } cmd[strcspn(cmd, \n)] \0; // 去掉换行符 if (strcmp(cmd, exit) 0) { break; } pid_t pid fork(); if (pid 0) { perror(fork); continue; } if (pid 0) { // 子进程解析命令 char *argv[CMD_MAX]; int argc 0; char *token strtok(cmd, ); while (token ! NULL) { argv[argc] token; token strtok(NULL, ); } argv[argc] NULL; if (argc 0) { execvp(argv[0], argv); perror(execvp); exit(EXIT_FAILURE); } exit(EXIT_SUCCESS); } else { waitpid(pid, NULL, 0); } } return 0; }这段代码虽然简陋但已经能执行ls -l、pwd这类基础命令。真实 shell 还要处理管道、重定向、后台任务、内置命令等但内核交互的骨架就是fork exec wait。面试官问“shell 是怎么执行命令的”你把这套逻辑讲清楚就赢了一大半。6.2 服务程序拉起子进程很多服务程序需要启动外部工具比如 Web 服务需要调用ffmpeg转码、需要调用git拉代码、需要调用python跑脚本。这些场景下服务进程不能把自己替换成子程序必须通过fork隔离。常用的姿势是父进程fork出子进程子进程执行外部工具父进程用waitpid等待并获取退出码。如果子进程执行时间很长父进程还可以用非阻塞方式轮询状态或者用 SIGCHLD 信号通知。实际工程中还要注意环境变量的传递。服务程序通常会有自己一套精心构造的运行环境用execve精确控制传给子进程的环境变量能避免很多安全问题和兼容性问题。比如禁止子进程继承敏感 token或者指定固定的 PATH 防止被注入恶意命令。6.3 解释器与脚本处理脚本文件的第一行#!/bin/bash或者#!/usr/bin/python3内核是怎么处理的答案是当你执行一个脚本时内核发现文件格式不对不是 ELF会检查第一行提取解释器路径然后相当于调用execve(解释器路径, [解释器路径, 脚本路径, 参数...])。所以你可以理解为内核执行脚本的过程本质上就是一次 “exec 替换成解释器程序” 的过程。这也是为什么脚本需要有可执行权限但脚本文件本身不需要是 ELF。如果你写了一个自定义解释器你也能在脚本开头用#!/path/to/my_interpreter把它接上。6.4 安全注意事项PATH 劫持与权限execvp依赖 PATH 搜索这也带来了一个安全风险如果 PATH 里包含了可被普通用户写入的目录比如当前目录.攻击者就能放一个同名的恶意程序诱导合法程序执行。比如某个 root 服务调用了execvp(ls, ...)而管理员粗心把.加进了 PATH那用户可能在某个目录里放一个假的lsroot 进程一执行就中招。应对措施服务程序里尽量用绝对路径调用exec而不是execvp。如果必须用 PATH确保 PATH 里的每个目录都是可信的把.去掉。特权进程切换到低权限用户后再执行外部命令降低影响面。另外exec会丢弃被捕获的信号处理函数信号处理重置为默认行为部分信号如SIGCHLD的阻塞状态也会被重置。这在设计守护进程时要特别小心别以为子进程会继承你精心设置的信号处理逻辑。提示从安全角度讲execve是最可控的入口路径明确、环境变量明确、参数明确。凡是涉及到不可信输入的启动逻辑都建议用execve而不是execvp至少在架构上避免 PATH 注入的可能性。结尾一点实操体会我在学习和调试这些函数的时候最大的感受是纸上谈兵一百遍不如亲手写个迷你 shell 跑一遍。fork之后子进程里调用exec然后父进程wait这套配合反复写你对“进程”这个概念的理解会发生质变——它不再是教科书里干巴巴的定义而是一段可以被替换、被回收、被等待的实体。如果你正在准备面试建议把exec的 6 个函数差异、fork与exec为什么成对出现、exec成功返回值和失败返回值的行为、环境变量传递机制这四个点讲清楚基本就能覆盖大多数进程控制题目。如果实际工作中要写高可靠的服务再深入学一下子进程退出码管理、SIGCHLD信号、僵尸进程回收这些是下一个阶段的功课。最后再分享一个小技巧写任何调用exec的代码之前先在终端用which ls、echo $PATH确认环境和路径这比在代码里瞎猜能省下大量排查时间。