【Linux基础IO】printf 为什么会写进文件？一文搞懂重定向和 dup2 底层原理

🔥个人主页：爱和冰阔乐
📚专栏传送门：《数据结构与算法》 、C++
🐶学习方向：C++方向学习爱好者
⭐人生格言：得知坦然 ，失之淡然

🏠博主简介

前言

在上一篇文章中，我们已经从 C 文件接口讲到了系统调用，也理解了 fd 的本质：它其实就是进程文件描述符表的数组下标。

这一篇就继续往下看一个很常见、但刚开始学时特别容易懵的问题：重定向到底改了什么？

平时我们在命令行里经常写：

./a.out>log.txt ./a.out>>log.txt ./a.out<input.txt ./cmd>log.txt2>&1

这些命令看起来只是把输入输出换了个地方，但底层并不是 printf、scanf 这些函数变了，而是文件描述符表中对应位置的指向发生了变化。

所以本文会按照实验现象一步步往下推：先看 fd 的分配规则，再理解关闭 1 后为什么内容会写进文件，然后介绍标准的重定向接口 dup2。最后再把这些知识放到 MiniShell 中，看看一个简单 shell 是怎么支持 >、>>、< 的。

看完这一篇后，再遇到重定向、dup2(fd, 1)、2>&1 这些内容，就不会只是死记命令了，而是能知道它们背后到底改的是哪一张表、哪一个位置、哪一个指针。

一、重定向到底改了什么？

理解了文件描述符表后，重定向就很好解释了。

1.1 文件描述符的分配规则

文件描述符的分配规则是：

新文件打开时，操作系统会选择当前进程文件描述符表中最小的、没有被使用的下标作为新的 fd。

先看普通情况：如果0、1、2都还在，新打开的文件一般拿到的是3。

如果我们提前关闭0或者2，再打开文件，情况就不一样了：

#include<stdio.h>#include<sys/types.h>#include<sys/stat.h>#include<fcntl.h>#include<unistd.h>intmain(){close(0);// 也可以试试 close(2)intfd=open("log.txt",O_RDONLY);if(fd<0){perror("open");return1;}printf("fd: %d\n",fd);close(fd);return0;}

如果关闭的是0，新文件就可能拿到fd = 0；如果关闭的是2，新文件就可能拿到fd = 2。

这就证明了 fd 不是固定从 3 开始，而是遵守“最小未使用下标”的分配规则。只不过正常情况下0、1、2已经被默认占用，所以普通文件才从 3 开始。

接着再看一个和重定向直接相关的实验：

#include<stdio.h>#include<sys/types.h>#include<sys/stat.h>#include<fcntl.h>#include<unistd.h>intmain(){close(1);// 关闭标准输出intfd=open("log.txt",O_CREAT|O_WRONLY|O_TRUNC,0666);if(fd<0){perror("open");return1;}printf("fd: %d\n",fd);printf("hello world\n");close(fd);return0;}

运行后会发现，屏幕上没有输出，但是log.txt里面出现了内容。

实验结果：关闭 1 后再打开文件，新文件会拿到 fd 1。

原本应该打印到显示器的内容，被写入到了 log.txt 中。

原因是：

1. 一开始fd = 1指向标准输出，也就是显示器。
2. close(1)后，1 号位置空出来了。
3. 再打开log.txt，操作系统发现 1 是最小空闲位置，于是把log.txt放到了 1 号位置。
4. printf底层还是往 1 号文件描述符写。
5. 但此时 1 号位置已经不是显示器，而是log.txt。

所以内容就写进文件了。

这就是重定向的核心：

上层使用的 fd 数字没变，底层文件描述符表中对应位置的指针变了。

补充图：close(1) 后，新打开的文件会占用 1 号位置。

也就是说，printf没变，stdout绑定的 1 也没变，变的是 1 号位置背后指向的文件对象。

1.2 dup2：标准重定向接口

实际写程序时，不建议手动close(1)再open。因为中间有空窗期，多线程环境下可能会出现问题。

