[linux仓库]解剖Linux内核：文件描述符（fd）的‘前世今生’与内核数据结构探秘
深入理解文件描述符，不仅能帮我们掌握 Linux 下文件 IO 的底层标识逻辑，还能进一步解释一个更实用的场景：为什么我们在终端中执行 ls > test.txt 时，原本要输出到屏幕的内容会 “转移” 到文件里？这背后的核心机制，正是基于文件描述符的重定向。接下来，我们就从 open 返回值的意义切入，逐步拆解文件描述符的本质、规则，以及重定向的实现原理。
open返回值
int open(const char *pathname, int flags, .../* mode_t mode */ );
我们之前对open接口的三个参数做了依次介绍，而返回值放在本章节进行介绍，是为了和文件描述符联系起来。
int main()
{
umask(0);
//int fd = open("log.txt", O_WRONLY | O_CREAT | O_TRUNC, 0666);
int fd0 = open("log0.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
int fd1 = open("log1.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
int fd2 = open("log2.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
int fd3 = open("log3.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
printf("fd0: %d\n", fd0);
printf("fd1: %d\n", fd1);
printf("fd2: %d\n", fd2);
printf("fd3: %d\n", fd3);
close(fd0);
close(fd1);
close(fd2);
close(fd3);
return 0;
}
我们对open的返回值进行打印查看:
fd0:3
fd1:4
fd2:5
fd3:6
我们看到的这些打印结果 —— 它们就是文件描述符 fd，本质是数组下标。
所以到底什么是文件描述符呢?为什么下标又是从3开始的呢?为什么没有0、1、2呢?
文件描述符
OS 打开文件时，只通过文件描述符 fd 来识别(只认fd,不认文件)。
进程和文件是 1 : n 的关联关系
一个进程能打开多个文件，这就使得 OS 内部必然会存在大量被打开的文件！！！那么需要进行管理吗？如何管理呢？
先描述，再组织！！！
每个进程都有对应的task_struct结构体,而内部含有一个struct files_struct *files指针,指向当前进程的文件管理结构，是进程与文件交互的 “总入口”。
fd_array 指针数组：数组下标就是文件描述符（fd） 。
内核的 struct file 链表：管理 “系统中所有打开的文件”:大量被进程打开的文件，通过 struct file 链表组织 。对文件的打开、关闭、读写等操作，转化为链表的增删查改，实现高效管理。
0 & 1 & 2
那么0、1、2分别被谁占着呢？
Linux进程默认情况有3个缺省打开的⽂件描述符:
标准输⼊ 0
标准输出 1
标准错误 2
0,1,2对应的物理设备⼀般是：键盘，显⽰器，显示器。
文件描述符就是从0开始的整数。当我们打开⽂件时，操作系统在内存中要创建相应的数据结构来描述⽬标⽂件。于是就有了file结构体。表⽰⼀个已经打开的⽂件对象。⽽进程执⾏open系统调⽤，所以必须让进程和⽂件关联起来。每个进程都有⼀个指针*files, 指向⼀张表files_struct,数组的每个下标，都指向内核中描述 “已打开文件” 的 struct file 结构体
本质上，⽂件描述符就是该数组的下标。只要拿着⽂件描述符，就可以找到对应的⽂件。
那该如何证明0、1、2确实如我们所说呢？将标准输入、输出、错误进行打印，如果证明确实是0、1、2，不就说明的确如此。
_fileno指的是文件描述符fd
int main()
{
printf("stdin->%d\n",stdin->_fileno); // 0
printf("stdout->%d\n",stdout->_fileno); // 1
printf("stderr->%d\n",stderr->_fileno); // 2
return 0;
}
FILE(扩展)
还记得上一章节我们用 C 语言操作文件时，频繁接触的FILE吗？当时我们只需调用fopen、fread这些库函数，就能轻松完成文件的读写，似乎不用关心底层细节。
但这里有个关键问题：我们之前说过，OS只认文件描述符（fd）
既然如此，FILE又是什么？
FILE是 C 标准库精心设计的一个结构体。
根据我们前面所说OS只认fd，因此我们可以推测FILE结构体里一定封装一个整数，且这个整数一定是fd!!!(确实如此)
struct _IO_FILE
{
int _flags; /* High-order word is _IO_MAGIC; rest is flags. */
/* The following pointers correspond to the C++ streambuf protocol. */
char *_IO_read_ptr; /* Current read pointer */
char *_IO_read_end; /* End of get area. */
char *_IO_read_base; /* Start of putback+get area. */
char *_IO_write_base; /* Start of put area. */
char *_IO_write_ptr; /* Current put pointer. */
char *_IO_write_end; /* End of put area. */
char *_IO_buf_base; /* Start of reserve area. */
char *_IO_buf_end; /* End of reserve area. */
/* The following fields are used to support backing up and undo. */
char *_IO_save_base; /* Pointer to start of non-current get area. */
char *_IO_backup_base; /* Pointer to first valid character of backup area */
char *_IO_save_end; /* Pointer to end of non-current get area. */
struct _IO_marker *_markers;
struct _IO_FILE *_chain;
int _fileno;
int _flags2;
__off_t _old_offset; /* This used to be _offset but it's too small. */
/* 1+column number of pbase(); 0 is unknown. */
unsigned short _cur_column;
signed char _vtable_offset;
char _shortbuf[1];
_IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};
类
再看 C++ 中的stdin、stdout、stderr（对应流对象cin、cout、cerr）：它们虽然是以类的形式存在，但本质上与结构体并无本质鸿沟 —— 类不过是在结构体基础上增加了成员函数和运算符重载的扩展形式。而我们完全可以肯定，这些类的内部一定藏着一个核心成员：文件描述符（fd）。
而无论是通过 C 的FILE结构体，还是 C++ 的流类操作文件，有一个底层逻辑始终不变：任何对文件内容的增、删、查、改，都必须先经过内核缓冲区 —— 操作系统会先将文件数据预加载到这块内核空间的缓冲区中，后续的读写操作实际是与缓冲区交互，而非直接操作磁盘。这样既能减少对硬件的直接访问（降低开销），也能通过缓冲区的合并、延迟写入等机制提升整体 I/O 效率，这是所有文件操作绕不开的底层环节。
分配规则
文件描述符的分配规则:给新打开的文件分配fd，从文件描述符数组中寻找:最小的，没有被使用的下标，作为该文件的fd
关闭fd为0的文件
关闭fd为2的文件
关闭fd为1的文件
int main()
{
close(1);
int fd = open("log.txt",O_CREAT | O_WRONLY | O_TRUNC,0666);
if(fd<0)
{
perror("fd");
return 1;
}
printf("hello file,fd:%d\n",fd); // stdout -> 1
close(fd);
return 0;
}
我们会发现显示器上不打印内容了?我写入的信息跑哪里去了呢??
这也验证了我们前面所说，fd为1的文件默认为stdout。此时把1关闭了，给新打开的文件分配到了1的位置，因此显示器上并打印显示我们想要的内容。
打印 log.txt里的内容看看：
不对啊，怎么还是没有看到我们想要的内容呢?为什么会看不到啊？！
printf默认是往1位置进行打印，即写入。此时我们的fd=1位置已经被换成log.txt文件了，而printf在上层并不知道fd=1的位置被替换了，还是傻傻地往该位置进行写入，即打印到文件里。
同样地，scanf默认往fd为0的位置上读取，此时0位置也被狸猫换太子了，导致是往log.txt文件读取内容。
解决方法
第一种：往文件描述符1写入内容后，1位置又被我们关闭了，那么不关闭1位置是否就能看到我们想要的内容了呢？
第二种：fflush功能是立即清空指定流的缓冲区，并将其中的数据强制写入到关联的目标设备中。
重定向
上述关闭fd为1的文件的代码跟重定向似乎是很类似的啊？会不会重定向的底层就是这样实现的呢？实际上重定向功能实现不是这样做的，而是通过dup2函数
有了重定向的概念和本质理解，那么如果创建子进程，子进程是如何看待父进程打开的文件的?
当父进程通过 fork 创建子进程时，子进程对父进程已打开文件的 “继承”，本质是对内核文件对象的 “指针共享”：
子进程会完整拷贝父进程的 file_struct（进程文件描述符表的容器），但其中每个文件描述符（fd）对应的指针，都指向同一个内核级 struct file 对象（该对象存储了文件偏移、打开模式、引用计数 ref_count 等核心元信息）。
如果我们做exec程序替换，不会创建新进程，会影响我们历史打开的文件吗?? 不会!!!
添加重定向功能
//支持重定向功能
#define NONE_REDIR 0
#define OUPUT_REDIR 1
#define APPEND_REDIR 2
#define INPUT_REDIR 3
std::string filename;
int redir_type = NONE_REDIR;
//初始化化数据
void InitGlobal()
{
gargc = 0;
memset(gargv,0,sizeof(gargv));
filename.clear();
redir_type = NONE_REDIR;
}
//3.对命令进行解析，支持重定向功能
void CheckRedir(char cmd[])
{
char* start = cmd;
char* end = cmd + strlen(cmd) - 1;
while(start<=end)
{
//1.> >> 输出或追加
if(*start=='>')
{
if(*(start+1)=='>')
{
//>> 追加
*start='\0';
redir_type = APPEND_REDIR;
start+=2;
//去掉空格
TrimSpace(start);
filename=start;
break;
}
else
{
//> 输出
*start = '\0';
redir_type = OUPUT_REDIR;
start++;
//去掉空格
TrimSpace(start);
filename=start;
break;
}
}
//2. < 输入
else if(*start == '<')
{
*start='\0';
redir_type = INPUT_REDIR;
start++;
TrimSpace(start);
filename=start;
break;
}
else
{
start++;
}
}
}
//5.执行命令，让子进程来执行！！！
void ForkAndExec()
{
pid_t id = fork();
if(id<0)
{
perror("fork"); //将错误码转为错误信息
return;
}
else if(id == 0) //子进程
{
//支持重定向功能
if(redir_type == OUPUT_REDIR)
{
//输出 >
int output = open(filename.c_str(),O_CREAT | O_TRUNC | O_WRONLY,0666);
dup2(output,1);
}
else if(redir_type == APPEND_REDIR)
{
//追加 >>
int appendfd = open(filename.c_str(),O_CREAT | O_APPEND | O_WRONLY);
dup2(appendfd,1);
}
else if(redir_type == INPUT_REDIR)
{
//输入 <
int input = open(filename.c_str(),O_RDONLY);
dup2(input,0);
}
else
{
//什么都不做
}
execvp(gargv[0],gargv);
exit(0);
}
else
{
//父进程
//等待子进程
int status = 0;
pid_t rid = waitpid(id,&status,0);
if(rid > 0)
{
lastcode = WEXITSTATUS(status);
}
}
}
总结
本文深入探讨Linux文件描述符(FD)机制，从open系统调用返回值切入，揭示FD作为数组下标的本质特性。通过分析进程task_struct中的files_struct结构，阐明0/1/2分别对应标准输入/输出/错误的分配规则，并验证了FILE结构体与FD的封装关系。重点讲解了FD分配规则、重定向实现原理（通过dup2系统调用）及父子进程间的FD继承机制。最后演示了在Shell中实现重定向功能的具体代码实现，包括输出重定向(>)、追加重定向(>>)和输入重定向(<)的处理逻辑。全文贯通理论讲解与实践验证，完整呈现了Linux文件IO的核心机制。
————————————————
版权声明：本文为CSDN博主「egoist祈」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/egoist2023/article/details/150956083
