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

文章由LinuxBoy分享于2019-03-24 01:03:34热评（353）

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

int main(){

fprintf(stdout,"Hello ");

fprintf(stderr,"World!");

return0;

}

然后发现输出是

World!Hello

而不是:

Hello World!

这是为什么呢？在默认情况下，stdout是行缓冲的，他的输出会放在一个buffer里面，只有到换行的时候，才会输出到屏幕。而stderr是无缓冲的，会直接输出，举例来说就是printf(stdout, "xxxx") 和 printf(stdout, "xxxx\n")，前者会憋住，直到遇到新行才会一起输出。而printf(stderr, "xxxxx")，不管有么有\n，都输出.

最后:

www.2cto.com

看看什么叫/dev/null

UFO@UFO~:cd /dev

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

crw-rw-rw- 1 root root 1, 3 Feb 14 2012 null

看到了吧?是个字符设备文件(c).而这个东西呢?你可以叫他"黑洞", Blackhole?NO.不是天文学里面的黑洞.它非常等价于一个只写文件. 所有写入它的内容都会永远丢失. 而尝试从它那儿读取内容则什么也读不到. 然而, /dev/null 对命令行和脚本都非常的有用.

再来看看在glibc库的stdio.h头文件中:

#define stdin (&__sF[0])

#define stdout (&__sF[1])

#define stderr (&__sF[2])

比如

www.2cto.com

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

又看个实例吧：

luther@gliethttp:~$ cat a.c

#include <stdio.h>

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

{

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

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

return 0;

}

luther@gliethttp:~$ gcc a.c

luther@gliethttp:~$ ./a.out

luther stdout

12 www.2cto.com

luther stderr

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

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

写一个test.sh脚本

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

luther@gliethttp:~$ cat test.sh

exec ./a.out >/dev/null

luther@gliethttp:~$ ./test.sh

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

luther@gliethttp:~$ cat test.sh

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

luther@gliethttp:~$ ./test.sh

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

luther@gliethttp:~$ cat test.sh

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

./test.sh

luther stdout

luther stderr

luther@gliethttp:~$

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

www.2cto.com

继续看看实例：

luther@gliethttp:~$ ./a.out

luther stdout

luther stderr

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

luther stdout

luther stderr

luther@gliethttp:~$ cat luther.txt

luther stdout

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

luther stderr

luther stdout

luther@gliethttp:~$ cat luther.txt

luther stderr

luther stdout

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

luther stderr

luther stdout

luther@gliethttp:~$ cat luther.txt

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

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

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

22 www.2cto.com

luther stderr

luther stdout

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

luther stderr

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

luther stdout

OK.不想写了.忙的很.上面的文章我只是添油加醋的把网络上很多因为大抄而散落各地的文章乱七八糟的整合了一下.所以我是站在巨人的肩上来了一次大抄.感谢那些巨人吧.其实上面提到的概念估计就这篇整合文章也不能完全解释的非常彻底.相关的概念更多的还在于实践和看文档再加自己的大脑过滤与思考.希望和大家探讨!

推荐文章：

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