EEPW论坛

探讨shell命令中>/dev/null 2>&1的实现原理 首先标准输入,标准输出,标准错误:标准输入是程序可以读取其输入的位置。缺省情况下，进程从键盘读取 stdin 。标准输出是程序写入其输出的位置。缺省情况下，进程将 stdout 写到终端屏幕上。标准错误是程序写入其错误消息的位置。缺省情况下，进程将 stderr 写到终端屏幕上。
 为什么有这三个很重要的概念呢?我们知道，一个程序要运行，需要有输入、输出，如果出错，还要能表现出自身的错误。这是就要从某个地方读入数据、将数据输出到某个地方，出错了还要把错误给弄到一个地方去.这就够成了数据流(stream)。所以通常情况，每个 Unix 程序在启动时都会打开三个流，一个用于输入，一个用于输出，一个用于打印诊断或错误消息。  www.2cto.com  有了这三个概念. 再说说重定向: 数据流重导向(重定向)就是将某个指令(命令)执行后的执行返回值,一般这些返回值就是你执行完后出现在屏幕上那些结果数据,如果我不想让他默认流向屏幕.那么我可以把这些结果数据传输到其他的地方，例如文件或者装置(例如打印机,不过在Linux里面一切都一切都是文件,所以打印机这样的设备也是文件咯).这样数据就跑被我导向其他地方了.你懂的.所以东西都输出到屏幕,如果数据太多太乱.我们也受不了啊.而且屏幕的terminal一关.东西就再也找不到了.如果我重定向到一个文件.这样就可以长期保存执行的日志了. >数据流重导向：输出导向，会替换被导向的文件内容.>>数据流重导向：输出导向，不会替换被导向的文件内容.会在屁股后面累加数据.继续看看文件描述符:  www.2cto.com  维基百科，自由的百科全书上面是这样说的,文件描述符(File descriptor)是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

文件描述符的优点主要有两个:基于文件描述符的I/O操作兼容POSIX标准。在UNIX、Linux的系统调用中，大量的系统调用都是依赖于文件描述符。看来这东西还真的有点抽象.也就是说如果程序不打开,文件孤单的在磁盘上面的时候是没有文件描述符的.可以想象一下.第一个打开的文件是0，第二个是1，依此类推。Unix 操作系统通常给每个进程能打开的文件数量强加一个限制。更甚的是，unix 通常有一个系统级的限制。当然真是的情况是0,1,2一般已经被某些概念占用.再加上系统启动后已经不知道打开了多少文件.

