我正在尝试了解三个流的行为 - stdout、stdin 和 stderr。我无法从任何教科书中得到答案，所以我来到了这里。
我知道这三个存储在文件描述符表中，文件描述符为 0 (stdin)、1 (stdout) 和 2 (stderr)。我也知道这些不仅仅是文件描述符，而是可以重定向的 I/O 流。好的，那分享一下怎么样？
考虑三种情况：
execl("./a.out", "a.out", NULL); ，那么这个新的可执行文件会获得标准输入、标准错误和标准输出的新副本吗？欢迎所有明智的答案。
【问题讨论】：
标签： multithreading exec stdout stdin stderr
为了了解发生了什么，请考虑这些是跨流程边界的通信渠道。我将避免将它们称为流，因为它们在不同的上下文中使用，但它们是相关的。
现在，首先，文件描述符只是代表这些通道的进程特定表的索引，它们基本上是一种不透明的句柄。但是，这里是第一个答案：由于线程是进程的一部分，它们也共享这些描述符，所以如果你从两个线程写入同一个通道，它会通过同一个通道离开，所以在进程之外，两个线程无法区分。
然后，当调用 fork() 时，该过程被有效地复制。这是通过写时复制优化完成的，但这意味着它们也有不同的表来表示这些通信通道。一个进程中索引为 2 的条目与 fork 中索引为 2 的条目不同。这对于进程内的任何结构都是相同的，如果您在其中创建了 C FILE* 或 C++ std::stream，它也会与其他数据一起被复制。
当调用 execl() 时，进程仍然“拥有”某些外部通道。这些是从管理进程的操作系统分配给它的。这意味着索引 2 仍然可以用于与外界通信。在启动时，运行时库将创建例如FILE* 用于在 C 中用于三个众所周知的通道 stdin、stdout 和 stderr。
剩下的问题是当一个进程被分叉到外部的通道时会发生什么。在这里，答案很简单，通道是关闭的还是继承的，可以在每个通道的基础上进行配置。如果它被继承，它在子进程中仍然可用。任何写入继承通道的内容都将在父进程的输出结束时结束。
关于分叉进程的标准输入，我实际上不确定，我认为输入默认是关闭的输入之一，因为将输入发送到多个目标没有意义。此外，我从未发现需要在子进程中实际处理来自 stdin 的输入，除非该输入是由父进程专门提供的（类似于 shell 中的管道，尽管它们是兄弟而不是父子进程）。
注意：我不确定此描述是否清楚，请不要犹豫，我会尽力改进以供您理解。
【讨论】：
让我们假设相反。
如果它们不共享相同的位置（本质上就是文件描述符），那么这些场景将不得不让人联想到一些东西？这可能吗 - 人们会从确定性机器得出结论，它不是。
答案就在这里。是的，他们共享相同的位置。
【讨论】：