Linux 提供了dup2：

#include<unistd.h>intdup2(intoldfd,intnewfd);

dup2 系统调用接口。

dup2 的核心作用：让 newfd 成为 oldfd 的副本。

它的作用可以简单理解为：

让 newfd 成为 oldfd 的副本。

也就是把oldfd指向的文件对象，复制到newfd这个位置。

补充图：dup2(fd, 1) 的本质是让 1 号位置复制 fd 的指向。

1.3 输出重定向

如果想让标准输出写入文件：

intfd=open("log.txt",O_CREAT|O_WRONLY|O_TRUNC,0666);dup2(fd,1);close(fd);

含义是：

让 1 号标准输出指向log.txt。

之后所有写向标准输出的内容，都会进入log.txt。

比如：

printf("hello printf\n");fprintf(stdout,"hello stdout\n");write(1,"hello write\n",12);

它们最终都会写入文件。

实验结果：dup2(fd, 1) 后，printf/fprintf 都会写入目标文件。

1.4 追加重定向

追加重定向只需要打开文件时换成O_APPEND：

intfd=open("log.txt",O_CREAT|O_WRONLY|O_APPEND,0666);dup2(fd,1);close(fd);

这对应 shell 中的：

./a.out>>log.txt

1.5 输入重定向

如果想让程序本来从键盘读的内容，变成从文件读：

intfd=open("input.txt",O_RDONLY);dup2(fd,0);close(fd);

含义是：

让 0 号标准输入指向 input.txt。

这样scanf、fgets(stdin)等函数就不再从键盘读，而是从文件中读。

输入重定向后，程序原本从键盘读取的内容会变成从文件读取。

这对应 shell 中的：

./a.out<input.txt

实际写小工具时，文件名最好不要写死在代码里，可以通过命令行参数传入。这样同一份程序就可以读取不同文件，不需要每次修改源码重新编译。

通过命令行参数传入文件名，可以让输入重定向相关程序更加通用。

1.6 标准输出和标准错误：2>&1

有时候我们会看到这样的命令：

./cmd>log.txt2>&1

这个命令不要只背成“把错误也写进文件”，最好把它拆开看。

首先，普通的输出重定向：

./cmd>log.txt

它默认只影响stdout，也就是文件描述符1。如果程序把错误信息写到了stderr，也就是文件描述符2，那么错误信息依然可能显示在屏幕上。

比如下面这个命令：

./cmd>log.txt

可以理解成底层做了类似的事情：

intfd=open("log.txt",O_CREAT|O_WRONLY|O_TRUNC,0666);dup2(fd,1);// 只让标准输出指向 log.txtclose(fd);

此时文件描述符表大致是：

fd 1 -> log.txt fd 2 -> 显示器

所以普通输出进文件，错误信息还在屏幕。

而下面这个命令：

./cmd>log.txt2>&1

它可以分成两步：

第一步：

>log.txt

让fd = 1指向log.txt。

第二步：

2>&1

这一步的含义不是“把 2 写到数字 1 里面”，而是：

让 2 号标准错误复制当前 1 号标准输出的指向。

也就是类似：

dup2(1,2);

注意这里复制的是“当前 1 号 fd 背后指向的文件对象”。由于第一步已经让1指向了log.txt，所以第二步执行完以后，2也会指向log.txt。

最终效果就是：

fd 1 -> log.txt fd 2 -> log.txt

普通输出和错误输出都会进入同一个文件。

还有一个很容易混的写法：

./cmd>log.txt2>1

这个和2>&1不是一回事。

2>1的意思是：把标准错误重定向到一个名字叫1的文件里；而2>&1的意思才是：把标准错误重定向到标准输出当前指向的位置。

补充图：2>&1 的核心是让标准错误复制当前标准输出的指向。

二、一个容易踩坑的现象：重定向后 printf 为什么可能重复输出？

前面一直在讲printf、fprintf、write都能输出内容，但是它们底层经过的路线并不完全一样。

