主页 / unix / 问题 / 450713
Accepted
Fixee
Asked: 2018-06-20 11:46:00 +0800 CST

命名管道、文件描述符和 EOF

  • 772

两个窗口，同一用户，带有 bash 提示。在 window-1 类型中：

$ mkfifo f; exec <f

所以 bash 现在正试图从映射到命名管道的文件描述符 0 中读取f。在 window-2 类型中：

$ echo ls > f

现在 window-1 打印一个 ls 然后 shell 死掉了。为什么？

下一个实验：用 再次打开 window-1 exec <f。在 window-2 类型中：

$ exec 3>f
$ echo ls >&3

在上面的第一行之后，window-1 被唤醒并打印一个提示。为什么？在上面的第二行之后，window-1 打印ls输出并且 shell 保持活动状态。为什么？实际上，现在在window-2 中，echo ls > f并没有关闭window-1 外壳。

答案一定与window-2中引用命名管道的文件描述符3的存在有关？！

fifo file-descriptors

3 个回答

  1. Best Answer

    它与文件描述符的关闭有关。

    在您的第一个示例中，echo写入其标准输出流，shell 打开该流以将其与 连接f，当它终止时，其描述符被关闭（由 shell）。在接收端，从其标准输入流（连接到f）读取输入的 shell 读取ls、运行ls，然后由于其标准输入上的文件结束条件而终止。

    文件结束条件的发生是因为命名管道的所有写入者（本例中只有一个）都关闭了管道的末端。

    在您的第二个示例中，exec 3>f打开文件描述符 3 以写入f，然后echo写入ls它。现在打开文件描述符的是shell，而不是echo命令。描述符保持打开状态，直到您这样做exec 3>&-。在接收端，从其标准输入流（连接到f）读取输入的 shellls运行ls，然后等待更多输入（因为流仍然打开）。

    流保持打开状态，因为它的所有写入者（shell、viaexec 3>f和echo）都没有关闭它们的管道末端（exec 3>f仍然有效）。

    我在上面写过echo，好像它是一个外部命令。它很可能是内置在外壳中的。效果还是一样的。

    • 13

  2. 没什么：当管道没有写入器时，它看起来对读取器关闭，即在读取时返回 EOF 并在打开时阻塞。

    从 Linux 手册页（pipe(7)另请参阅fifo(7)）：

    如果所有引用管道写入端的文件描述符都已关闭，read(2)则从管道尝试将看到文件结束（read(2)将返回 0）。

    关闭写端是在结尾隐式发生的echo ls >f，正如你所说，在另一种情况下，文件描述符保持打开状态。

    • 7

  3. 在阅读了@Kusalananda 和@ikkachu 的两个答案后，我想我明白了。在 window-1 中，shell 正在等待打开管道的写入端然后关闭它的东西。一旦写入端打开，window-1 中的 shell 就会打印一个提示。一旦写入端关闭，shell 就会获得 EOF 并死亡。

    在 window-2 方面，我们有我的问题中描述的两种情况：在第一种情况下echo ls > f，没有文件描述符 3，所以我们有echo产卵，它stdin看起来stdout像这样：

    0 --> tty
1 --> f

    然后echo终止，shell 关闭两个描述符。由于文件描述符 1 已关闭并引用f， 的写入端f已关闭，这会导致窗口 1 出现 EOF。

    在第二种情况下，我们exec 3>f在我们的 shell 中运行，导致 shell 采用这个环境：

    bash:
0 --> tty
1 --> tty
2 --> tty
3 --> f

    现在我们运行echo ls >& 3，shell 分配文件描述符echo如下：

    echo:
0 --> tty
1 --> f     # because 3 points to f
2 --> tty

    然后 shell 关闭上面的三个描述符，包括f，但f仍然有来自 shell 本身的引用。这是重要的区别。正如@Kusalananda 所指出的，关闭描述符 3exec 3>&-将关闭最后一个打开的引用并导致窗口 1 的 EOF。

    • 3

相关问题