所以.我们自己一般打开文件的时候描述符估计也已经到很大的数据了.但是这文件描述符缺点也是有的.比如完成的代码可读性也就会变得很差.你想啊.0,1,2....22231是知道是啥玩意儿?还好POSIX 定义了 STDIN_FILENO、STDOUT_FILENO 和 STDERR_FILENO 来代替 0、1、2。这三个符号常量的定义位于头文件 unistd.h。文件描述符的有效范围是 0 到 OPEN_MAX。一般来说，每个进程最多可以打开 64 个文件（0 — 63）。对于 FreeBSD 5.2.1、Mac OS X 10.3 和 Solaris 9 来说，每个进程最多可以打开文件的多少取决于系统内存的大小，int 的大小，以及系统管理员设定的限制。Linux 2.4.22 强制规定最多不能超过 1,048,576 。  www.2cto.com  综合上面的基本概念:下面的也就不难理解了. 标准输入 (stdin) ：文件描述符为 0 ，使用 < 或 << ；(你不会非要写成0<或0<<吧.其实这个也没错.不过太累人了)其实可以理解为这个箭头指向哪里数据就往哪里跑.这里是输入(stdin).命令就通过<来获取数据.等于数据是从左边往命令里面流. 标准输出 (stdout)：文件描述符为 1 ，使用 > 或 >> ；(你不会非要写成1>或1>>吧.其实这个也没错.不过太累人了)输出的时候当如不能用<或者<<,因为命令总是在前面嘛.这里命令要输出数据.所以数据的来源是命令,数据就会随着箭头指向你给的方向. 标准错误输出(stderr)：文件描述符为 2 ，使用 2> 或 2>>; 再举例说明: 首先command >file 2>file 的意思是将命令所产生的标准输出信息,和错误的输出信息送到file中.command >file 2>file 这样的写法,stdout和stderr都直接送到file中, file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了两个同时去抢占file的管道.定向了2次. 那如果使用command >file 2>&1 这条命令就将stdout直接送向file, stderr 继承了第一次重定向(FD1)到管道后,再被送往file,此时,file 只被打开了一次,也只使用了一个管道FD1,它包括了stdout和stderr的内容.还可以这样理解.想是把file用管道接通了标准输出.然后把2代表的标准错误输出接到1代表的标准信息输出上面.就都通向了file了.  从IO效率上,前一条命令的效率要比后面一条的命令效率要低,所以在编写shell脚本的时候,较多的时候我们会用command > file 2>&1 这样的写法. 在看看一个实例(加深相关的理解,此实例引用网上博客.说是intel的笔试题): 问题：下面程序的输出是什么？（intel笔试2011）  www.2cto.com  1int main(){2  fprintf(stdout,"Hello ");3  fprintf(stderr,"World!");4  return0;5}然后发现输出是World!Hello而不是:Hello World! 这是为什么呢？在默认情况下，stdout是行缓冲的，他的输出会放在一个buffer里面，只有到换行的时候，才会输出到屏幕。而stderr是无缓冲的，会直接输出，举例来说就是printf(stdout, "xxxx") 和 printf(stdout, "xxxx\n")，前者会憋住，直到遇到新行才会一起输出。而printf(stderr, "xxxxx")，不管有么有\n，都输出. 最后:  www.2cto.com  看看什么叫/dev/null 1UFO@UFO~:cd /dev2UFO<a href="www.2cto.com" class="referer" target="_blank">@UFO</a> :/dev$ls -l null3crw-rw-rw-  1 root root 1, 3 Feb 14  2012 null看到了吧?是个字符设备文件(c).而这个东西呢?你可以叫他"黑洞", Blackhole?NO.不是天文学里面的黑洞.它非常等价于一个只写文件. 所有写入它的内容都会永远丢失. 而尝试从它那儿读取内容则什么也读不到. 然而, /dev/null 对命令行和脚本都非常的有用.再来看看在glibc库的stdio.h头文件中: 1#define    stdin    (&__sF[0])2#define    stdout    (&__sF[1])3#define    stderr    (&__sF[2])比如  www.2cto.com  1fprintf(stderr, "UFO\n");//那么将把"UFO"作为标准错误输出在shell命令中,0,1和2分别对应glibc中的stdin,stdout和stderr,上面我们已经大概了解到了: 0 对应stdin     即标准输入1 对应stdout    即标准输出2 对应stderr    即标准错误输出所以>/dev/null表示将程序通过printf或者fprintf打印到handle为1的stdout文件的信息,送到/dev/null空洞文件,/dev/null节点对应的kernel实现就是直接返回写入的字节数,所以程序认为成功存储到/dev/null了,但是>/dev/null这个操作不能将fprintf(stderr, "UFO\n")打印到stderr上的字符串送到>/dev/null下,所以必须使用2>&1命令,表示shell将送到2 stderr中的数据转送到1 stdout中,所以这样stderr中会显示到terminal上的信息也将被转送到/dev/null下了. 又看个实例吧： 01luther@gliethttp:~$ cat a.c02#include <stdio.h>03int main(int argc, char *argv[])04{05    fprintf(stdout,"luther stdout\n");06    fprintf(stderr,"luther stderr\n");07    return 0;08}09luther@gliethttp:~$ gcc a.c10luther@gliethttp:~$ ./a.out11luther stdout12  www.2cto.com  luther stderr13luther@gliethttp:~$ ./a.out >/dev/null14luther stderr//可以看到>/dev/null操作并不会将stderr信息送到/dev/null下写一个test.sh脚本 01luther@gliethttp:~$ chmod +x test.sh02luther@gliethttp:~$ cat test.sh03exec ./a.out >/dev/null04luther@gliethttp:~$ ./test.sh05luther stderr       //可以看到shell也不会将stderr信息送到/dev/null下06luther@gliethttp:~$ cat test.sh07exec ./a.out >/dev/null 2>&108luther@gliethttp:~$ ./test.sh09luther@gliethttp:~$ //什么也没有输出,stderr信息被2>&1命令成功变为stdout信息,进而送入了/dev/null淹没10luther@gliethttp:~$ cat test.sh11exec ./a.out >/dev/null 1>&212./test.sh13luther stdout14luther stderr15luther@gliethttp:~$当然对于tee操作也同样存在如上问题,如果打印到stderr的log将不能被tee操作捕获,所以可以将stderr重定向到stdout来解决这个问题,  www.2cto.com  继续看看实例：01luther@gliethttp:~$ ./a.out02luther stdout03luther stderr04luther@gliethttp:~$ ./a.out|tee luther.txt05luther stdout06luther stderr07luther@gliethttp:~$ cat luther.txt08luther stdout09luther@gliethttp:~$ ./a.out 2>&1|tee luther.txt10luther stderr11luther stdout12luther@gliethttp:~$ cat luther.txt13luther stderr14luther stdout15luther@gliethttp:~$ ./a.out 1>&2|tee luther.txt16luther stderr17luther stdout18luther@gliethttp:~$ cat luther.txt19luther@gliethttp:~$ //啥东西都没有,因为stdout被定向到stderr,所以所有log信息都不能被tee捕获20 对于1>&2因为作为一个命令将被shell解析,所以放在哪里都可以,1>&2将影响到该组命令中所有的log输出,比如：21luther@gliethttp:~$ 1>&2 ./a.out|tee luther.txt22  www.2cto.com  luther stderr23luther stdout24luther@gliethttp:~$ ./a.out 1>2 //只输出stderr25luther stderr26luther@gliethttp:~$ ./a.out 2>1 //只输出stdout27luther stdout