【Linux系统】【Linux 进程程序替换机制解析及自定义 Shell 核心逻辑实现 】流食般投喂

Linux 进程程序替换与自定义 Shell 实现：从 exec 原理到手写命令解释器

课程主题：Linux 进程程序替换机制解析及自定义 Shell 核心逻辑实现
技术栈：C/C++ 混合编程、Linux 系统调用（fork, exec, wait）

你有没有想过，当你在终端敲下 ls -a -l 时，操作系统到底在背后做了什么？本章节带我们撕开 Shell 的神秘面纱，用大约 100 行代码，亲手打造一个能执行系统命令的简化版 Shell。

这不仅是一次编码练习，更是对“进程、程序替换、命令行参数、环境变量”这些散落概念的系统性串联。

一、进程程序替换：不是“新建”，而是“夺舍”

1.1 核心原理：覆盖式载入，PID 不变

进程程序替换的本质，并非创建新进程，而是将目标程序的代码和数据覆盖式地载入当前进程的代码段和数据段。换句话说，进程还是那个进程（PID 保持不变），只是“灵魂”被换掉了。

老师在课堂上写了一段最简单的验证代码：前半段打印自己的 printf，后半段调用 execl 执行 ls。运行时你会发现，前半段正常输出，后半段直接变成了 ls 的输出——原始代码后半部分被物理覆盖掉了，再也回不来了。

为了从操作系统层面验证“未创建新进程”，老师故意让子进程先打印自己的 PID，再 execl 替换为一个自编的 C++ 程序 other.cc，让 other.cc 也打印自己的 PID。两个 PID 完全一致。这就实锤了：exec 只是替换了执行上下文，没有新建 PCB。

小知识点：exec 系列接口在底层属于“加载器”范畴。我们平时在命令行启动的进程，本质都是 bash 这个“父进程”先 fork 出子进程，再 exec 替换加载新程序。

1.2 返回值特性：只有失败才返回

这是一个极其反直觉的设计：exec 系列函数只有失败时才返回 -1；一旦成功，新程序直接接管当前进程，原函数调用点之后的代码永远不会执行（被物理覆盖了）。

课堂上老师特意演示了“故意写错路径”的实验：

int n = execl("/usr/bin/lsss", "lsss", NULL); // 故意写错
printf("%d\n", n); // 只有当替换失败时，这行才会执行，输出 -1

基于这个特性，代码里完全不需要对成功返回值做判断。优雅的写法是：

execl(...);
// 如果执行到这行，说明必定失败了
exit(1);

1.3 进程独立性：子进程替换不影响父进程

如果你直接在原进程里做程序替换，原进程自己的代码就没了。那如果只想“派个人去执行命令”，自己继续干活呢？

答案是：fork 创建子进程，让子进程去执行替换，父进程继续 waitpid 等待。

老师在这里抛出了一个关键的细节问题：子进程本来和父进程共享代码和数据段，那子进程做程序替换，会不会把父进程的代码也覆盖掉？

答案是不会。得益于**写时拷贝（Copy-on-Write）**机制，一旦子进程进行程序替换，操作系统会为子进程重新分配独立的代码区和数据区，让它彻底与父进程分离。这再次验证了进程的独立性。

二、exec 家族全解析：命名有规律，选型看场景

Linux 提供了 7 个 exec 相关接口，其中 6 个是 C 库封装，只有 execve 是真正的系统调用，其余最终都会汇聚到它。接口命名遵循一套清晰的语义规则：

2.1 接口对比与实验

课堂上老师带着我们逐一实验了多个接口：

① execl：完整路径 + 列表传参

execl("/usr/bin/ls", "ls", "-a", "-l", NULL);

第一个参数是“我要执行谁”（带路径），从第二个参数开始是“我想怎么执行它”。即便你写成 execl("/usr/bin/ls", "ls", "-al", NULL) 也能运行，但标准写法建议把命令行怎么写，参数就怎么拆开来传。

② execlp：PATH 查找 + 列表传参

execlp("ls", "ls", "-a", "-l", NULL);

带 p 就意味着第一个参数只需要文件名，不需要路径。系统会自动去 PATH 环境变量里找。

小知识点：有同学问，这里写了两遍 "ls" 是不是重复？完全不冲突。第一个 "ls" 是告诉系统“我要执行谁”，第二个及以后的 "ls" 是告诉系统“我想怎么执行它”。语义不同，只是凑巧字符串相同。

③ execv：完整路径 + 数组传参

char *argv[] = {"ls", "-a", "-l", NULL};
execv("/usr/bin/ls", argv);

v 就是 vector/数组。当你已经有了一个参数数组时，用 v 系列更自然。

④ execvp：Shell 实现的首选推荐

execvp("ls", argv);

