shell中可能经常能看到：echo log > /dev/null 2>&1

命令的结果可以通过%>的形式来定义输出

/dev/null ：代表空设备文件

> ：代表重定向到哪里，例如：echo "123" > /home/123.txt

1 ：表示stdout标准输出，系统默认值是1，所以">/dev/null"等同于"1>/dev/null"

2 ：表示stderr标准错误

& ：表示等同于的意思，2>&1，表示2的输出重定向等同于1

1 > /dev/null 2>&1 语句含义：

1 > /dev/null ： 首先表示标准输出重定向到空设备文件，也就是不输出任何信息到终端，说白了就是不显示任何信息。

2>&1 ：接着，标准错误输出重定向（等同于）标准输出，因为之前标准输出已经重定向到了空设备文件，所以标准错误输出也重定向到空设备文件。

&>/dev/null : 这个意思是所以的输出都重定向到/dev/null 这个设备

实例解析：

cmd >a 2>a 和 cmd >a 2>&1 为什么不同？

cmd >a 2>a ：stdout和stderr都直接送往文件 a ，a文件会被打开两遍，由此导致stdout和stderr互相覆盖。

cmd >a 2>&1 ：stdout直接送往文件a ，stderr是继承了FD1的管道之后，再被送往文件a 。a文件只被打开一遍，就是FD1将其打开。

两者的不同点在于：

cmd >a 2>a 相当于使用了FD1、FD2两个互相竞争使用文件 a 的管道；

cmd >a 2>&1 只使用了一个管道FD1，但已经包括了stdout和stderr。

从IO效率上来讲，cmd >a 2>&1的效率更高。

经常可以在一些脚本，尤其是在crontab调用时发现如下形式的命令调用

/tmp/test.sh > /tmp/test.log 2>&1

前半部分/tmp/test.sh > /tmp/test.log很容易理解，那么后面的2>&1是怎么回事呢？

要解释这个问题，还是得提到文件重定向。我们知道>和<是文件重定向符。那么1和2是什么？

在shell中，每个进程都和三个系统文件 相关联：标准输入stdin，标准输出stdout、标准错误stderr，三个系统文件的文件描述符分别为0，1、2。所以这里2>&1 的意思就是将标准错误也输出到标准输出当中。

下面通过一个例子来展示2>&1有什么作用：

$ cat test.sh

t

date

test.sh中包含两个命令，其中t是一个不存在的命令，执行会报错，默认情况下，错误会输出到stderr。date则能正确执行，并且输出时间信息，默认输出到stdout

./test.sh > test1.log

./test.sh: line 1: t: command not found

$ cat test1.log

Wed Jul 10 21:12:02 CST 2013

可以看到，date的执行结果被重定向到log文件中了，而t无法执行的错误则只打印在屏幕上。

$ ./test.sh > test2.log 2>&1

$ cat test2.log

./test.sh: line 1: t: command not found

Tue Oct 9 20:53:44 CST 2007

这次，stderr和stdout的内容都被重定向到log文件中了。

实际上， > 就相当于 1> 也就是重定向标准输出，不包括标准错误。通过2>&1，就将标准错误重定向到标准输出了，那么再使用>重定向就会将标准输出和标准错误信息一同重定向了。如果只想重定向标准错误到文件中，则可以使用2> file。

linux shell 中"2>&1"含义脚本是：

nohup /mnt/Nand3/H2000G >/dev/null 2>&1 &

对于&1 更准确的说应该是文件描述符 1，而1 一般代表的就是STDOUT_FILENO,实际上这个操作就是一个dup2(2)调用.他标准输出到all_result ，然后复制标准输出到文件描述符2(STDERR_FILENO)，其后果就是文件描述符1和2指向同一个文件表项,也可以说错误的输出被合并了，其中0 表示键盘输入 1表示屏幕输出 2表示错误输出，把标准出错重定向到标准输出,然后扔到/DEV/NULL下面去。通俗的说，就是把所有标准输出和标准出错都扔到垃圾桶里面。

command >out.file 2>&1 &

command >out.file是将command的输出重定向到out.file文件，即输出内容不打印到屏幕上，而是输出到out.file文件中。 2>&1 是将标准出错重定向到标准输出，这里的标准输出已经重定向到了out.file文件，即将标准出错也输出到out.file文件中。最后一个& ， 是让该命令在后台执行。

试想2>1代表什么，2与>结合代表错误重定向，而1则代表错误重定向到一个文件1，而不代表标准输出；

换成2>&1，&与1结合就代表标准输出了，就变成错误重定向到标准输出.

你可以用

ls 2>1测试一下，不会报没有2文件的错误，但会输出一个空的文件1；

ls xxx 2>1测试，没有xxx这个文件的错误输出到了1中；

ls xxx 2>&1测试，不会生成1这个文件了，不过错误跑到标准输出了；

ls xxx >out.txt 2>&1, 实际上可换成 ls xxx 1>out.txt 2>&1；重定向符号>默认是1,错误和输出都传到out.txt了。

为何2>&1要写在后面？

command > file 2>&1

首先是command > file将标准输出重定向到file中， 2>&1 是标准错误拷贝了标准输出的行为，也就是同样被重定向到file中，最终结果就是标准输出和错误都被重定向到file中。

command 2>&1 >file

2>&1 标准错误拷贝了标准输出的行为，但此时标准输出还是在终端。>file 后输出才被重定向到file，但标准错误仍然保持在终端。

用strace可以看到：

1. command > file 2>&1

这个命令中实现重定向的关键系统调用序列是：

