从日常写代码到排查线上问题，文件重定向是绕不开的基础操作。尤其当你开始尝试给自己的小程序、小工具甚至一个简化版shell加入重定向能力时，才会真正意识到，平时在终端里写的那些> file、2>&1，背后其实是系统调用层面一套非常精巧的设计。我早年写过一个迷你shell，功能倒是能跑，但在处理重定向时踩了不少坑，回头再看Linux基础IO里的文件描述符、dup2这些概念，才把它们彻底串了起来。这篇文章就把我在这段实践里的完整思考过程写下来，从文件描述符的本质开始，一路讲到如何使用dup2、给shell程序添加重定向支持，最后聊聊“一切皆文件”这句话到底该怎么理解。

1. 文件描述符表：重定向的本质是“改指针”，不是“改文件”

先说一个很多刚接触Linux的同学最容易混淆的点：重定向操作看起来是在“指定数据写到哪个文件”，但内核层面做的事情，其实是修改进程内部一张表里的指针指向。搞清楚这张表，后面所有内容都会变得顺理成章。

1.1 文件描述符是索引，不是文件本身

Linux进程启动之后，内核会为它维护一张文件描述符表（fd table）。这张表里的每一项，存放的是一个指向内核打开文件表（open file table）中某个条目的指针。而我们平时说的fd，其实只是这张fd table的下标索引。

比如进程刚启动时，默认就有三个描述符：

当你调用open("log.txt", O_WRONLY | O_CREAT)时，内核会在打开文件表里新建一个条目，然后在当前进程的fd table中找一个空闲位置（通常是最小的可用下标），比如返回3，于是fd table[3]就指向了那个文件条目。

这里有一个非常重要的结论：fd编号只是一个索引，真正决定“读写到哪”的是索引指向的打开文件描述。如果我修改了fd table[1]的指向，让它从指向终端改为指向log.txt对应的打开文件条目，那么进程里任何通过标准输出（printf、fprintf(stdout,...)、write(1,...)）写出的数据，就会全部落进log.txt，终端上反而什么都看不到。这就是重定向最底层的机制。

1.2 重定向的实质操作：替换文件描述符指向

现在再看一条简单的shell命令：

echo "hello world" > log.txt

shell在接收到这条命令后，并不是自己动手把echo的输出重定向到文件，而是做这样几件事：

1. 以只写方式打开log.txt，得到一个fd（假设是3）；
2. 调用dup2(3, 1)，把fd table[1]的指向改为fd table[3]的指向；
3. 关闭多余的fd 3；
4. 通过fork()创建子进程，在子进程中exec加载echo程序；
5. 由于子进程拷贝了父进程的fd table，所以子进程的fd 1也指向log.txt；
6. 子进程里echo调用的write(1, "hello world\n", 12)自然就写进了文件。

可以看到，重定向的本质并不是“把输出方向改到文件”，而是“让目标进程的文件描述符1指向我们要的那个文件”。这也是为什么重定向能对任何遵循标准输出约定的程序生效，因为程序根本不关心fd 1背后是什么，它只知道自己往fd 1写数据就行。

1.3 用代码做一次最小验证

为了验证上面的理解，我写过一个非常小的C程序，手工完成重定向操作：

#include <stdio.h> #include <fcntl.h> #include <unistd.h> int main() { // 打开文件，得到fd int fd = open("out.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); return 1; } // 把标准输出重定向到fd指向的文件 dup2(fd, STDOUT_FILENO); close(fd); // 这句printf不会输出到终端，而是写入out.txt printf("这一行会写进文件里\n"); fflush(stdout); return 0; }

编译运行后，终端上什么都看不到，但当前目录下会生成一个out.txt，里面有完整的一行文本。这个实验虽然简单，却把重定向的底层逻辑暴露得清清楚楚：printf根本没有变，变的是fd 1指向的目标。

这里顺带提醒一句：printf是C标准库函数，它在用户态有自己的缓冲区（stdio buffer）。所以如果重定向前后混用了printf和write，可能会出现输出顺序错乱的问题，因为write是直接进内核，而printf的缓冲区可能还没刷新。保险做法是在重定向后、继续混用之前，显式调用fflush(stdout)，或者用setbuf(stdout, NULL)关闭缓冲区。这个坑我在排查一个日志顺序错乱问题时印象极深，后面做shell重定向时也专门处理了这个问题。

