在 { fd1>&fd3 } 之后，fd3>&fd1 如何（内部）将原始 fd 放回（或不放回）fd1？（“坏文件描述符”）

因此，稍微简化一下，你有

{ a 2>&1 1>&3 | b; } 3>&1

现在，括号组外部的重定向需要与括号组内部的重定向分开处理；它们需要在括号组中的任何内容运行之前设置。因此，括号组会发现 fds 1 和 3 指向同一个位置（原始标准输出）。

然后，管道将左侧进程的标准输出重定向到右侧进程的标准输入。这也会在任何一侧或其重定向运行之前发生。

让我们用进程替换语法重写它，只是为了按从左到右的顺序显示重定向。 _{（>(b)运行b，使其 stdin 可用作文件名，并扩展为该名称。因此1> >(b)将 stdout 重定向到该“文件”和b的 stdin。）}

{ a 1> >(b) 2>&1 1>&3; } 3>&1

甚至，

a 3>&1 1> >(b) 2>&1 1>&3

因此，a首先将原始 stdout(1) 复制到 fd 3（大括号组之外的重定向）。

然后，b启动，a的 stdout(1) 重定向到b的标准输入。a的标准错误(2) 也重定向到 的标准输入。现在，fd 1 和 2 转到b，fd 3 转到原始的标准输出。

最后，a的 stdout(1) 被重定向到 fd 3 所在的位置，即原始 stdout 的副本，实际上撤消了之前将 stdout 重定向到 的操作b。现在，fd 1 再次转到原始 stdout，而 fd 2 转到。正如另一个答案b中提到的，现在您也可以使用 关闭 fd 3，因为它不再需要了。3>&-

这样写，有人可能会问这是否有意义，为什么不这样做呢：

a 2> >(b)

当然可以，但是管道语法不允许指定要重定向到管道的 fd 或 fds，它始终只是标准输出 (stdout)。而且进程替换不是 POSIX 特性，所以并非所有 shell 都支持它，而且还有一个烦人的特性：当主 shell 继续运行时，从进程替换启动的进程可能会在后台继续运行，而不像管道那样，shell 会等待管道的所有部分完成。

那里1>&2的也“撤消”了，2>&1因为当的 stderra被重定向到管道时，来自管道的 stdout（整个括号组）被重定向回脚本的 stderr。

我认为您感到困惑，因为大多数关于文件描述符重复的描述都有些模糊，很容易错过理解这一点的重要细节。

5>/path/to/file

当进程打开文件的文件描述符时，进程与文件之间就会形成一个输入/输出通道（当打开的对象是目录、流、网络文件等时，情况也是如此）。您可以将其想象成进程与文件之间的管道，这是一个理解基本细节的良好模型：管道两端——一端指向进程，另一端指向文件。 这篇博文对我在这里讨论的通道/管道进行了很好的描述。

6>&5

复制文件描述符可以理解为创建第二个管道。该管道的编号在进程端有所不同，但新管道的另一端指向同一个文件。这两个文件描述符各自拥有一个指向同一目标文件的通道。

5>/dev/null

在脚本的后续部分，原始文件描述符可能会被更改为其他目标文件/设备。许多关于重定向的描述会忽略这样一个事实：当描述符已打开时，此重定向会执行两个步骤而不是一个步骤。原始文件描述符 (5) 通道会关闭，移除其指向原始文件的管道，然后该描述符会打开一个指向新文件的新通道（管道）。

这不会改变重复的文件描述符（6），因为它仍然具有到原始文件的管道。

5>&6

现在，脚本想要将更改的文件描述符 (5) 恢复到原始文件。关闭通往新目标的开放管道，并将复制的描述符 (6) 再次复制到原始描述符 (5)。现在，原始描述符再次连接到原始文件。

6>&-

某些脚本现在会在完成其用途后关闭重复的描述符。现在只有原始描述符 (5) 对原始文件开放。

关键概念是，打开的文件描述符就像一条管道，一端指向进程，另一端指向文件/目录/设备/流/其他对象。复制描述符会在进程端产生新的内容，但在文件端，它指向的是同一个地方。

我在上面的例子中使用了描述符 5 和 6，但这种将描述符复制到另一个描述符并将其恢复回来的操作通常使用 stdin (0)、stdout (1) 或 stderr (2) 的描述符来完成。