具体的了解“>/dev/null 2>&1”

Linux系统中不管是crontab里面。还是平时使用的命令。常常会碰到">/dev/null 2>&1"。比方说：在Crontab
Job里面，假设不想发送邮件，那么有两种方法:

• 一是将MAILTO="", 设置为空

[root@host etc]# cat crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

• 二是将关闭某个命令的输出结果，将其重定向到/dev/null中。

1 1 * * * /sbin/ping -c 5 www.sohu.com > /dev/null 2>&1

1 2 * * * /sbin/ping -c 5 www.sohu.com > /dev/null 

则第一个crontab,即使ping失败，都不会有邮件发出。

而第二个crontab,假设ping失败。会在/var/spool/mail文件夹或/var/spool/clientmqueue文件夹下生成大量的错误输出提示邮件。

那么怎样理解">/dev/null 2>&1"，能够拆开来理解:

 >        :重定向，比如 echo "Hello" > /root/1.txt

1>  stdout:表示标准输出,默认是1

2>  stderr:表示标准错误

 &        :表示等同于,2>&1，表示标准错误重定向。等同于标准输出

/dev/null :表示空设置文件，类似于Win系统中的垃圾箱

因此，“>/dev/null 2>&1”也能够写成“1>/dev/null 2>&1”

那么本文标题的语句运行过程为：

1>/dev/null ：首先表示标准输出重定向到空设备文件，就是不显示不论什么信息。

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

比方说: 

ping a.b.c                  # 错误信息 ping:unknown host a.b.c

ping a.b.c > /dev/null      # 错误信息同上，由于仅仅是将标准输出摒弃

ping a.b.c > /dev/null 2>&1 # 而假设这么写的话，屏幕不会显示错误信息。这事实上丢弃标准输出及错误输出

• command > file 2>file
• command > file 2>&1

同样点:上面两个命令都但是实现将运行command后的。标准及错误输出重定向到file文件里。

不同点: I/O效率上的差异

command 1>file 2>file 这种写法,stdout和stderr都直接送到file中,
file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了FD1和FD2两个同一时候去抢占file的管道。

 

command 1>file 2>&1 这条命令就将stdout直接送向file, stderr 继承了FD1管道后,再被送往file,此时,file仅仅被打开了一次,也仅仅使用了一个管道FD1,它包含了stdout和stderr的内容。从I/O效率上,前一条命令的效率要比后面一条的命令效率要低,所以在编写shell脚本的时候,最多的时候我们会command
1>file 2>&1 这种写法， 或 "command >file 2&1"

版权声明：本文博主原创文章，博客，未经同意不得转载。