/dev/null 2>&一 解释
/dev/null 2>&1 解释
/dev/null 2>&1 解释
crontab内容 ：50 18 5-30 * * /script/myscript.sh 1> /dev/null 2>&1
其中 1> /dev/null 2>&1是什么意思？？
dev/null 为系统垃圾箱
&为后台运行
但是 myscript 后面的1 和 /null后面的2 还有 &后面的1是什么意思？
1代表标准输出，2代表错误信息输出.
1>/dev/null 就是指将标准输出定向到空设备，
2>&1，的意思是将错误输出定向到和1一样的输出设备，也同样是空.
换句话说，就是不显示该程序执行过程中的任何信息
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的效率更高。
-------------------------------------
为什么要用 /dev/null 2>&1 这样的写法.这条命令的意思是将标准输出和错误输出全部重定向到/dev/null中,也就是将产生的所有信息丢弃.下面我就为大家来说一下, command > file 2>file 与command > file 2>&1 有什么不同的地方.
首先~command > file 2>file 的意思是将命令所产生的标准输出信息,和错误的输出信息送到file 中.command > file 2>file 这样的写法,stdout和stderr都直接送到file中, file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了FD1和FD2两个同时去抢占file 的管道.
而command >file 2>&1 这条命令就将stdout直接送向file, stderr 继承了FD1管道后,再被送往file,此时,file 只被打开了一次,也只使用了一个管道FD1,它包括了stdout和stderr的内容.
从IO效率上,前一条命令的效率要比后面一条的命令效率要低,所以在编写shell脚本的时候,较多的时候我们会用command > file 2>&1 这样的写法.
****************************************************
in UNIX
0 = stdin
1 = stdout
2 = stderr
>/dev/null 2>&1 means
redirect all the standard out and standard error messages/output/results from the programs/scripts to /dev/null ( which means they go to a bottomless pit)
*****************************************************
/dev/null 2>&1
You need to understand the theory first and then its upto you how and where you want to apply that theory. I'll try to explain above to you.
The greater-than (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out and error:
There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.
Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.
That means file descriptor 0 or fd0 denotes STDIN or standard input and file descriptor 1 or fd1 denotes STDOUT or standard output and file descriptor 2 or fd2 denotes STDERR or standard error.
You can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).
The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!
*********************************************
When in a shell, you can do various things with the output and input to commands. You can run them through a pipe:
grep root /var/log/messages | less
This takes the output of the 'grep' commands, and uses the 'less' paginator to finally display it on the screen.
To go into further detail, this sends the STDOUT of 'grep' to less.
If you wanted to send the output to a file, you'd use a redirect:
grep root /var/log/messages > /tmp/file
This takes the STDOUT, and sticks it into '/tmp/file'. I won't go into detail about the > and >> options etc. as they are all covered in the man page.
There are 3 file descriptors for every process. STDIN, STDOUT and STDERR. These map to 0, 1 and 2 respecitvly.
Strangely enough, the above command can also be written as:
grep root /var/log/messages 1> /tmp/file
The first command makes the assumption that you want to redirect STDOUT. This one clears up that assumption.
Now we'll look at STDERR:
grep root /var/log/mseeagse > /tmp/file
This will spit out an error to your tty, even though you've redirected the output.
grep root /var/log/mseeagse 2> /tmp/file
This one will output nothing, and '/tmp/file' will contain the error. If we didn't miss-spell the messages file name, any errors that might occur would go to the file, but the output will go to the TTY.
Now we'll do the last confusing thing, moving a file descriptor to a different one. This is where the &<number> comes in:
grep root /var/log/mseeagse 2> &1
This moves STDERR so it comes out in the same place as STDOUT. It says "Move file descriptor 2 to file descriptor 1".
Thus where we get to your tail. We mix and match the STDOUT and STDERR redirections:
grep root /var/log/messages > /tmp/file 2> &1
grep root /var/log/mseeagse > /tmp/file 2> &1
With both of these commands, both the regular output (STDOUT), and any errors that occur (STDERR) will go into '/tmp/file'.
When stacking redirects like this, there is one major thing to be aware of. When you move a file descriptor, you have to make sure the descriptor you are moving too has already been redirected to where you want, otherwise you can get some... interesting results.
************************************************************
This is from memory.
Everything in Linux is a file, including I/O. There are three standard file descriptors, Standard In (STDIN, file descriptor 0), Standard Output (STDOUT, file descriptor 1) and Standard Error (STDERR, file descriptor 2). /dev/null is the null device, which is like "write only memory". > will write to the specified file (overwriting its contents) and >> will append to the specified file.
2> redirects STDERR to the specified file. >> is used to append to the end of the file.
& only means to run the process in the background if it appears at the end of the line.
2>&1 redirects STDERR to STDOUT. Since in this case, STDOUT is being redirected to /dev/null, 2>&1 causes both STDERR and STDOUT to /dev/null.
/dev/null 2>&1 解释
crontab内容 ：50 18 5-30 * * /script/myscript.sh 1> /dev/null 2>&1
其中 1> /dev/null 2>&1是什么意思？？
dev/null 为系统垃圾箱
&为后台运行
但是 myscript 后面的1 和 /null后面的2 还有 &后面的1是什么意思？
1代表标准输出，2代表错误信息输出.
1>/dev/null 就是指将标准输出定向到空设备，
2>&1，的意思是将错误输出定向到和1一样的输出设备，也同样是空.
换句话说，就是不显示该程序执行过程中的任何信息
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的效率更高。
-------------------------------------
为什么要用 /dev/null 2>&1 这样的写法.这条命令的意思是将标准输出和错误输出全部重定向到/dev/null中,也就是将产生的所有信息丢弃.下面我就为大家来说一下, command > file 2>file 与command > file 2>&1 有什么不同的地方.
首先~command > file 2>file 的意思是将命令所产生的标准输出信息,和错误的输出信息送到file 中.command > file 2>file 这样的写法,stdout和stderr都直接送到file中, file会被打开两次,这样stdout和stderr会互相覆盖,这样写相当使用了FD1和FD2两个同时去抢占file 的管道.
而command >file 2>&1 这条命令就将stdout直接送向file, stderr 继承了FD1管道后,再被送往file,此时,file 只被打开了一次,也只使用了一个管道FD1,它包括了stdout和stderr的内容.
从IO效率上,前一条命令的效率要比后面一条的命令效率要低,所以在编写shell脚本的时候,较多的时候我们会用command > file 2>&1 这样的写法.
****************************************************
in UNIX
0 = stdin
1 = stdout
2 = stderr
>/dev/null 2>&1 means
redirect all the standard out and standard error messages/output/results from the programs/scripts to /dev/null ( which means they go to a bottomless pit)
*****************************************************
/dev/null 2>&1
You need to understand the theory first and then its upto you how and where you want to apply that theory. I'll try to explain above to you.
The greater-than (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out and error:
There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.
Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.
That means file descriptor 0 or fd0 denotes STDIN or standard input and file descriptor 1 or fd1 denotes STDOUT or standard output and file descriptor 2 or fd2 denotes STDERR or standard error.
You can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).
The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!
*********************************************
When in a shell, you can do various things with the output and input to commands. You can run them through a pipe:
grep root /var/log/messages | less
This takes the output of the 'grep' commands, and uses the 'less' paginator to finally display it on the screen.
To go into further detail, this sends the STDOUT of 'grep' to less.
If you wanted to send the output to a file, you'd use a redirect:
grep root /var/log/messages > /tmp/file
This takes the STDOUT, and sticks it into '/tmp/file'. I won't go into detail about the > and >> options etc. as they are all covered in the man page.
There are 3 file descriptors for every process. STDIN, STDOUT and STDERR. These map to 0, 1 and 2 respecitvly.
Strangely enough, the above command can also be written as:
grep root /var/log/messages 1> /tmp/file
The first command makes the assumption that you want to redirect STDOUT. This one clears up that assumption.
Now we'll look at STDERR:
grep root /var/log/mseeagse > /tmp/file
This will spit out an error to your tty, even though you've redirected the output.
grep root /var/log/mseeagse 2> /tmp/file
This one will output nothing, and '/tmp/file' will contain the error. If we didn't miss-spell the messages file name, any errors that might occur would go to the file, but the output will go to the TTY.
Now we'll do the last confusing thing, moving a file descriptor to a different one. This is where the &<number> comes in:
grep root /var/log/mseeagse 2> &1
This moves STDERR so it comes out in the same place as STDOUT. It says "Move file descriptor 2 to file descriptor 1".
Thus where we get to your tail. We mix and match the STDOUT and STDERR redirections:
grep root /var/log/messages > /tmp/file 2> &1
grep root /var/log/mseeagse > /tmp/file 2> &1
With both of these commands, both the regular output (STDOUT), and any errors that occur (STDERR) will go into '/tmp/file'.
When stacking redirects like this, there is one major thing to be aware of. When you move a file descriptor, you have to make sure the descriptor you are moving too has already been redirected to where you want, otherwise you can get some... interesting results.
************************************************************
This is from memory.
Everything in Linux is a file, including I/O. There are three standard file descriptors, Standard In (STDIN, file descriptor 0), Standard Output (STDOUT, file descriptor 1) and Standard Error (STDERR, file descriptor 2). /dev/null is the null device, which is like "write only memory". > will write to the specified file (overwriting its contents) and >> will append to the specified file.
2> redirects STDERR to the specified file. >> is used to append to the end of the file.
& only means to run the process in the background if it appears at the end of the line.
2>&1 redirects STDERR to STDOUT. Since in this case, STDOUT is being redirected to /dev/null, 2>&1 causes both STDERR and STDOUT to /dev/null.