文件描述符 dup/dup2函数

一、文件描述符

文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数（通常是小整数），用于指代被打开的文件，所有执行I/O操作的系统调用都通过文件描述符。

一个进程当前有哪些打开的文件描述符可以通过/proc/进程ID/fd目录查看。

标准文件描述符：

POSIX标准要求每次打开文件时（含socket）必须使用当前进程中最小可用的文件描述符号码

二、文件描述符表

系统为每一个进程维护了一个文件描述符表，该表的值都是从0开始的

内核使用3种数据结构表示打开文件。

   1. 进程级的文件描述符表（进程表项）

    2. 系统级的打开文件描述符表（文件表项）

     3. 文件系统的i-node表（v节点表项、i节点）

进程级的描述符表（进程表项）：

  每一条目记录了单个文件描述符的相关信息。

   1. 文件描述符标志（控制文件描述符操作的一组标志，目前此类标志仅定义了一个，即close-on-exec标志）

      2. 对打开文件句柄的引用

打开文件表（文件表项）：

内核对所有打开的文件的文件维护有一个系统级的描述符表格，也称之为打开文件表，并将表格中各条目称为打开文件句柄（open file handle）。

一个打开文件句柄存储了与一个打开文件相关的全部信息：

    1. 当前文件偏移量（调用read()和write()时更新，或使用lseek()直接修改）

    2. 打开文件时所使用的状态标识（即，open()的flags参数）

    3. 文件访问模式（如调用open()时所设置的只读模式、只写模式或读写模式）

    4. 与信号驱动相关的设置

    5. 对该文件i-node对象的引用

    6. 文件类型（例如：常规文件、套接字或FIFO）和访问权限

   7. 一个指针，指向该文件所持有的锁列表

    8. 文件的各种属性，包括文件大小以及与不同类型操作相关的时间戳

i节点：

相当于磁盘上的文件

在进程A中，文件描述符1和30都指向了同一个打开的文件句柄（标号23）。这可能是通过调用dup()、dup2()、fcntl()或者对同一个文件多次调用了open()函数而形成的。

进程A的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄（标号73）。这种情形可能是在调用fork()后出现的（即，进程A、B是父子进程关系），或者当某进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程时，也会发生。再者是不同的进程独自去调用open函数打开了同一个文件，此时进程内部的描述符正好分配到与其他进程打开该文件的描述符一样。

此外，进程A的描述符0和进程B的描述符3分别指向不同的打开文件句柄，但这些句柄均指向i-node表的相同条目（1976），换言之，指向同一个文件。发生这种情况是因为每个进程各自对同一个文件发起了open()调用。同一个进程两次打开同一个文件，也会发生类似情况。

三、文件描述符要点

1. 由于进程级文件描述符表的存在，不同的进程中会出现相同的文件描述符，它们可能指向同一个文件，也可能指向不同的文件

2. 两个不同的文件描述符，若指向同一个打开文件句柄，将共享同一文件偏移量。因此，如果通过其中一个文件描述符来修改文件偏移量（由调用read()、write()或lseek()所致），那么从另一个描述符中也会观察到变化，无论这两个文件描述符是否属于不同进程，还是同一个进程，情况都是如此。

3. 要获取和修改打开的文件标志（例如：O_APPEND、O_NONBLOCK和O_ASYNC），可执行fcntl()的F_GETFL和F_SETFL操作，其对作用域的约束与上一条颇为类似。

4. 文件描述符标志（即，close-on-exec）为进程和文件描述符所私有。对这一标志的修改将不会影响同一进程或不同进程中的其他文件描述符

5.文件描述符、文件描述符标志（CLOEXE）、文件状态标志（指打开文件设置的只读只写那种的flag）

http://blog.csdn.net/cywosp/article/details/38965239

四、dup和dup2

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

dup函数：

内核在进程中创建一个新的文件描述符，此描述符是当前可用文件描述符的最小数值，这个文件描述符指向oldfd所拥有的文件表项。

返回：新的fd

新的fd被复制为oldfd，具有相同的文件表项、指向同一文件节点

dup2函数：

和dup的区别就是可以用newfd参数指定新描述符的数值，

如果newfd已经打开，则内核会先将其关闭。如果newfd等于oldfd，则dup2返回newfd, 而不关闭它。dup2函数返回的新文件描述符同样与参数oldfd共享同一文件表项。

可以用来重定向STDOUT_FINLENO，STDIN_FINLENO

返回：newfd

newfd被复制为oldfd，具有相同的文件表项、指向同一文件节点

实际上，调用dup(oldfd)等效于
fcntl(oldfd, F_DUPFD, 0)
而调用dup2(oldfd, newfd)等效于
close(oldfd)；
fcntl(oldfd, F_DUPFD, newfd)；

例子：CGI中dup2
1.写过CGI程序的人都清楚，当浏览器使用post方法提交表单数据时，CGI读数据是从标准输入stdin，写数据是写到标准输出stdout(C语言利用printf函数)。按照我们正常的理解，printf的输出应该在终端显示，原来CGI程序使用dup2函数将STDOUT_FINLENO(这个宏在unitstd.h定义，为１)这个文件描述符重定向到了连接套接字。
dup2(connfd, STDOUT_FILENO)；　
一个进程默认的文件描述符１(STDOUT_FILENO)是和标准输出stdout相关联的，对于内核而言，所有打开的文件都通过文件描述符引用，而内核并不知道流的存在(比如stdin、stdout)，所以printf函数输出到stdout的数据最后都写到了文件描述符１里面。至于文件描述符0、１、2与标准输入、标准输出、标准错误输出相关联，这只是shell以及很多应用程序的惯例，而与内核无关。
用下面的流图可以说明问题:(ps: 虽然不是流图关系，但是还是有助于理解)
printf －> stdout －> STDOUT_FILENO(1) －> 终端(tty)
printf最后的输出到了终端设备，文件描述符１指向当前的终端可以这么理解：
STDOUT_FILENO = open("/dev/tty", O_RDWR);
使用dup2之后STDOUT_FILENO不再指向终端设备，而是指向connfd, 所以printf的输出最后写到了connfd。是不是很优美？

2. 如何在CGI程序的fork子进程中还原STDOUT_FILENO

追本溯源，打开当前终端恢复STDOUT_FILENO。
分析流图，STDOUT_FILENO是如何和终端关联的？我们重头做一遍不就行了，代码实现如下：
ttyfd = open("/dev/tty", O_RDWR);
dup2(ttyfd, STDOUT_FILENO);
close(ttyfd);
/dev/tty是程序运行所在的终端，这个应该通过一种方法获得。实践证明这种方法是可行的，但是个人总感觉有些不妥，不知道为什么，可能一些潜在的问题还没出现。

http://blog.csdn.net/fulinus/article/details/9669177