先看一段经典代码：

#include<stdio.h>#include<string.h>#include<unistd.h>intmain(){printf("hello printf ");fprintf(stdout,"hello fprintf ");write(1,"hello write", strlen("hello write "));fork();return0;}

如果直接运行，通常会看到三行输出。

但是如果执行输出重定向：

./a.out>log.txt

查看log.txt时，可能会看到类似结果：

hello write hello printf hello fprintf hello printf hello fprintf

也就是说：

• write的内容只出现了一次。
• printf和fprintf的内容出现了两次。
• write的内容还可能跑到最前面。

这个现象不是fork把代码从头执行了一遍，也不是printf出错了。关键在于：

printf/fprintf是 C 库函数，中间会经过用户态缓冲区；write是系统调用，会直接把数据交给内核。

当输出目标是显示器时，C 库通常采用行缓冲，遇到 就会尽快刷新，所以执行到fork()时，printf/fprintf的内容可能已经输出了。

但是当输出目标变成普通文件时，C 库通常会采用全缓冲。此时printf/fprintf的内容可能还留在用户态缓冲区中，没有马上写入文件。

接着执行fork()，父子进程都会带着这份尚未刷新出去的缓冲区内容。等父子进程各自退出时，都会刷新自己的那份缓冲区，于是同一份printf/fprintf内容就可能被写入两次。

而write不走 C 库用户态缓冲区，它在fork()前就已经通过系统调用写出去了，所以只出现一次。

补充图：重定向到文件后，printf/fprintf 和 write 的刷新路线不同。

这个实验不是为了单独展开“缓冲区专题”，而是为了说明一件事：

C 库函数和系统调用虽然都能完成输出，但它们中间隔着一层用户态封装，所以在 fork、重定向这些场景下，现象可能会不一样。

三、在 MiniShell 中如何实现重定向？

如果我们自己写一个简单的 shell，重定向应该在哪里做？

答案是：

必须在子进程中做，而且要先做重定向，再做程序替换。

3.1 为什么不能让父进程做重定向？

假设父进程就是我们的 shell。

如果父进程直接执行：

dup2(fd,1);

那么父 shell 自己的标准输出就被改掉了。之后提示符、命令执行结果等都可能写到文件中，终端就会被污染。

普通命令的重定向只是临时针对当前命令，不能影响整个 shell。

所以正确做法是：

1. 父进程fork创建子进程。
2. 子进程根据命令中的>、>>、<做重定向。
3. 子进程再执行execvp进行程序替换。
4. 父进程等待子进程退出，自己的标准输入输出不受影响。

补充图：MiniShell 中重定向的执行流程。

3.2 核心流程代码

在 MiniShell 中实现重定向，不能只写dup2，前面还要先把命令行中的重定向符号解析出来。比如：

ls-a-l>log.txtcat<input.txtls>>log.txt

可以定义一个变量记录重定向类型，再用一个指针保存目标文件名：

#defineNoneRedir0#defineInputRedir1#defineOutputRedir2#defineAppRedir3intredir=NoneRedir;char*filename=NULL;

解析命令行时，从后往前找<、>、>>，找到之后把命令和文件名切开：

voidTrimSpace(char**pos){while(**pos&&isspace(**pos)){(*pos)++;}}voidParseRedir(charcommand_buffer[],intlen){intend=len-1;while(end>=0){if(command_buffer[end]=='<'){redir=InputRedir;command_buffer[end]='\0';filename=&command_buffer[end]+1;TrimSpace(&filename);break;}elseif(command_buffer[end]=='>'){if(end-1>=0&&command_buffer[end-1]=='>'){redir=AppRedir;command_buffer[end]='\0';command_buffer[end-1]='\0';filename=&command_buffer[end]+1;TrimSpace(&filename);break;}else{redir=OutputRedir;command_buffer[end]='\0';filename=&command_buffer[end]+1;TrimSpace(&filename);break;}}end--;}}