这是自定义 Shell 时最推荐的接口。因为命令行解析后，参数天然就是数组结构；同时 Shell 命令通常依赖 PATH 查找，带 p 正好省去手动拼路径的麻烦。

⑤ execvpe：环境变量的“覆盖式”传递

这是课堂上最烧脑的一个实验。老师写了一个 other.cc，让它打印自己的命令行参数和环境变量。然后在父进程里用 execvpe 执行它，并手动构造了一个只包含 my_env_val=123456789 的环境变量数组传进去。

结果令人惊讶：other.cc 打印出的环境变量只剩下了我们手动传入的那一个，历史上从 bash 继承下来的所有环境变量全部消失了！

这说明：带 e 的接口，如果你显式传入环境变量，它会用你传入的全新列表直接覆盖子进程的环境变量。

那如何让子进程“新增”环境变量，同时保留老的呢？老师给了两种做法：

• 做法一（推荐增量）：在当前进程（父进程或子进程）里调用 putenv("new_var=value") 把新环境变量导入到当前上下文（新增），再调用不带 e 的 execvp（不传环境变量表，子进程就拿父进程的那张老的环境变量表）。此时函数内部会默认把当前进程的 environ 指针传给目标程序，子进程自然就能看到“老的 + 新增”的完整环境变量。
• 做法二（显式拼接）：先用 putenv 导入新变量，再把全局的 extern char **environ 作为参数传给带 e 的接口。这样你传的就是一个已经包含了新增变量的完整环境表。（老的、新增的，在当前进程中被拼在了一起）

小知识点：即使你不给 exec 接口传环境变量，子进程依然能拿到父进程的环境变量。原因是 C 库封装的 exec 接口内部会默认将当前进程的 environ 指针传给底层的 execve（系统调用这个接口，参数本来就是有环境变量的，上层封装有的有，有的没有，到底层系统调用这，你传了就用你的，没传我就用父进程的）。环境变量和命令行参数一样，本质上都是地址空间上的全局资源，创建子进程时已经随地址空间拷贝过去了。

2.2 命令行参数到底是谁传的？

当 other.cc 成功打印出我们伪造的 -a -b -c -d 参数时，一个贯穿始终的疑惑被解开了：

任何一个进程的 main(int argc, char *argv[]) 参数，是谁传的？

答案：它的父进程通过 exec 系列接口传递的。

无论是 Linux 下的 bash，还是 Windows 下 VS2022 调试运行时作为父进程帮你启动程序，本质上都是父进程 fork 后，通过 exec 加载器把参数塞进子进程的命令行参数表里。这就是 argv 的终极来源。

三、跨语言程序替换：系统级概念的降维打击

程序替换是一个系统级概念，不限于 C 程序调 C 程序。老师在课堂上连续做了三个震撼的实验：

实验 1：C 程序调用 C++ 程序

写了一个 other.cc，编译成二进制。C 父进程直接 execl("./other", "other", NULL) 将其拉起。证明可执行二进制文件可以被无缝替换执行。

实验 2：C 程序调用 Python 脚本

execl("/usr/bin/python3", "python3", "other.py", NULL);

关键点：Python 是解释型语言，真正被加载执行的不是脚本本身，而是 Python 解释器。程序替换替换的是解释器的二进制代码，解释器再去读取脚本逐行执行。

实验 3：C 程序调用 Shell 脚本

execl("/bin/bash", "bash", "other.sh", NULL);

同理，Shell 脚本也需要由 /bin/bash 解释器来执行。

老师总结了一句很精辟的话：“只要目标能在操作系统里转化为进程运行，就能被替换。前端语言（如浏览器里的 JS）做不到，因为那不是操作系统在跑，是浏览器在解释。”

四、自定义 Shell 实现：百行代码洞见本质

理解了 exec 原理，接下来进入终极实战：手写一个简化版 Shell。老师的实现过程极具工程示范性，分为四大模块。

4.1 模块一：命令行提示符生成

Shell 是一个死循环，第一步是打印提示符。我们需要获取三类信息：

• 用户名：getenv("USER")
• 主机名：getenv("HOSTNAME")
• 当前路径：getenv("PWD")

老师特意强调了两个工程细节：

1. 用 snprintf 而非 printf
   因为我们想要的是“把格式化的字符串写进缓冲区”，而不是直接打印。snprintf 是安全的格式化操作，可避免缓冲区溢出。

2. 路径优化：截取当前目录名
   PWD 返回的是全路径（如 /home/user/project/src），但系统 Shell 只显示最后一个目录名。这里老师用了C++ 的 string::rfind 逆向查找最后一个 /，再截取子串。这就是 C/C++ 混编的优势：该用什么就用什么，不必强行用 C 写字符串遍历。

格式化模板类似：[user@hostname dirname]$ 。输出后记得 fflush(stdout) 刷新标准输出，确保提示符及时显示。

