linux文件描述符0 1 2是否有可能不适用于stdin、stdout和stderr？

Question

当程序开始时，默认情况下，它是否采用stdin、stdout和stderr的文件描述符0、1和2？以及API调用，如open(...)，socket(...)不返回0、1和2，因为这些值已经被取了？有没有打开(...)的情况或套接字(...)将返回0、1或2。0、1和2与stdin、stdout和stderr无关。

Answer 1

1. 缺省情况下，当程序启动时，是否获取标准输入、标准输出和标准错误的文件描述符0 1 2。

如果您正常地在交互式shell中启动您的程序，则可以。

由@EJP提供：

如果程序是由inetd启动的，或者任何其他行为相同的东西，也会发生将套接字继承为fd0的情况。

1. 将调用诸如open(...)、socket(...)不返回0 1 2，因为这些值已被获取。

是。

1. 是否有打开(...)的案例或套接字(...)将返回0 1 2。

是的，如果你这样做的话

close(0)；close(1)；close(2)；open(...)；/*如果成功，此open将返回0 */

Answer 2

虽然有几个答案已经存在，但我发现他们没有足够的信息，他们解释了完整的故事。

由于我继续进行了更多的研究，我正在添加我的发现。

每当进程启动时，都会将正在运行的进程的条目添加到/proc/<pid>目录中。这是保存与流程相关的所有数据的地方。此外，在进程启动时，内核将3个文件描述符分配给进程，以便与称为stdin、stdout和stderr的3个数据流进行通信。

linux内核使用一种算法来始终创建一个具有最低可能整数值的FD，因此这些数据流被映射到数字0、1和2。

因为这些只是对流的引用，我们可以关闭流。可以很容易地调用close(<fd>) (在本例中为close(1) )来关闭文件描述符。

在执行ls -l /proc/<pid>/fd/时，我们只看到0和2中列出了2个FD。

如果我们现在做一个open()调用，内核将创建一个新的FD来映射这个新的文件引用，由于内核使用最小整数优先算法，它将获取整数值1。

现在，新创建的FD指向我们打开的文件(使用open()系统调用)

现在发生的任何数据传输都不是通过先前链接的默认数据流，而是通过我们打开的新文件。

是的，我们可以将FD 0、1或2映射到任何文件，而无需映射到stdin、stdout或stderr