shell "cmd 2>&1 >file" "cmd > file 2>&1" 的区别

 原帖： 是"2>&1 >file" 还是 ">file 2>&1" 

http://www.diybl.com/course/6_system/linux/Linuxjs/2008923/144844.html 

$ cat food 2>&1 >file    cat: can't open food

$ cat food >file 2>&1

一个Bourne或Korn shell经常提出的问题是，为什么只有第二个命令才能把标准输出(stdout)和标准错误(stderr)重定向到文件file中？在第一个命令中，shell里首先是2>&1，意味着标准错误重定向到与标准输出同样的地方。这无任何效果，因为两部分都重定向到屏幕上(省缺)。然后>file重定向标准输出到file，但标准错误仍然定向到终端。在第二个命令中，shell里首先是>file，意味着标准输出重定向到file。然后 2>&1将标准错误重定向到与标准输出同样的地方，既file。这也是我们想要的。其它常用重定向的命令command > filename　　　　　　把标准输出重定向到一个新文件中command >> filename 　　　　　把标准输出重定向到一个文件中(追加) command 1 > fielname　　　　　把标准输出重定向到一个文件中command 1 >> fielname　　　　 把标准输出重定向到一个文件中(追加)command 2 > filename　　　　　把标准错误重定向到一个文件中command 2 >> filename　　　 　把标准错误重定向到一个文件中(追加)command < filename　　　　　　把filename文件作为标准输入command << delimiter　　　　　从标准输入中读入，直至遇到delimiter分界符command <&m　　　　　　　　把把文件描述符m作为标准输入command >&m 　　　　　　　　把把标准输出重定向到文件描述符m中command <&-　　　　　　　　　把关闭标准输入背景知识：我们在shell中执行命令的时候，每个进程都和三个打开的文件相联系，并使用文件描述符来引用这些文件。由于文件描述符不容易记忆，shell同时也给出了相应的文件名。下面就是这些文件描述符及它们通常所对应的文件名： 输入文件—标准输入　　　　0　　　　缺省是键盘输出文件—标准输出　　　　1　　　　缺省是屏幕错误输出文件—标准错误　　2　　　　缺省是屏幕 写了个程序验证了一下： #include int main(void) { printf("printf1/n"); printf("printf2/n"); perror("perror1/n"); perror("perror2/n"); //exit(1); return 0; } 执行结果 [me@localhost print_error]$ ls a.out print_error.c [me@localhost print_error]$ ./a.out > outfile 2>&1 [me@localhost print_error]$ cat outfile perror1 : Success perror2 : Invalid argument //不知道为啥这里会出现这个错误，谁知道指点一下，假如不输出重定向的话，不会出现这个问题。 printf1 printf2 [me@localhost print_error]$ ./a.out 2>&1 > outfile perror1 : Success perror2 : Success [me@localhost print_error]$ cat outfile printf1 printf2 [me@localhost print_error]$

附加：看完这个基本就明白了，dup2差不多吧。

Order matters. The way to reason about redirections is to read them from left to right and realize that redirections make streams point at the same place. They don't make streams point at each other.

What does that mean? If you say 2>&1 then you are redirecting stderr to wherever stdout is currently redirected to. If stdout is going to the console then stderr is, too. If stdout is going to a file then stderr is as well. If you follow this up by then redirecting stdout, stderr still points to what stdout used to point to. It does not "follow" stdout to the new location.

Right

cmd > log 2>&1

This redirects stdout to log and then redirects stderr to wherever stdout is now being redirected, which is log.

End result: both stdout and stderr are redirected to log.

Wrong

cmd 2>&1 > log

This redirects stderr to wherever stdout is currently being redirected, which is typically the console. Then stdout is redirected to log. Remember that stderr does not "follow" stdout, so it continues to redirect to the console.

End result: stdout is redirected to the log file and stderr is (still) sent to the console. This is almost certainly not what you want.