前言
有时候我们常看到类似这样的脚本调用：
./test.sh > log.txt 2>&1
这里的2>&1是什么意思？该如何理解？
先说结论：上面的调用表明将 ./test.sh的输出重定向到 log.txt文件中，同时将标准错误也重定向到 log.txt文件中。
有何妙用
（如果已经明白是什么作用，可跳过此小节）
上面到底是什么意思呢？我们来看下面的例子，假如有脚本 test.sh：
#!/bin/bash
date #打印当前时间
while true #死循环
do
#每隔2秒打印一次
sleep 2
whatthis #不存在的命令
echo -e "std output"
done
脚本中先打印当前日期，然后每隔2秒执行 whatthis并打印一段字符。由于系统中不存在 whatthis命令，因此执行会报错。
假如我们想保存该脚本的打印结果，只需将 test.sh的结果重定向到 log.txt中即可：
./test.sh > log.txt
执行结果如下：
./test.sh >log.txt
./test.sh: 行 7: whatthis: 未找到命令
我们明明将打印内容重定向到 log.txt中了，但是这条错误信息却没有重定向到 log.txt中。如果你是使用程序调用该脚本，当查看脚本日志的时候，将会完全看不到这条错误信息。而使用下面的方式则会将出错信息也重定向到 log.txt中：
./test.sh > log.txt 2>&1
以这样的方式调用脚本，可以很好地将错误信息保存，帮助我们定位问题。
如何理解
每个程序在运行后，都会至少打开三个文件描述符，分别是
0：标准输入 => stdin；
1：标准输出 => stdout；
2：标准错误 => stderr。
例如，对于前面的test.sh脚本，我们通过下面的步骤看到它至少打开了三个文件描述符：
./test.sh #运行脚本
ps -ef|grep test.sh #重新打开命令串口，使用ps命令找到test.sh的pid
root 96126 88139 0 10:44 pts/2 00:00:00 sh test.sh
root 96177 56236 0 10:45 pts/1 00:00:00 grep --color=auto test.sh
可以看到 test.sh的pid为96126，进入到相关fd目录：
cd /proc/96126/fd #进程96126所有打开的文件描述符信息都在此
ls -l #列出目录下的内容
0 -> /dev/pts/2
1 -> /dev/pts/2
2 -> /dev/pts/2
255 -> /root/shell/test.sh
可以看到，test.sh打开了0，1，2三个文件描述符。同样的，如果有兴趣，也可以查看其他运行进程的文件描述符打开情况，除非关闭了否则都会有这三个文件描述符。
那么现在就容易理解前面的疑问了，2>&1表明将文件描述2（标准错误输出）的内容重定向到文件描述符1（标准输出）的文件（/dev/stdout）中，为什么1前面需要&？当没有&时，1会被认为是一个普通的文件，有&表示重定向的目标不是一个文件，而是一个文件描述符。在前面我们知道，sh test.sh >log.txt又将文件描述符1的内容重定向到了文件 log.txt，那么最终标准错误也会重定向到 log.txt。我们同样通过前面的方法 sh test.sh > log.txt 2>&1，可以看到 test.sh进程的文件描述符情况如下：
0 -> /dev/pts/2
1 -> /root/shell/log.txt
2 -> /root/shell/log.txt
255 -> /root/shell/test.sh
我们可以很明显地看到，文件描述符1和2都指向了 log.txt文件，也就得到了我们最终想要的效果：将标准错误输出重定向到文件中。
它们还有两种等价写法：
sh test.sh >& log.txt
sh test.sh &> log.txt
此处 >& 或者 &> 视作整体，分开没有单独的意义。
总结
我们总结一下前面的内容：
- 1.程序运行后会打开三个文件描述符，分别是标准输入，标准输出和标准错误输出。
- 2.在调用脚本时，可使用2>&1来将标准错误输出重定向。
- 3.只需要查看脚本的错误时，可将标准输出重定向到文件，而标准错误会打印在控制台，便于查看。
- 4.
>>log.txt会将重定向内容追加到log.txt文件末尾。 - 5.通过查看
/proc/进程id/fd下的内容，可了解进程打开的文件描述符信息。
思考
下面的调用会将标准错误输出重定向到文件中吗？为什么？
./test.sh 2>&1 >log.txt
答案是不会，只会将标准输入和标准输出到文件中，标准错误会输出到终端。
顺序问题
find /etc -name .bashrc > list 2>&1
# 我想问为什么不能调下顺序,比如这样
find /etc -name .bashrc 2>&1 > list
这个是从左到右有顺序的
第一种：
xxx > list 2>&1
先将要输出到stdout的内容重定向到文件，此时文件list就是这个程序的stdout，再将stderr重定向到stdout，也就是文件list
第二种：
xxx 2>&1 > list
先将要输出到stderr的内容重定向到stdout，此时会产生一个stdout的拷贝，作为程序的stderr，而程序原本要输出到stdout的内容，依然是对接在stdout原身上的，因此第二步重定向stdout，对stdout的拷贝不产生任何影响。
第三种：
# 对于上面 '2>&1'，举个例子，比如说:
find /etc -names "*.txt" >list 2>&1
从左往右执行，执行到 >list，此时的stdout为list；而执行到 2>&1，表示stderr重定向到stdout，这里也就是list文件。
但因为 find /etc -names "*.txt"这条命令是错误的(-names应该是-name)。
本来要输出到终端屏幕的错误信息:
find: unknown predicate `-names`
被重定向到了 stdout 也就是 list 文件中，所以屏幕不会出现错误信息，而是打印到了 list 文件中。
cat list可以查看到 find: unknown predicate '-names'就在里面。