个别自动备份脚本不执行的解决方法
个别自动备份脚本不执行的解决方法
在添加crontab命令定时启动脚本的后面，加上" > /dev/null 2>&1"。
如:
00 03 * * * /home/AutoBackupToFtp.sh > /dev/null 2>&1
下面是一个关于"/dev/null 2>&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的效率更高。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
经常可以在一些脚本，尤其是在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
Tue Oct 9 20:51:50 CST 2007
可以看到，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)
可以考虑一下不同的dup2()调用序列会产生怎样的文件共享结构。请参考APUE 3.10, 3.12
------------------------
/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 &
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.
本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。