为什么每次运行“$EDITOR >(cmd)”时终端都会冻结？

编辑器正在尝试从您指定的文件中读取当前read()文本，就像文本编辑器通常所做的那样。由于尚未向管道写入任何内容（但管道仍处于打开状态以供写入），因此编辑器将永远停留在调用中等待数据到达。

要使这个想法奏效，您需要使用创建一个命名管道mkfifo。启动编辑器，并（同时在后台）将文本 cat/echo 到管道 - 即使没有文本，在将管道交给“读取器”程序之前，至少打开和关闭一次管道进行写入仍然很重要。这可能很难在 bash 中实现，因为当要求 nano 写入新文本时，读取器需要已经在运行，但必须在 nano 已经读取原始文本后才能运行。

mktemp对于常规临时文件来说这是一个更好的主意。

使用>(…)为您的编辑器提供一个代表管道“写入”端的文件描述符（而 cat 则持有“读取”端），以及/dev/fd/###该文件描述符的样式路径。

• 命令行参数：[ nano, /dev/fd/63]
• 文件描述符：{ 0←tty, 1→tty, 2→tty, 63→pipe}

但是编辑器不会明确地将/dev/fd路径识别为“这代表我已经拥有的 FD，因此我们就使用它吧”——相反，编辑器会将其视为任何其他路径，调用open()并获取新的文件描述符。（它仍然不知道它有 FD #63。）

但是，在 Linux 上，这种方式/dev/fd（不仅适用于管道，而且适用于尝试重新打开“文件描述符路径”）是将其视为打开该文件或对象的全新尝试，而不是 1:1 复制文件描述符。

• 编辑做：open("/dev/fd/63", O_RDONLY)⇒3
• FD 现在：{ 0←tty, 1→tty, 2→tty, 3←pipe, 63→pipe}

因此，如果编辑器打开此路径进行读取，它实际上会获得管道“读取”端的文件描述符，而不是“写入”端 - 因此，后续read()调用不会立即失败并出现“尝试从只写 FD 读取”错误，就像原始 FD 一样，但会阻止等待数据。

从这个意义上讲，Linux/dev/fd匿名管道路径的行为与命名管道的常规路径的行为相同。如果您使用 创建管道mkfifo ~/foo，编辑器也会打开它进行读取，并且会在尝试读取时卡住 - 直到您将某些内容回显到管道。

但最重要的是：只有当写入端完全关闭时，管道才会报告“文件结束” 。因此，由于编辑器仍然在不知不觉中保留了“写入”端的原始文件描述符 #63，这意味着始终有一个活动的写入器 - 编辑器本身 - 即使它能够通过管道接收一些数据（例如，通过手动“回显”写入/proc/PID/fd），它仍将永远等待“文件结束”指示。实际上，编辑器本身陷入了死锁。

后一个问题不会发生在命名管道中，因为管道没有预先存在的打开文件描述符——假设echo yay > ~/yay是唯一的写入器，因此一旦它退出，编辑器就会到达“EOF”并显示文本。因此，如果您想进行实验，我强烈建议您尝试使用命名管道，以获得比涉及的方法更受控制的环境/dev/fd。