2. dup2的系统调用细节：为什么重定向场景必须用它

既然重定向的本质是“让fd 1指向另一个打开文件描述”，那么实现这个“指向修改”的函数就是核心工具了。Linux提供了dup和dup2两个系统调用，这里重点说dup2，以及它和dup的差异。

2.1 dup2的签名与语义

#include <unistd.h> int dup2(int oldfd, int newfd);

它的作用一句话就能概括：让newfd这个描述符，拷贝oldfd的指向。也就是让newfd和oldfd最终指向同一个内核打开文件描述。

具体执行过程分几种情况：

• 如果oldfd本身不是一个有效的描述符，dup2调用失败，返回-1；
• 如果oldfd有效，但newfd已经打开着，dup2会先自动关闭原先的newfd，再把它指向oldfd的同一条打开文件描述；
• 如果oldfd恰好等于newfd，那么dup2直接返回newfd，不做任何改动。

这正是重定向场景最需要的特性：我不需要关心fd 1当前是否被占用，直接dup2(fd, 1)，内核会帮我关掉旧的标准输出打开文件描述，再换上新的指向。

实现重定向的标准三步：

int fd = open("file", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); // 根据场景决定是exit还是返回错误 } dup2(fd, STDOUT_FILENO); close(fd);

第三步的close(fd)经常被初学者漏掉。它的意义在于：重定向完成后，原来的fd编号已经不再需要了，如果留着，会让文件被两个fd同时引用，也占用了进程宝贵的fd数。真正成熟的代码里关闭多余的fd是必须习惯，否则在处理大量并发连接的程序里，fd泄漏会非常致命。

2.2 dup和dup2的差别：dup2是“指定目标”，dup是“自动分配”

举一个实际场景说明区别：假设我想临时把标准输出重定向到文件，执行完一段代码后再恢复回终端。如果只用一个fd实现，需要用dup先保存当时的stdout指向。

int saved = dup(STDOUT_FILENO); // saved指向终端 int fd = open("log.txt", O_WRONLY | O_CREAT, 0644); dup2(fd, STDOUT_FILENO); // stdout指向文件 printf("这行会写进文件\n"); fflush(stdout); dup2(saved, STDOUT_FILENO); // stdout恢复指向终端 close(saved); close(fd);

这里saved拿到了printf原本要写的终端设备对应的打开文件描述，等重定向结束后再把它搬回fd 1，就能完美还原现场。如果你想用dup2做同样的事，就得自己挑一个不会撞车的fd编号，比如dup2(1, 100)，然后在你需要恢复时dup2(100, 1)。但这里藏着风险：程序里如果其他地方用了100这个fd，就会互相覆盖，所以dup在这种“临时保存”场景更安全。

2.3 dup2使用中的经典陷阱

第一个坑是返回值检查。很多人以为dup2一定会成功，就忽略返回值。但实际上如果oldfd无效（比如之前已经被关闭），或者进程的fd数达到上限，dup2会返回-1并设置errno。在给shell做重定向时，如果dup2静默失败，后果是子进程可能往错误的fd输出数据，调试起来非常痛苦。我自己的习惯是任何系统调用都检查返回值，至少要有perror。

第二个坑是权限和打开模式的匹配。dup2本身不做权限检查，它只是复制指向。但你用open打开文件时如果只给了只读权限（O_RDONLY），那么之后即使dup2成功了，往这个fd写数据依然会报EBADF。也就是说，你在open阶段就要想清楚这个文件最终是用来读还是写，这其实决定了shell解析重定向时应该选哪个open标志。

第三个坑是fd的复用问题。前面说过，open返回的通常是当前进程最小可用的fd编号。如果你在做重定向前关闭了fd 0，那么open返回的可能就是0，导致后面dup2(fd, 1)时，fd和newfd错位。这在shell解析复杂重定向组合时非常容易踩到。我的处理思路是：在重定向组装阶段不依赖任何固定的fd编号，先用变量接收open返回值，再用dup2精确搬运，最后统一清理多余fd。

