进程创建和文件描述符这两件事，在Linux系统编程里属于那种"看文档觉得简单、动手写就翻车"的典型。fork和exec这对组合拳，几乎每个写过shell或者做过系统工具的人都用过，但真正把I/O重定向这件事从头捋清楚的人并不多。我见过不少同学，能背出fork创建子进程、exec替换映像，可一旦让他实现一个ls > out.txt的效果，就开始在dup2的参数顺序上反复试错。这篇内容就是围绕这个实验展开的：从fork和exec的协作机制讲起，把文件描述符表在进程间的复制关系、dup2的重定向原理、以及重定向时机对exec的影响，一层层拆开。适合已经会用基本Linux命令、想搞明白shell底层到底做了什么的人，也适合正在准备系统编程实验、需要一份能直接复现的操作指南的读者。下面这些内容，都是我在反复写demo、反复踩坑之后整理出来的，代码可以直接跑，坑也标出来了。
1. 先把实验目标钉死：重定向到底在重定向什么
很多人一上来就写dup2(fd, 1)，写完发现输出确实进了文件，但问他为什么是1、为什么不是0或者2，就答不上来了。这个实验的第一步不是敲代码，而是把"重定向"这个词翻译成内核能听懂的语言。
1.1 文件描述符是进程私有的"插座编号"
Linux里一切皆文件，这句话的真正含义是：内核给每个打开的文件维护一个文件表项，而进程拿到的是一个非负整数索引，也就是文件描述符（file descriptor，简称fd）。你可以把它理解成酒店房间的插座编号——房间（进程）里每个插座（fd）对应一条供电线路（打开的文件），但不同房间的同一个编号，接的可能是完全不同的电器。
关键点在于：文件描述符表是进程私有的。进程A的fd 1和进程B的fd 1，默认都指向各自的终端，但它们是两张独立的表。这一点直接决定了后面fork之后父子进程的描述符关系，也是理解重定向为什么"只影响子进程"的根基。
标准输入、标准输出、标准错误这三个约定俗成的编号，是shell和几乎所有命令行程序之间的默契：
| fd编号 | 名称 | 默认指向 | 常见用途 |
|---|---|---|---|
| 0 | 标准输入 stdin | 终端键盘 | read、scanf读取数据 |
| 1 | 标准输出 stdout | 终端屏幕 | printf、write正常输出 |
| 2 | 标准错误 stderr | 终端屏幕 | 错误信息、调试日志 |
所谓"重定向"，本质就是把某个fd编号重新绑定到另一个打开的文件表项上。ls > out.txt做的事情，就是把子进程的fd 1从"终端"改绑到"out.txt"这个文件。程序本身完全不知道自己被重定向了，它还是老老实实往fd 1写，只是fd 1背后换了个目的地。这种"程序无感知"的设计，正是Unix哲学里组合性的精髓。
1.2 重定向发生在exec之前，而不是之后
这是实验里最容易搞混的时序问题。exec系列函数的作用是用新程序替换当前进程的代码段、数据段，但有一个东西会被完整保留下来——文件描述符表（除非fd设置了FD_CLOEXEC标志）。
换句话说，重定向必须在exec之前完成。因为一旦exec成功，当前进程的代码就被新程序覆盖了，你原来写的dup2调用根本不会再执行。正确的顺序永远是：
fork出子进程；- 子进程里打开目标文件、用
dup2完成重定向； - 子进程调用
exec加载新程序； - 新程序继承已经重定向好的fd表，往fd 1写就是往文件写。
我见过有人把dup2写在exec后面，结果exec成功返回后代码根本走不到那一行，程序直接变成新程序在跑，重定向自然失效。这个坑不踩一次很难记住，所以实验设计上一定要把"重定向在exec前"当成铁律。
1.3 为什么用fork+exec而不是system或popen
有同学会问：直接system("ls > out.txt")不就完了？确实能出结果，但那是把重定向的活儿又甩回给shell了，你什么都没学到。popen稍微好一点，但它只支持单向管道，且内部还是fork了一个shell。
用fork+exec+dup2手写，价值在于你能精确控制每一个fd的去向，能实现2>&1这种把错误输出合并到标准输出的复杂重定向，也能理解为什么shell里重定向的顺序是有讲究的。这是从"会用命令"到"理解命令"的分水岭。实验的目的不是造一个能用的shell，而是把这条链路彻底打通。
2. fork之后，父子进程的fd表到底怎么算
fork的语义经常被简化成"复制一个进程"，但"复制"到什么粒度，直接关系到重定向实验的正确性。这一节把fork对文件描述符的影响讲透。
2.1 fd表被复制，但文件表项是共享的
fork成功后会创建子进程，子进程获得父进程文件描述符表的副本。注意措辞：复制的是"表"，不是"表里的文件"。父子进程各自的fd 1指向的是同一个打开文件表项（open file description），这个表项里记录了文件偏移量、文件状态标志等信息。
这个区别非常关键。意味着：
- 父子进程对同一个fd调用
read，会共享文件偏移量，一个读了下一次另一个接着读； - 但如果子进程用
dup2把fd 1改绑到别的文件，只影响子进程自己的fd表，父进程的fd 1纹丝不动。
这正是重定向"只作用于子进程"的底层原因。父进程（比如shell本身）的fd 1还连着终端，所以shell自己的提示符照常显示；子进程的fd 1被改绑到文件，所以ls的输出进了文件。两者互不干扰。
2.2 一个容易忽略的细节：fork失败与fd泄漏
fork可能失败（返回-1），常见原因是进程数达到上限或者内存不足。实验代码里如果不对fork返回值做判断，失败后继续往下走，父子进程的逻辑就全乱了。标准写法是：
pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(EXIT_FAILURE); } else if (pid == 0) { // 子进程：重定向 + exec } else { // 父进程：waitpid回收 }另一个坑是fd泄漏。子进程里open了目标文件拿到一个fd，dup2之后这个原始fd如果不再需要，应该close掉。虽然exec之后大部分fd会被新程序继承，但如果你打开的文件恰好占用了fd 3，而新程序又碰巧要用fd 3做别的事，就可能出问题。规范做法是dup2(oldfd, 1)之后立刻close(oldfd)，让fd编号干净。
2.3 父进程必须wait，否则产生僵尸
子进程exec之后变成新程序运行，结束后会变成僵尸进程（zombie），直到父进程调用wait或waitpid回收。实验里如果父进程不wait就退出，子进程会被init收养，虽然最终也能回收，但中间会有一段僵尸期，用ps能看到<defunct>状态。
更实际的问题是：如果父进程是shell，它必须等子进程结束才能打印下一个提示符，否则用户会看到提示符和命令输出交错在一起。所以父进程的正确姿势是：
int status; waitpid(pid, &status, 0);这里用waitpid而不是wait，是因为实验里可能同时管理多个子进程，waitpid能精确指定回收哪个。status参数用来判断子进程是正常退出还是被信号杀死，后面排查exec失败时很有用。
3. dup2的重定向魔法：参数顺序和边界条件
dup2是整个实验的核心函数，但它的参数语义和返回值处理，是翻车重灾区。这一节把它的行为拆到原子级别。
3.1 dup2(oldfd, newfd)到底做了什么
dup2的原型是int dup2(int oldfd, int newfd)，作用是让newfd成为oldfd的副本，即newfd现在指向和oldfd相同的打开文件表项。如果newfd原来已经打开，会先被静默关闭。
拿ls > out.txt举例：
int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); exit(1); } dup2(fd, STDOUT_FILENO); // STDOUT_FILENO 就是 1 close(fd);执行完dup2(fd, 1)后，fd 1不再指向终端，而是指向out.txt。此后任何往fd 1的写入，都会落到文件里。close(fd)是因为fd这个原始编号已经没用了，fd 1已经接管了它的"线路"。
参数顺序记不住的话，可以这样记：dup2(源, 目标)，把目标改绑到源上。源是你要用的文件，目标是标准输出1。写成dup2(1, fd)就反了，那会把文件fd改绑到终端，完全不是你要的效果。
3.2 打开标志位选错，输出会变成追加或乱码
open的第二个参数决定文件打开方式，重定向场景下最常用的是O_WRONLY | O_CREAT | O_TRUNC：
O_WRONLY：只写，因为重定向输出不需要读；O_CREAT：文件不存在就创建；O_TRUNC：文件存在就清空，对应shell里>的覆盖语义。
如果想实现>>追加，就把O_TRUNC换成O_APPEND。这两个标志千万别同时用，行为未定义。第三个参数0644是权限位，表示所有者读写、其他人只读，这是新建文件的常规权限，实际还会被进程的umask修正。
我踩过一个坑：忘了加O_CREAT，结果文件不存在时open直接返回-1，perror打印"No such file or directory"，排查半天才发现是标志位漏了。所以open之后一定要判断返回值，这是硬性习惯。
3.3 dup2的返回值与EINTR
dup2成功返回新的fd（也就是newfd），失败返回-1并设置errno。常见的失败原因：
EBADF：oldfd不是有效的打开fd，或者newfd是负数或超过上限；EINTR：调用被信号中断。
EINTR在实验环境里不常见，但在生产代码里必须处理，标准做法是用循环重试。实验阶段至少要把返回值判断写上，失败时perror并退出，别让错误静默传播。
还有一个边界：如果oldfd == newfd，dup2直接返回newfd，什么也不做。这个行为在某些"幂等重定向"的写法里会被利用，但实验里一般不会遇到。
4. 完整实验代码：从零跑通一个重定向
理论讲完，直接上能跑的代码。这个demo实现的效果等价于ls -l > out.txt，但完全由我们自己控制重定向过程。
4.1 代码骨架与逐行注释
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/wait.h> #include <sys/types.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(EXIT_FAILURE); } if (pid == 0) { // 子进程：打开文件并重定向stdout int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); _exit(EXIT_FAILURE); // 子进程用_exit避免刷新父进程缓冲区 } if (dup2(fd, STDOUT_FILENO) < 0) { perror("dup2"); _exit(EXIT_FAILURE); } close(fd); // 原始fd已无用，关掉 // 加载ls程序，参数列表以NULL结尾 execlp("ls", "ls", "-l", (char *)NULL); // 只有exec失败才会走到这里 perror("execlp"); _exit(EXIT_FAILURE); } else { // 父进程：等待子进程结束 int status; waitpid(pid, &status, 0); if (WIFEXITED(status)) { printf("child exited with %d\n", WEXITSTATUS(status)); } } return 0; }编译运行：
gcc -Wall -o redirect_demo redirect_demo.c ./redirect_demo cat out.txt如果一切正常，out.txt里会是当前目录的详细列表，终端上只打印一行child exited with 0。
4.2 为什么子进程用_exit而不是exit
这是实验里一个非常隐蔽的坑。exit会刷新stdio缓冲区，而fork之后子进程继承了父进程的缓冲区内容。如果父进程在fork之前用printf往缓冲区里写过东西但还没刷新，子进程调用exit时会把这份缓冲区也刷出去，导致输出重复。
_exit是系统调用，直接终止进程，不碰stdio缓冲区，所以子进程在exec失败的分支里应该用_exit。这个细节在教科书里经常一笔带过，但实验里一旦出现"输出莫名其妙多了一行"，八成就是这里的问题。
4.3 验证重定向是否真的生效
光看out.txt有内容还不够，要确认输出确实没跑到终端上。可以这样验证：
- 运行
./redirect_demo，观察终端——除了child exited with 0，不应该有ls的输出； cat out.txt，应该看到完整的目录列表；- 把
dup2那行注释掉重新编译运行，此时ls输出会直接打到终端，out.txt是空的（因为open还是创建了文件）。
这个对照实验能让你直观感受到dup2的作用。我建议每个人都做一遍这个"注释掉再跑"的对比，比看十遍文档都管用。
5. 进阶：2>&1这种合并重定向怎么写
基础版跑通之后，真正的挑战是command > out.txt 2>&1这种把标准错误也合并进文件的写法。这里涉及重定向顺序的问题，是shell实现里最经典的考点。
5.1 顺序决定结果：> out 2>&1 与 2>&1 > out 的区别
先看正确写法对应的代码：
int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, STDOUT_FILENO); // 先把1指向文件 dup2(fd, STDERR_FILENO); // 再把2指向文件（此时2和1指向同一个文件表项） close(fd);这样fd 1和fd 2都指向out.txt，程序的正常输出和错误输出都会进文件。
如果顺序反过来：
dup2(fd, STDERR_FILENO); // 2先指向文件 dup2(fd, STDOUT_FILENO); // 1再指向文件结果其实一样，因为两次都是指向同一个文件。真正体现顺序差异的是2>&1这种"让2复制1当前指向"的语义。在shell里：
> out 2>&1：先把1指向out，再让2复制1，所以2也指向out，两者都进文件；2>&1 > out：先让2复制1（此时1还指向终端），所以2指向终端；再把1指向out。最终1进文件、2还在终端。
用dup2表达第二种：
dup2(STDOUT_FILENO, STDERR_FILENO); // 2复制1，此时1还是终端 int fd = open("out.txt", ...); dup2(fd, STDOUT_FILENO); // 1改指文件，2不受影响这个顺序差异是shell脚本里2>&1位置不能乱放的根本原因。实验里把两种顺序都跑一遍，用一段同时往stdout和stderr写的程序做测试，能非常直观地看到区别。
5.2 用dup保存原始fd以便恢复
有时候需要在重定向之后恢复原来的stdout，比如先重定向到文件，处理完再切回终端打印提示。做法是用dup保存一份原始fd：
int saved_stdout = dup(STDOUT_FILENO); // 备份当前1 int fd = open("out.txt", ...); dup2(fd, STDOUT_FILENO); // ... 往文件写 ... dup2(saved_stdout, STDOUT_FILENO); // 恢复 close(saved_stdout); close(fd);dup会返回一个新的fd，指向和参数相同的文件表项。这里dup(STDOUT_FILENO)拿到的saved_stdout，就是终端的一个"备份线路"。恢复时再dup2回去即可。这个技巧在实现日志系统、临时屏蔽输出时很常用。
注意saved_stdout用完要close，否则每重定向一次就泄漏一个fd，循环里跑久了会耗尽fd上限（默认1024）。
5.3 重定向到管道：和pipe配合的写法
重定向不只针对文件，也可以针对管道。ls | grep txt这种效果，底层是父进程创建管道，子进程把stdout重定向到管道写端：
int pipefd[2]; pipe(pipefd); pid_t pid = fork(); if (pid == 0) { close(pipefd[0]); // 子进程关掉读端 dup2(pipefd[1], STDOUT_FILENO); // stdout改指管道写端 close(pipefd[1]); execlp("ls", "ls", (char *)NULL); _exit(1); } else { close(pipefd[1]); // 父进程关掉写端 dup2(pipefd[0], STDIN_FILENO); // stdin改指管道读端 close(pipefd[0]); execlp("grep", "grep", "txt", (char *)NULL); _exit(1); }这里有个关键点：管道两端在父子进程里都要及时关闭不需要的那一端。如果子进程不关读端，父进程的grep可能永远等不到EOF，因为管道写端还有子进程持有的副本没关。这个坑在写多进程管道时极其常见，表现为程序卡死不退出。
6. 实验里那些文档不会告诉你的坑
代码能跑通只是及格线，真正拉开差距的是对异常路径的处理。这一节列几个我在实验和实际项目里反复遇到的坑。
6.1 exec失败后必须退出，不能继续往下跑
execlp只有在失败时才返回，成功的话当前进程已经被新程序替换，后面的代码根本不会执行。所以execlp之后必须紧跟错误处理和_exit。如果忘了写，exec失败后子进程会继续执行父进程的代码逻辑，可能出现两个进程都在wait、都在打印的诡异现象。
更隐蔽的是：exec失败的原因往往是命令名拼错或者PATH里找不到，perror能打印出具体原因。实验时故意把"ls"改成"lss"跑一次，观察perror的输出和退出码，能加深对这条路径的理解。
6.2 文件权限与umask的相互作用
open的第三个参数0644不是最终权限，实际权限是0644 & ~umask。大多数系统umask是022，所以最终是0644。但如果实验环境umask是077，新建文件就变成0600，其他人读不了。这不是bug，是设计如此。
排查权限问题时，先umask看一眼当前值，再ls -l看实际权限，两者对不上就是umask在起作用。需要精确控制权限时，可以在open之前临时umask(0)，但记得改回来，否则影响后续所有文件创建。
6.3 缓冲区与重定向的交互：printf为什么没输出
有个经典现象：程序里用printf打印，重定向到文件后cat发现内容不全或者顺序乱了。原因是printf走的是stdio缓冲区，标准输出连终端时是行缓冲（遇到换行就刷），连文件时是全缓冲（缓冲区满了才刷）。重定向到文件后，如果程序异常退出没来得及刷新，缓冲区里的内容就丢了。
解决办法有两个：要么在关键位置fflush(stdout)，要么直接用write(STDOUT_FILENO, ...)绕过stdio缓冲。实验里如果发现"明明printf了但文件里没有"，先怀疑缓冲区，别怀疑dup2。
6.4 信号与EINTR：waitpid被打断怎么办
waitpid可能被信号中断返回-1并设置errno为EINTR。实验环境里如果不装信号处理器，一般不会遇到；但一旦程序里注册了SIGCHLD或者SIGALRM，waitpid就可能被打断。健壮的写法是循环重试：
while (waitpid(pid, &status, 0) == -1) { if (errno != EINTR) { perror("waitpid"); break; } }这个模式在处理信号的程序里是标配，实验阶段可以先不写，但要知道它的存在，否则将来遇到"偶尔wait失败"会一头雾水。
7. 从实验到实战：这套机制在真实工具里的影子
把实验跑通之后，回头看一些日常工具，会发现它们用的就是同一套机制，只是包装得更完善。理解这层对应关系，能让实验的价值翻倍。
7.1 shell的重定向实现就是这套逻辑的工程化
bash、zsh这些shell在执行一条带重定向的命令时，内部流程和我们的demo几乎一模一样：fork子进程、在子进程里按顺序处理每个重定向（打开文件、dup2到对应fd）、最后exec目标命令。区别在于shell要解析重定向语法、要处理多个重定向的组合、要支持<、>、>>、2>&1等各种形式，还要在exec失败时给出友好的错误提示。
所以实验里踩的每一个坑，在shell源码里都有对应的处理代码。比如shell会在fork之前就把重定向的目标文件打开（这样打开失败可以在父进程里报错，不用fork），这个优化思路值得借鉴。
7.2 守护进程的fd清理：重定向到/dev/null
写守护进程（daemon）时有个标准操作：把stdin、stdout、stderr都重定向到/dev/null，避免进程在后台还往终端写东西导致出错。代码就是：
int fd = open("/dev/null", O_RDWR); dup2(fd, STDIN_FILENO); dup2(fd, STDOUT_FILENO); dup2(fd, STDERR_FILENO); if (fd > STDERR_FILENO) close(fd);这里if (fd > 2)的判断是因为如果/dev/null恰好被分配到fd 0/1/2（比如前面已经关了标准fd），就不能再close，否则会把刚重定向好的fd关掉。这个细节在daemon编程里是常识，但第一次写的人很容易漏。
7.3 容器与进程管理工具的fd继承
容器运行时在启动进程时，也要处理fd的继承和重定向——把容器的标准输入输出接到日志系统或者终端上。原理还是dup2，只是fd的来源可能是socket、pipe或者pty。理解了fork+exec+dup2这条链路，再看这些工具的文档，很多"魔法"就变成了理所当然。
我在实际排查一个"容器里进程输出丢失"的问题时，最后定位到就是启动时stderr没有正确dup2到日志管道，导致错误信息写到了一个已经关闭的fd上。这类问题的根因往往就在这几行系统调用里。
8. 几个值得动手改一改的扩展方向
实验做完基础版，可以顺着几个方向继续深挖，每个方向都能带出新的知识点。
第一个方向是实现一个迷你shell，支持cmd > file、cmd < file、cmd1 | cmd2三种形式。这需要解析命令行、识别重定向符号、按顺序执行dup2，工作量不大但能把整条链路串起来。写完之后你对shell的理解会上一个台阶。
第二个方向是研究FD_CLOEXEC标志。默认情况下fd会被exec继承，但有些fd（比如内部用的锁文件）不希望泄漏给新程序，就可以用fcntl(fd, F_SETFD, FD_CLOEXEC)设置。理解这个标志能解释为什么有些程序exec之后fd数量会变化。
第三个方向是对比posix_spawn。fork+exec在某些场景下（比如大内存进程fork）有性能问题，posix_spawn提供了更轻量的替代，内部可能用vfork或者clone。研究两者的差异，能理解现代系统编程在性能上的取舍。
每个方向都不需要太多代码，但都需要你把本文讲的fd表、重定向时机、exec继承这些概念真正吃透。我个人建议先把迷你shell写出来，因为它是所有扩展里最能检验理解程度的一个——写的过程中任何一个概念没搞清，都会以bug的形式暴露出来。
最后分享一个我自己的习惯：每次写完这类涉及fd的代码，都会在关键位置加一行system("ls -l /proc/self/fd")或者用ls -l /proc/<pid>/fd看一眼当前进程的fd表，确认每个fd指向哪里。这个土办法比任何调试器都直观，能让你一眼看出重定向到底有没有生效、有没有fd泄漏。实验做多了，你会对这种"看fd表"的排查方式产生依赖，因为它把抽象的文件描述符变成了看得见的符号链接，一切尽收眼底。
