文件描述符（0、1、2）的用法

在 前面的[2] 尖括号教程中[3]，你看到了如何使用 >，如下：

1. ls > list.txt

将 ls 输出传递给 list.txt 文件。

现在我们看到的是简写：

1. ls 1> list.txt

在这种情况下，1 是一个文件描述符，指向标准输出（stdout）。

以类似的方式，2 指向标准错误输出（stderr）：

1. ls 2> error.log

所有错误消息都通过管道传递给 error.log 文件。

回顾一下：1> 是标准输出（stdout），2> 是标准错误输出（stderr）。

第三个标准文件描述符，0< 是标准输入（stdin）。你可以看到它是一个输入，因为箭头（<）指向0，而对于 1 和 2，箭头（>）是指向外部的。

标准文件描述符有什么用？

如果你在阅读本系列以后，你已经多次使用标准输出（1>）的简写形式：>。

例如，当（假如）你知道你的命令会抛出一个错误时，像 stderr（2）这样的东西也很方便，但是 Bash 告诉你的东西是没有用的，你不需要看到它。如果要在 home/ 目录中创建目录，例如：

1. mkdir newdir

如果 newdir/ 已经存在，mkdir 将显示错误。但你为什么要关心这些呢？（好吧，在某些情况下你可能会关心，但并非总是如此。）在一天结束时，newdir 会以某种方式让你填入一些东西。你可以通过将错误消息推入虚空（即 ``/dev/null`）来抑制错误消息：

1. mkdir newdir 2> /dev/null

===========================================================================

这不仅仅是 “让我们不要看到丑陋和无关的错误消息，因为它们很烦人”，因为在某些情况下，错误消息可能会在其他地方引起一连串错误。比如说，你想找到 /etc 下所有的 .service 文件。你可以这样做：

1. find /etc -iname "*.service"

但事实证明，在大多数系统中，find 显示的错误会有许多行，因为普通用户对 /etc 下的某些文件夹没有读取访问权限。它使读取正确的输出变得很麻烦，如果 find 是更大的脚本的一部分，它可能会导致行中的下一个命令排队。

相反，你可以这样做：

1. find /etc -iname "*.service" 2> /dev/null

而且你只得到你想要的结果。

单独的文件描述符 stdout 和 stderr 还有一些注意事项。如果要将输出存储在文件中，请执行以下操作：

1. find /etc -iname "*.service" 1> services.txt

工作正常，因为 1> 意味着 “发送标准输出且自身标准输出（非标准错误）到某个地方”。

但这里存在一个问题：如果你想把命令抛出的错误信息记录到文件，而结果中没有错误信息你该怎么做？上面的命令并不会这样做，因为它只写入 find 正确的结果，而：

1. find /etc -iname "*.service" 2> services.txt

只会写入命令抛出的错误信息。

我们如何得到两者？请尝试以下命令：

1. find /etc -iname "*.service" &> services.txt