第四个坑是与stdio缓冲区的交互。很多人写C程序时发现重定向之后printf的顺序乱了，其实就是因为标准库的缓冲机制。终端设备通常是行缓冲，一行输出立即刷新；但重定向到文件后，C标准库会切换为全缓冲，缓冲区可能等到程序退出或攒够4KB才真正写入。如果你在同一进程里既要重定向，又要保持实时输出，要么fflush显式刷新，要么使用setvbuf调整缓冲策略。这块在日志系统里特别常见。

3. 给shell程序添加重定向支持：动手实现前的设计与关键决策

讲完基础原理和系统调用，现在进入最有意思的部分：怎么给一个自己的shell程序加上重定向能力。很多人一上来就写代码，结果各种诡异问题，其实根源在于没有想清楚shell解析命令和执行命令之间的协作关系。

3.1 为什么必须在fork之后、exec之前处理重定向

shell执行外部命令的经典流程是：fork出一个子进程，在子进程中exec加载目标程序。重定向操作的时机选择是这门手艺的核心，必须发生在fork之后、exec之前。

原因在于exec会用新程序替换当前进程的代码和数据段，但它不会修改文件描述符表。也就是说，子进程中已设置好的fd指向关系会被完整保留给新程序。如果你在fork之前就对父进程做重定向，那么父进程自己也跟着遭殃，shell本身的标准输出会被改掉，接下来所有终端输出都会消失，这是绝对不可接受的。

所以标准做法是：

shell 解析命令 │ ├─ fork() │ ├─ 子进程: 执行重定向（open、dup2、close） │ ├─ 子进程: exec 目标程序 │ └─ 父进程: wait 等待子进程结束

子进程里对fd表的任何修改，只会影响子进程自己，不会波及父进程。这也是进程隔离带来的便利：子进程的fd表是从父进程拷贝过来的副本，怎么改都无所谓，用完即被exec覆盖或随进程退出销毁。

3.2 第一版实现：支持> file、>> file和2>重定向

我做过一个微型shell的练习版本，主循环非常简单：读取一行命令，解析出命令名、参数，以及重定向部分，然后fork执行。解析重定向的环节我是这样处理的：

先看输入命令里是否包含>或>>符号，找到之后，把符号前面的部分当作正常命令，把符号后面的部分当作目标文件名。同时记录是截断写（>）还是追加写（>>）。如果命令里出现2>，那么在打开文件时把目标fd定为2（stderr），否则默认是1（stdout）。