解析完成后，子进程根据redir的不同取值完成对应的open + dup2：

voidDoRedir(){if(redir==InputRedir){intfd=open(filename,O_RDONLY);if(fd<0)exit(2);dup2(fd,0);close(fd);}elseif(redir==OutputRedir){intfd=open(filename,O_CREAT|O_WRONLY|O_TRUNC,0666);if(fd<0)exit(4);dup2(fd,1);close(fd);}elseif(redir==AppRedir){intfd=open(filename,O_CREAT|O_WRONLY|O_APPEND,0666);if(fd<0)exit(6);dup2(fd,1);close(fd);}}

最后再放到fork的子进程里执行。下面只写核心流程：

pid_tid=fork();if(id==0){// 子进程中处理重定向intfd=open(redir_file,O_WRONLY|O_CREAT|O_TRUNC,0666);if(fd<0){perror("open");exit(1);}dup2(fd,1);close(fd);// 重定向完成后，再进行程序替换execvp(myargv[0],myargv);// execvp 成功后不会走到这里perror("execvp");exit(1);}

这里的顺序不能反。

如果先execvp，程序替换成功后，当前代码就被替换掉了，后面的open和dup2根本执行不到。

所以一定是：

先重定向，再程序替换。

3.3 execvp 后重定向关系还在吗？

还在。

因为execvp替换的是进程用户态的代码和数据，比如代码段、数据段等。

但是文件描述符表属于进程的内核资源，默认不会因为程序替换而消失。

所以子进程完成dup2(fd, 1)后，再执行execvp替换成ls，新的ls程序一运行，它的 1 号标准输出就已经指向文件了。

这就是 shell 能实现：

ls-l>log.txt

的原因。

四、多进程下 close 会影响其他进程吗？

这里还有一个容易混的点：

父子进程都可能拿着同一个 fd，如果子进程执行close(fd)，会不会把父进程对应的文件也关掉？

一般不会。

原因在于内核文件对象有引用计数。可以先这样理解：

父进程 fd_array[1] ----\ ---> struct file 引用计数 = 2 子进程 fd_array[1] ----/

当某个进程调用：

close(fd);

内核主要做两件事：

1. 清空当前进程文件描述符表中对应的下标。
2. 将对应struct file的引用计数减一。

只有当引用计数减到 0，说明没有任何进程再使用这个打开文件对象了，内核才会真正释放相关资源。

所以一个进程close(fd)，只是自己不再使用这个文件，不会直接影响其他仍然持有该文件的进程。

这里还可以顺便区分两个场景：

五、全文总结

本篇主要围绕 Linux 文件 I/O 中的重定向展开。

首先通过实验理解了 fd 的分配规则：新文件打开时，操作系统会选择当前进程文件描述符表中最小的空闲下标作为新的 fd。也正因为这样，关闭 1 后再打开文件，新文件就会占用标准输出的位置，导致 printf 原本应该输出到屏幕的内容写入文件。

接着学习了 dup2，它的作用是让 newfd 成为 oldfd 的副本。比如 dup2(fd, 1) 就是让标准输出指向 fd 对应的文件，这也是输出重定向的核心。

后面还理解了 2>&1，它不是把错误写到数字 1，而是让标准错误复制当前标准输出的指向。最后把重定向放到 MiniShell 中，知道了重定向必须在子进程中完成，并且要先 dup2，再 execvp。

所以本篇最核心的一句话就是：

重定向不是修改 printf、scanf 这些函数，而是修改进程文件描述符表中对应 fd 背后的指向。

理解了这一点，>、>>、<、2>&1 和 MiniShell 重定向实现就能串起来了。
【Linux】基础 I/O 详解：从 fopen 到 open，终于搞懂 fd 为什么从 3 开始
【Linux进程控制】从exec程序替换到手写简易Shell：fork、execvp、环境变量与内建命令
【Linux系统篇】从 fork 到 WNOHANG：进程创建与等待机制详解