shell命令中>/dev/null 2>&1的实现原理

探讨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

1

int 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

1

UFO@UFO~:cd /dev

2

UFO<a href="www.2cto.com" class="referer" target="_blank">@UFO</a> :/dev$ls -l null

3

crw-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

1

fprintf(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下了.

又看个实例吧：

01

luther@gliethttp:~$ cat a.c

02

#include <stdio.h>

03

int main(int argc, char *argv[])

04

{

05

fprintf(stdout,"luther stdout\n");

06

fprintf(stderr,"luther stderr\n");

07

return 0;

08

}

09

luther@gliethttp:~$ gcc a.c

10

luther@gliethttp:~$ ./a.out

11

luther stdout

12 www.2cto.com

luther stderr

13

luther@gliethttp:~$ ./a.out >/dev/null

14

luther stderr//可以看到>/dev/null操作并不会将stderr信息送到/dev/null下

写一个test.sh脚本

01

luther@gliethttp:~$ chmod +x test.sh

02

luther@gliethttp:~$ cat test.sh

03

exec ./a.out >/dev/null

04

luther@gliethttp:~$ ./test.sh

05

luther stderr //可以看到shell也不会将stderr信息送到/dev/null下

06

luther@gliethttp:~$ cat test.sh

07

exec ./a.out >/dev/null 2>&1

08

luther@gliethttp:~$ ./test.sh

09

luther@gliethttp:~$ //什么也没有输出,stderr信息被2>&1命令成功变为stdout信息,进而送入了/dev/null淹没

10

luther@gliethttp:~$ cat test.sh

11

exec ./a.out >/dev/null 1>&2

12

./test.sh

13

luther stdout

14

luther stderr

15

luther@gliethttp:~$

当然对于tee操作也同样存在如上问题,如果打印到stderr的log将不能被tee操作捕获,所以可以将stderr重定向到stdout来解决这个问题,

www.2cto.com

继续看看实例：

01

luther@gliethttp:~$ ./a.out

02

luther stdout

03

luther stderr

04

luther@gliethttp:~$ ./a.out|tee luther.txt

05

luther stdout

06

luther stderr

07

luther@gliethttp:~$ cat luther.txt

08

luther stdout

09

luther@gliethttp:~$ ./a.out 2>&1|tee luther.txt

10

luther stderr

11

luther stdout

12

luther@gliethttp:~$ cat luther.txt

13

luther stderr

14

luther stdout

15

luther@gliethttp:~$ ./a.out 1>&2|tee luther.txt

16

luther stderr

17

luther stdout

18

luther@gliethttp:~$ cat luther.txt

19

luther@gliethttp:~$ //啥东西都没有,因为stdout被定向到stderr,所以所有log信息都不能被tee捕获

20

对于1>&2因为作为一个命令将被shell解析,所以放在哪里都可以,1>&2将影响到该组命令中所有的log输出,比如：

21

luther@gliethttp:~$ 1>&2 ./a.out|tee luther.txt

22 www.2cto.com

luther stderr

23

luther stdout

24

luther@gliethttp:~$ ./a.out 1>2 //只输出stderr

25

luther stderr

26

luther@gliethttp:~$ ./a.out 2>1 //只输出stdout

27

luther stdout