如何理解 Linux shell中“2>＆1”？

前言

有时候我们常看到类似这样的脚本调用：

这里的2>&1是什么意思？该如何理解？

先说结论：上面的调用表明将./test.sh的输出重定向到log.txt文件中，同时将标准错误也重定向到log.txt文件中。

有何妙用

（如果已经明白是什么作用，可跳过此小节）

上面到底是什么意思呢？我们来看下面的例子，假如有脚本test.sh：

脚本中先打印当前日期，然后每隔2秒执行whatthis并打印一段字符。由于系统中不存在whatthis命令，因此执行会报错。

假如我们想保存该脚本的打印结果，只需将test.sh的结果重定向到log.txt中即可：

执行结果如下：

我们明明将打印内容重定向到log.txt中了，但是这条错误信息却没有重定向到log.txt中。如果你是使用程序调用该脚本，当查看脚本日志的时候，将会完全看不到这条错误信息。而使用下面的方式则会将出错信息也重定向到log.txt中：

以这样的方式调用脚本，可以很好的将错误信息保存，帮助我们定位问题。

如何理解

每个程序在运行后，都会至少打开三个文件描述符，分别是0：标准输入；1：标准输出；2：标准错误。

例如，对于前面的test.sh脚本，我们通过下面的步骤看到它至少打开了三个文件描述符：

可以看到test.sh的pid为5270，进入到相关fd目录：

可以看到，test.sh打开了0，1，2三个文件描述符。同样的，如果有兴趣，也可以查看其他运行进程的文件描述符打开情况，除非关闭了否则都会有这三个文件描述符。

那么现在就容易理解前面的疑问了，2>&1表明将文件描述2（标准错误输出）的内容重定向到文件描述符1（标准输出），为什么1前面需要&？当没有&时，1会被认为是一个普通的文件，有&表示重定向的目标不是一个文件，而是一个文件描述符。在前面我们知道，test.sh >log.txt又将文件描述符1的内容重定向到了文件log.txt，那么最终标准错误也会重定向到log.txt。我们同样通过前面的方法，可以看到test.sh进程的文件描述符情况如下：

我们可以很明显地看到，文件描述符1和2都指向了log.txt文件，也就得到了我们最终想要的效果：将标准错误输出重定向到文件中。

它们还有两种等价写法：

总结

我们总结一下前面的内容：

程序运行后会打开三个文件描述符，分别是标准输入，标准输出和标准错误输出。

在调用脚本时，可使用2>&1来将标准错误输出重定向。

只需要查看脚本的错误时，可将标准输出重定向到文件，而标准错误会打印在控制台，便于查看。

>>log.txt会将重定向内容追加到log.txt文件末尾。

通过查看/proc/进程id/fd下的内容，可了解进程打开的文件描述符信息。

思考

下面的调用会将标准错误输出重定向到文件中吗？为什么？

关注公众号【编程珠玑】，第一时间获取更多原创技术文章