4.2 模块二：获取用户输入

这里有一个初学者极易踩的坑：

不要用 scanf！
scanf 以空格为分隔符，你输入 ls -a -l，它只会读到 ls，后面的参数全丢了。

正确做法是使用 fgets` 按行读取：

char command_line[1024];
fgets(command_line, sizeof(command_line), stdin);

读完后必须去除末尾的换行符 \n：

command_line[strlen(command_line) - 1] = '\0';

小知识点：不用担心 strlen 为 0 导致越界。只要用户敲了回车，fgets 至少会读到一个 \n，长度至少为 1。如果用户直接回车，字符串变成空串，后续直接 continue 跳过即可。

4.3 模块三：命令行参数解析

这是从“字符串”到“进程执行”最关键的一步。我们的目标很明确：

把 "ls -a -l" 转换成 char *argv[] = {"ls", "-a", "-l", NULL}

老师用了 C 标准库的 strtok 函数，以空格为分隔符进行切割。切割逻辑如下：

#define SEP " "
g_argv[0] = strtok(command_line, SEP); // 第一次传原串
while (g_argv[g_argc] = strtok(NULL, SEP)) { // 后续传 NULL
    g_argc++;
}
//这样写，g_argc在定义时给的默认值就是1了

这里有三个必须注意的小知识点：

1. strtok 会修改原字符串：它把分隔符替换成 \0，所以输入缓冲区必须是可写的，不能传字符串常量。
2. 全局状态管理：维护全局的 g_argv 数组和 g_argc 计数器。g_argv 就是未来要传给 execvp 的命令行参数表。
3. 计数修正：由于循环逻辑，strtok 最后返回 NULL 时，g_argc 会多统计一次。因此最后要做 g_argc-- 修正，确保参数个数准确。

解析完成后，老师还做了一步防御性编程：如果解析后命令为空（用户只敲了回车），直接 continue 进入下一轮循环，让用户开始输入新一轮的命令。

4.4 模块四：命令执行

有了参数表，执行命令的逻辑非常清晰：

pid_t id = fork();
if (id == 0) {
    // 子进程：执行程序替换
    execvp(g_argv[0], g_argv);
    exit(1); // 如果替换失败，子进程退出
}
// 父进程：阻塞等待子进程结束，回收资源
waitpid(id, &status, 0);

为什么选 execvp？

• 支持 PATH 自动查找命令（带 p）。
• 天然接受数组参数（带 v），与我们解析后的 g_argv 数据结构完美契合。

老师把这部分封装成了一个 Execute() 函数，让主循环保持极简：

while (1) {
    PrintPrompt();      // 1. 打印提示符
    if (!GetCommand()) continue; // 2. 获取输入
    ParseCommand();     // 3. 解析命令
    Execute();          // 4. 执行命令
}

五、遗留问题：cd 为何失效？引出“内建命令”

写到这里，这个迷你 Shell 已经能跑 ls、pwd、touch、rm 等大多数命令了。但老师故意让我们试了一个命令：

cd ..

然后发现——路径根本没变！

为什么？因为我们目前所有命令都在子进程中执行。cd 命令改变的是子进程的当前工作目录（cwd），子进程一结束就消失了，父进程 Shell 的工作目录纹丝不动。

这就是操作系统中**“内建命令”（Built-in Command）**概念的来源：

cd、export 等会影响 Shell 自身状态的命令，不能创建子进程去执行，必须由 Shell 父进程亲自执行。

六、课程总结：从接口到系统的思维跃迁

本章节的价值，远不止于让我记住了几个 exec 函数名。它完成了从“零散知识点”到“系统级认知”的闭环：

• 程序替换原理：理解了进程并非只能“诞生”和“死亡”，还能“重生”为另一个程序，且 PID 不变。
• exec 接口选型：通过 l/v/p/e 的命名规律，能根据场景（需不需要 PATH、参数是列表还是数组、要不要定制环境变量）快速选择最合适的接口。
• 命令行参数的传递链：终于搞清楚 main 函数的 argv 是从哪来的——是父进程通过 exec 亲手塞进来的。
• Shell 的解剖学：一个看似简单的命令解释器，背后需要提示符生成、输入处理、字符串解析、父子进程分工、进程等待这一套精密配合。
• 工程细节：snprintf 的安全格式化、fgets 替代 scanf、strtok 的切割技巧、string::rfind 的路径处理、环境变量的增量式导入……这些才是从“ toy code ”走向“生产代码”的阶梯。

最后想分享老师在课上的一句话：“所谓加载器，本质上就是 fork + exec；而所谓 Shell，本质上就是一个不断 fork、exec、wait 的死循环进程。”

当你亲手写完这 100 多行代码，再回头看 Linux 终端时，它不再是一个黑盒子，而是一个你能看懂、能拆解、甚至能复现的老朋友。