Linux管道与文件描述符：exec()前为何要关闭管道的文件描述符？

首先纠正一个理解偏差：close(0)释放的是**标准输入（STDIN）**对应的文件描述符，标准输出STDOUT的文件描述符编号是1，不要搞混。

接下来逐一解释你的疑问：

为什么执行exec前需要调用close(0) #

这是dup()系统调用的规则决定的：dup(oldfd)会复制oldfd对应的文件描述符，返回当前进程可用的最小未占用文件描述符编号。
我们的目标是让后续运行的wc命令从管道读端读取输入，而wc默认是从固定编号为0的标准输入读数据，所以需要把管道读端映射到fd 0的位置。先调用close(0)就是主动释放fd 0的占用，这样接下来调用dup(p[0])的时候，系统会自动把管道读端绑定到刚释放的fd 0上，刚好符合我们的需求。

关闭0之后进程怎么知道从哪读数据 #

close(0)只是解除了fd 0和原来的标准输入（比如终端）的绑定，后面的dup(p[0])已经重新给fd 0绑定了管道读端的引用。此时fd 0对应的就是管道的读端，wc运行时还是从固定的fd 0读数据，自然能读到父进程写入管道的内容。

移除close(0)会有什么差异 #

如果不提前关闭fd 0，fd 0仍然绑定着原来的标准输入资源，dup(p[0])返回的就会是当前最小的可用fd，通常是3（进程启动时默认0、1、2分别绑定标准输入、输出、错误）。此时管道读端只绑定在fd 3上，wc还是从fd 0读数据，根本不会读取管道里的内容，程序要么阻塞等待终端输入，要么输出的是终端输入的统计结果，完全达不到预期。

子进程为什么要调用close(p[0])和close(p[1]) #

• 关闭p[0]：我们已经通过dup把管道读端复制到了fd 0，p[0]这个文件描述符已经没有任何作用，留着只会占用进程的文件描述符表资源，直接关闭即可。
• 关闭p[1]：这是管道正常工作的必要操作。管道的读端只有在所有持有写端的进程都关闭写端后，read操作才会返回EOF。如果子进程不关闭p[1]，就算父进程已经关闭了自己持有的p[1]，子进程仍然持有写端引用，管道会认为还有进程可能写入数据，wc读完管道内的全部内容后会一直阻塞等待后续输入，永远不会退出。

内容的提问来源于stack exchange，提问作者Mattmmmmm