open(file) == 3

dup2(3,1)

dup2(1,2)

2. command 2>&1 >file

这个命令中实现重定向的关键系统调用序列是：

dup2(1,2)

open(file) == 3

dup2(3,1)

文件描述符和打开文件之间的关系

每一个文件描述符会与一个打开文件相对应，同时，不同的文件描述符也会指向同一个文件。相同的文件可以被不同的进程打开也可以在同一个进程中被多次打开。系统为每一个进程维护了一个文件描述符表，该表的值都是从0开始的，所以在不同的进程中你会看到相同的文件描述符，这种情况下相同文件描述符有可能指向同一个文件，也有可能指向不同的文件。具体情况要具体分析，要理解具体其概况如何，需要查看由内核维护的3个数据结构。

1. 进程级的文件描述符表

2. 系统级的打开文件描述符表

3. 文件系统的i-node表

进程级的描述符表的每一条目记录了单个文件描述符的相关信息。

1. 控制文件描述符操作的一组标志。（目前，此类标志仅定义了一个，即close-on-exec标志）

2. 对打开文件句柄的引用

内核对所有打开的文件的文件维护有一个系统级的描述符表格（open file description table）。有时，也称之为打开文件表（open file table），并将表格中各条目称为打开文件句柄（open file handle）。一个打开文件句柄存储了与一个打开文件相关的全部信息，如下所示：

1. 当前文件偏移量（调用read()和write()时更新，或使用lseek()直接修改）

2. 打开文件时所使用的状态标识（即，open()的flags参数）

3. 文件访问模式（如调用open()时所设置的只读模式、只写模式或读写模式）

4. 与信号驱动相关的设置

5. 对该文件i-node对象的引用

6. 文件类型（例如：常规文件、套接字或FIFO）和访问权限

7. 一个指针，指向该文件所持有的锁列表

8. 文件的各种属性，包括文件大小以及与不同类型操作相关的时间戳

下图展示了文件描述符、打开的文件句柄以及i-node之间的关系，图中，两个进程拥有诸多打开的文件描述符。

在进程A中，文件描述符1和30都指向了同一个打开的文件句柄（标号23）。这可能是通过调用dup()、dup2()、fcntl()或者对同一个文件多次调用了open()函数而形成的。

进程A的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄（标号73）。这种情形可能是在调用fork()后出现的（即，进程A、B是父子进程关系），或者当某进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程时，也会发生。再者是不同的进程独自去调用open函数打开了同一个文件，此时进程内部的描述符正好分配到与其他进程打开该文件的描述符一样。

此外，进程A的描述符0和进程B的描述符3分别指向不同的打开文件句柄，但这些句柄均指向i-node表的相同条目（1976），换言之，指向同一个文件。发生这种情况是因为每个进程各自对同一个文件发起了open()调用。同一个进程两次打开同一个文件，也会发生类似情况。

重定向的本质与实现

为什么 >/dev/null 2>&1 和 2>&1 /dev/null 的效果不同呢？为了解决这个问题，我们先要从内核里文件描述符和文件的关系说起。理解重定向的背后到底发生了什么。

我们先来看看文件描述符与文件的关系。内核通过三张表来对把一个文件描述符对应到具体的文件，

首先，通过最左边的文件描述符表（File Descriptor Table）将一个文件描述符数字对应到一个文件表（File Table）中的文件项。再通过文件表将一个文件项对应到磁盘上具体的 inode 。

所谓“重定向”本质上就是通过修改文件描述符表中的文件指针（file table descriptor）将对一个描述符的操作落到其他文件上去。

比如， 3>&1 就会导致上图的结果。也就是将描述符 3 的文件指针指向和描述符 0 相同的地方。这个操作在 Linux 系统是通过一个叫 dup2(2) 的系统调用完成的。举例来说： 2>&1 在程序实现上就是

#include <stdio.h>

#include <stdlib.h>

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

{

dup2(1, 2);

fprintf(stderr, "hello, worldn");

return 0;

}

理解了 dup2(2) 做的工作后，我们再来看看 2>&1 >/dev/null 和 >/dev/null 2>&1 的实现，

int fd = open("/dev/null", "w+");

dup2(fd, 1);

dup2(1, 2);

以上就是 >/dev/null 2>&1 的实现。我们先把描述符 1 指向和 /dev/null 的位置，然后再把描述符 2 指向描述符 1 对应文件的位置。由于之前描述符 1 的对应文件已经被 dup2(2) 修改为了 /dev/null 因此描述符 2 现在也指向 /dev/null 了。后续的所有标准输出与标准错误的数据都被定向到了 /dev/null 。

再来看 2>&1 >/dev/null 的实现，

int fd = open("/dev/null", "w+");

dup2(1, 2);

dup2(fd, 1);

这里仅仅就是把两条 dup2(2) 语句的顺序调换了一下。但是却产生了完全不同的结果。首先，我们把描述符 2 指向描述符 1 对应的文件，也就是标准输出，然后再把描述符 1 指向 /dev/null 。结果是描述符 1 指向了 /dev/null 而描述符 2 仍然指向标准输出。如果还不是理解得很清楚，可以画一下类似上面的描述符指向图，来模拟一下每一步文件描述符和文件的关系。

理解了重定向的原理后，就很容易理解在 shell 中重定向的顺序是至关重要的。

发布时间: 9年前【Linux】128人已围观【返回】【回到顶端】

转载：个人转载请注明文章出处 "www.itarticle.cc-IT技术类文章收集&分享"。

很赞哦！ (1)