核心代码思路大致如下：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <sys/wait.h> void execute_with_redirect(char *cmd, char *file, int target_fd, int append) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return; } if (pid == 0) { // 子进程中执行重定向 int flags = O_WRONLY | O_CREAT; if (append) { flags |= O_APPEND; } else { flags |= O_TRUNC; } int fd = open(file, flags, 0644); if (fd < 0) { perror("open"); exit(127); } dup2(fd, target_fd); close(fd); // 执行命令 execlp(cmd, cmd, NULL); perror("exec"); exit(126); } // 父进程等待 wait(NULL); }

这个版本虽然只支持最简单的>和>>，没有管道，也不支持<输入重定向，但已经能跑通一个基本流程：输入ls > list.txt命令，shell会fork子进程，在子进程里把fd 1指向list.txt，然后exec加载ls，把ls的输出全部写进文件。

这一版跑起来之后，我当时检查了三个容易出问题的点，这里也分享给读者：

第一，O_TRUNC和O_APPEND不能同时设置，否则行为取决于内核实现，容易造成困惑不清的效果。解析代码里用if (append)分开处理是对的。

第二，exit和_exit的选择。子进程里exec失败后，我使用的是exit(126)。这里要注意：exit会刷新stdio缓冲区并运行注册的清理函数，而_exit不会。对子进程来说，如果之前有任何缓冲区残留数据，使用exit可能把这些数据写入已经重定向过的fd中，导致奇怪的输出。但从另一个角度看，exit更符合清理资源的语义。实际工程里，我倾向于在exec失败时使用_exit，避免双重刷新父进程拷贝下来的缓冲区。这一点在《UNIX环境高级编程》里也有讨论，属于老手和新手容易产生分歧的细节，我的结论是：涉及不可靠状态时_exit更干净。

第三，解析重定向符号的顺序。如果输入是echo hello > file，我要做的是先按空格把命令拆成echo、hello、>、file，然后在扫描到>时，把前面部分拼成真正的命令参数。这个解析不难，但容易在引号和转义上翻车。真正的shell还要处理"和'包裹的空格，我在这个练习版里没有处理，因为没有引入词法分析器，先保住主流程。给想继续深入的朋友一个方向：用状态机区分“引号内”和“引号外”的空白，是正确解析命令行的基础。

3.3 为什么<输入重定向同样依赖open和dup2

输出重定向做完之后，输入重定向就是顺理成章的事。cat < file.txt的含义是让cat从file.txt读数据，而不是从键盘读。底层操作和输出重定向完全对称：

int fd = open("file.txt", O_RDONLY); dup2(fd, STDIN_FILENO); close(fd);

然后exec加载cat，cat只知道自己从fd 0读取，并不知道fd 0此时已经指向了文件。按行读取、分析数据这些逻辑完全不用改动。

输入重定向在shell实现中容易忽略的一个细节是：当dup2(fd, 0)把fd 0指向文件后，如果命令中还包含其他需要读取终端输入的操作，比如某个交互程序在等待用户输入，那么它读到的将是文件中已经存在的内容，或者读到EOF直接退出。严格来说这是预期行为，因为重定向的意义就在于此。但对一个尚未准备好的shell来说，如果用户误输入了重定向符号，程序行为可能变得“看起来像卡死”，实际上是在读文件内容。因此我建议在实现初期就为每个重定向目标保存原始fd信息，方便异常时还原调试。

3.4 给shell加重定向时期的调试利器：strace

在给shell程序添加重定向功能时，我最推荐的调试工具其实是strace。它可以追踪一个进程执行过的所有系统调用，包括open、dup2、execve、write等。用法很简单：

strace -f -e trace=openat,dup2,execve ./myshell

-f参数表示跟踪所有子进程，-e指定只跟踪关心的系统调用。我在跑通第一版shell重定向时，就是靠strace确认了子进程是否真的按预期调用了dup2(3, 1)。如果屏幕上显示dup2(3, 1) = 1，说明重定向生效了；如果只看到open却没看到dup2，看代码思路，基本可以断定是自己忘记调用dup2或者参数写反了。这个工具的排查效率比我一行行写日志快太多了。

4. 重定向生命周期与shell命令执行的边界：谁继承，谁清理

把最基本的重定向做通之后，很多人的疑问会进入下一个层次：重定向后的fd到底影响哪些进程？为什么父进程shell不受影响？这里涉及shell执行命令的完整生命周期，值得独立展开。

4.1 fork拷贝fd表，exec保留fd表，exit释放fd表

Linux进程生命周期里，fd表有几个关键转折点：

• fork之后：子进程获得父进程fd表的完整副本，所有fd指向相同的打开文件描述。注意这里是“共享打开文件描述”而非“独立打开文件”，所以父子进程通过同一个文件描述写同一文件时，文件偏移量是共享的，这和一些人的直觉不同。
• exec之后：fd表保持不变，除非某个fd设置了FD_CLOEXEC标志。这也是重定向能在exec后继续生效的原因：exec只替换代码段、数据段、堆栈，不动fd表。
• exit之后：内核关闭进程所有打开的fd。所以子进程退出时，它重定向过的fd 1也随之关闭，对父进程没有任何影响。

这条生命周期链就是shell能够放心在子进程里做重定向前提。如果你站在子进程视角去思考数据流向，会发现整个过程非常干净：重定向设置完毕 -> exec加载新程序 -> 新程序读写标准流 -> 数据落进目标文件 -> 进程退出关闭所有fd。

4.2 shell内建命令为什么不需要特殊重定向逻辑

在实现shell时你还会遇到一类特殊命令，比如cd、export、alias，它们不像ls、cat那样是新程序，而是shell自身内建的功能。如果cd也走fork+exec流程，那么子进程换了目录，父进程却毫无变化，cd就永远不起作用。

但有意思的是，内建命令同样需要支持重定向。比如：

echo "conf" > /tmp/config.txt

echo在很多shell里是作为内建命令实现的，但重定向依然需要生效。处理内建命令重定向的逻辑和外部命令几乎一样，唯一区别是不需要fork和exec。基本做法是：在shell进程内临时保存当前fd 1的指向（通过dup），然后dup2重定向，调用内建命令处理函数，处理完毕再dup2恢复。可以用这段代码概括：

int saved = dup(1); int fd = open("/tmp/config.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); dup2(fd, 1); // 调用内建命令处理逻辑，比如cmd_echo() cmd_echo("conf"); fflush(stdout); dup2(saved, 1); close(saved); close(fd);

注意这里的fflush(stdout)是必须的。因为printf在重定向到普通文件后是全缓冲，如果没有主动刷新，数据可能还滞留在用户态缓冲区，此时即使恢复了fd 1的指向，滞留的数据也可能写到错误的地方，或者根本没有触发写入。内建命令和外部命令在重定向上的处理差异就在这里：外部命令通过exec获得全新的进程空间和缓冲区，旧数据残留可能性小；而内建命令继续使用同一个进程，你必须自己负责缓冲区的刷新和fd恢复。

4.3 关于2>&1的实现方式和顺序问题

日常shell使用中，2>&1是把标准错误合并到标准输出的经典写法。它的底层语义是“让fd 2指向fd 1当前指向的那个打开文件描述”。注意关键词是“当前指向”，不是“某个固定文件”。

这意味着重定向的顺序很重要。看两条命令的区别：

cmd > /tmp/out.log 2>&1

这条命令先让fd 1指向文件，再把fd 2指向fd 1当前的目标，最终fd 2和fd 1都指向同一个文件。执行效果完全符合预期，标准输出和标准错误都写入同一个文件。

再看颠倒顺序的写法：

cmd 2>&1 > /tmp/out.log

这条命令先让fd 2指向fd 1当前的目标（此时还是终端），再把fd 1指向文件。最终效果是标准错误去了终端，标准输出去了文件。很多人写错这个顺序后会很困惑，为什么自己明明输入了重定向，错误信息还是打印在屏幕上。

在你自己的shell里实现2>&1时，解析器必须在语义层面区分两种情况。最简单的方式是把2>&1视为一次“指定了源和目标fd的复制操作”，在执行时用dup2完成。代码逻辑可以这样：

// 解析到 "N>&M" 格式 int source_fd = 2; // N int target_fd = 1; // M dup2(target_fd, source_fd);

这段代码放到整个命令解析流程里的什么位置，取决于它出现在原始命令里的顺序。最稳妥的实践是先从左到右扫描整条命令，遇到重定向就把对应的open/dup2操作加入一个执行队列，然后按照队列顺序执行。这样做自然就反映了顺序语义，和真实shell行为保持一致。

4.4 进程fd数量限制和泄漏排查

每实现一个功能就引入一个新的fd分配，如果清理不彻底，很容易积累fd泄漏。Linux对进程fd数量默认有RLIMIT_NOFILE限制，通常为1024。日志子系统、网络服务程序、以及长期运行的守护进程特别容易触发这个问题。实际排查可以观察/proc/<pid>/fd/目录下的条目数量：

ls /proc/<pid>/fd | wc -l

如果这个数字持续增长，基本可以断定某个路径里fd没有关闭。在shell重定向场景中，最常见的泄漏路径是父进程等待子进程结束期间临时打开的文件没有关闭，或者失败分支里忘记关闭已打开的fd。我处理这个问题时的原则是：open之后立刻规划好谁来负责关闭，把close写在错误处理和成功路径同一个函数级作用域，尽量做到“打开即闭环”。

5. 从重定向到“一切皆文件”：抽象层之下的统一世界

讲完重定向和shell的关系，最后来聊聊那个经常被挂在嘴边、却又很难真正体会的设计哲学——“一切皆文件”。重定向恰好是理解这句话最好的入口，因为它把一个抽象概念变成了天天都在摸得着的操作。

5.1 打开文件描述背后其实是统一的对象模型

站在内核视角，所谓“文件”，并不只是磁盘上的普通文件。它是任何实现了统一读写语义的对象。Linux通过虚拟文件系统（VFS）层统一了对不同类型存储和设备的访问方式。每个打开的文件描述在内核里对应一个struct file，而struct file内部有一个指向struct file_operations的指针，这个结构体里是一组函数指针，定义了read、write、lseek、ioctl等操作。

普通磁盘文件有一部分操作函数，设备文件有另一套操作函数，管道文件又有自己的实现。但对用户态程序来说，它们都是通过open拿到fd，通过read/write读写数据，通过close释放资源。接口完全一致，差异全被内核隐藏在了函数指针的调度之下。

这就是重定向往文件、设备、管道都能生效的根本原因。让我用一个表格把这几种类型的差异列出来：

上面任何一项，只要是通过fd读写的，命令重定向自然就能对它们生效。也就是说你甚至可以把标准错误重定向到一个设备文件，比如cmd 2> /dev/null，数据就会被丢弃。

5.2 重定向到管道的统一性：匿名管道也是“文件”

管道在重定向中的地位比较特殊。cmd1 | cmd2本质上也是一种重定向：把cmd1的标准输出重定向到管道的一端，把cmd2的标准输入重定向到管道的另一端。

int pipefd[2]; pipe(pipefd); if (fork() == 0) { // 子进程1: cmd1 dup2(pipefd[1], STDOUT_FILENO); close(pipefd[0]); execlp("cmd1", "cmd1", NULL); } else { if (fork() == 0) { // 子进程2: cmd2 dup2(pipefd[0], STDIN_FILENO); close(pipefd[1]); execlp("cmd2", "cmd2", NULL); } }

管道写端用O_WRONLY语义，读端用O_RDONLY语义，但程序层看到的还是同一个fd读写模型。这也从侧面说明，如果你的shell能够统一处理文件重定向和管道重定向，那么这两者就是一个抽象概念的两面：把数据从一个fd搬到另一个fd。

我第一次把文件重定向和管道串起来思考时，那种“整个世界统一了”的感觉非常强烈。以前觉得> file和| next是两个不同概念，现在知道核心机制全是dup2换指向，只是数据方的种类不同。

5.3/proc/self/fd：亲眼看到重定向后的fd指向

如果不能直观感受fd指向的变化，对“一切皆文件”的理解终究会有一层隔膜。Linux的/proc/self/fd/目录提供了一个绝佳的观察窗口。这个目录下的每个符号链接，对应着当前进程的一个fd编号，链接指向的路径就是这个fd实际打开的目标。

比如在终端里执行：

sleep 100 > /tmp/out.log &

然后找到这个sleep进程的PID，查看它的fd目录。

ls -l /proc/<pid>/fd/

你会看到类似于这样的输出：

0 -> /dev/pts/0 1 -> /tmp/out.log 2 -> /dev/pts/0

fd 1指向了/tmp/out.log，而fd 0和fd 2还留在终端。这个符号链接列表，把之前关于fd表的抽象描述直接拉到了可视化层面。如果你重定向的是管道，这里会出现pipe:[12345678]这样的内容，表明fd指向了某个匿名管道对象。

同样的思路还可以用来排查“进程把输出写到哪里去了”。比如一个后台进程明明配置了日志文件，但文件里什么都没写，这时去看看/proc/<pid>/fd/1，很可能发现它根本不是你预期的文件。有一次我排查一个Node.js服务的日志丢失问题，就是这样抓到真相的。

5.4 “一切皆文件”在实践中的边界

虽然“一切皆文件”的概念很强大，但必须认识到它并不是说“所有东西都真的变成一个磁盘文件”。管道的inode和普通文件的inode不是同一个东西，write到管道可能阻塞，write到普通文件不会；设备文件用ioctl控制硬件属性，普通文件没有ioctl语义；procfs里的“文件”内容可能是动态生成的，读一次和读一次可能结果不同。这些差异恰恰说明VFS层提供的是“接口的统一”，而不是“行为的统一”。

理解这一层之后，“一切皆文件”就不再是一句空话，而是操作系统设计原则的实际体现：对外提供统一的接口，对内通过不同的实现满足不同对象的能力边界。重定向之所以能成为连接一切工具的万能胶，正是因为它站在这个统一接口之上，只要目标对象遵循fd读写协议，它就能无缝接入。

我自己的体会是，真正吃透重定向和fd机制，等于给理解整个Linux IO体系打下了一个稳固的地基。包括后面的select/poll/epoll、零拷贝、io_uring，所有的演进和优化，都还在跟这个基本模型打交道。那些看起来高深的IO模型，本质上都是在回答同一个问题：数据怎么在fd之间高效地流动，以及怎么让进程高效地感知fd上的事件。所以花时间把dup2和重定向想明白，不是只为了应付一个shell项目，而是为了后面读任何IO相关代码，都多了一双能看透表象的眼睛。