如果一个命令需要长时间在服务器上运行，那么很多时候会用到nohup命令，这时即便远程登录ssh中断了与服务器的联系，那么在服务器上运行的命令也不会因此而*停止。

通常情况下，nohup与&连用，&的意思是将该命令放在后台执行。如下：

nohup example.sh &

将exmaple.sh通过&放在服务器后台运行，nohup确保了即便当前ssh远程连接中断，example.sh仍然能够不受影响，继续在远程服务器中运行。

最近有两个配对测序文件，需要比对到参考基因组上，通过bwa可以完成，同时由于该文件比较大，运行时间长，为了避免网络连接不稳定造成ssh中断，使用nohup

nohup bwa mem ref.fa read1.fq.gz read2.fq.gz > read12.sam &

将两个测序文件合并并生成sam文件。
写好命令，一个回车键按下去，“啪”一声，那就一个爽。然后不用管它，十余个小时之后，果然生成了一个很大的文件read12.sam文件。
但是，当用该sam文件生成bam文件时，提示错误sam文件存在错误！！！【十余个小时的计算白费了】
仔细检查了一下sam文件，发现程序运行的结果和程序运行过程中的说明输出到了同一个文件中！

1、标准输出和标准错误

标准输出（standard output）即结果默认的输出地方，比如在bash中，

$ echo 'hello'
hello

在默认状态下，’hello’时输出到你的终端（terminal）上显示。
再如，通过cat命令显示一个文本文件，

$ cat hello.txt
Hello!
This is a test!

但是，如果这个文本文件在当前路径下不存在，在会输出错误：

$ cat No_exist.txt
cat: No_exist.txt: No such file or directory
这时的输出内容“cat: No_exist.txt: No such file or directory”就是标准错误（standard error）。

2、重导向输出

默认情况下，标准输出和标准错误都会在终端显示。如果要将标准输出不是输出在终端，而是输出到一个其他文件中，这个时候就是重导向输出，可以通过“>“符号来完成。

echo 'hello' > hello.txt

将“hello”输出到hello.txt文件中，系统会新创建该文件，如果路径中存在该文件，旧的文件将会被覆盖。
还可以使用”>>”符号，这样不会覆盖旧文件，会将”hello”添加到旧文件中。
那么，这儿有一个问题，是不是所有输出到终端的内容都可以重导向输出到一个文件中？比如，如果是标准错误，能否通过”>”输入到文件中？

$ cat No_exist.txt > output.txt
cat: No_exist.txt: No such file or directory

结果证明：不能！output.txt依旧是一个空文件，而错误内容并没有出现在该文件中，依旧在终端显示！所以不能直接通过”>”将标准错误输出到文件中！
那么应该怎样才能将标准错误输出到文件中呢？

3、文件描述符

在bash中，通常使用3个整数来表示标准输入（0）、标准输出（1）和标准错误（2）。
如果要把标准错误输出到文件中，可以使用

cat No_exist.txt 2> tt.txt

这时在tt.txt文件中就会出现标准错误“cat: No_exist.txt: No such file or directory”。
同样的道理，我们可以将标准错误重导向输出为标准输出，2>&1
比如

$ cat No_exist.txt 
cat: No_exist.txt: No such file or directory
$ cat No_exist.txt 2>&1
cat: No_exist.txt: No such file or directory

虽然它们在终端上输出的内容看起来没有什么区别，但是它们的身份是不一样的，第一个是以标准错误的形式输出的，而第二个是标准输出。我们可以通过管道符号验证一下它们的不同。

$ cat No_exist.txt | sed 's/or/and/'
cat: No_exist.txt: No such file or directory
$ cat No_exist.txt 2>&1| sed 's/or/and/'
cat: No_exist.txt: No such file and directory

现在可以看出区别了，第一个标准错误无法通过管道符号把“or”替换成“and”，而第二个是标准输出，可以通过管道符号，把其中的“or”替换成“and”.
同样的道理，也可以将标准输出重导向为标准错误“1 >2&“

那么回过头来，看最开始的那个问题，为什么nohup同时会运算结果和运算过程的描述输出到同一个sam文件中呢？
为了简便，用下面的代码（example.sh)重现了nohup中的错误。

#!/bin/bash

echo "this is outcome!"
sleep 1
echo "sleep for 1s" >&2
echo "this is outcome, too!"
sleep 2
echo "second sleep for 2s" >&2

其中sleep的过程描述通过 >&2以标准错误的形式出现，而outcome则以标准输出的形式输出。
正常情况下，运行：

$ ./example.sh > outcome.txt
sleep for 1s
second sleep for 2s

$ cat outcome.txt 
this is outcome!
this is outcome, too!

标准错误直接输出到了终端中，运行结果输出到了outcome.txt中，没有任何问题。但是在nohup的情况下，这种情况就变了。
在nohup的说明中，提到“如果标准输出是在终端，那么输出的内容将会被添加到‘nohup.out’文件中；如果标准错误的输出是在终端，那么内容将会被重导向到标准输出“。这就意味着，在没有特殊说明的情况下，标准输出和标准错误将会被重导向输出到同一个地方。如下，

$ nohup ./example.sh 
appending output to nohup.out

$ cat nohup.out 
this is outcome!
sleep for 1s
this is outcome, too!
second sleep for 2s

在nohup.txt文件中不仅出现了我想要的运行结果，还出现了我不想要的运行过程！这也就解释了为什么在我的sam文件中会出现很多本不应该属于该文件的内容。
既然知道了原因，那么解决问题就不难了。我们可以通过重导向输出，把运行结果和运行过程分别输出到不同的文件中。

$ nohup ./example.sh 2>stderr.log 1>outcome.txt

$ cat stderr.log 
sleep for 1s
second sleep for 2s

$ cat outcome.txt 
this is outcome!
this is outcome, too!

这样，将过程以标准错误形式输出到stderr.log中，将结果以标准输出形式输出到outcome.txt中。
所以本文最开头提到的命令可以改为：

nohup bwa mem ref.fa read1.fq.gz read2.fq.gz 1> read12.sam 2>read12.log &

总结

nohup在默认条件下，标准错误和标准输出会重导向到同一个文件中；通过文件描述符（0，1，2）来对控制输出内容；养成良好的输出控制习惯，对标准输出和标准错误要区别对待。

===== THE END =====

参考资料：

https://robots.thoughtbot.com/input-output-redirection-in-the-shell#file-descriptors
https://www.brianstorti.com/understanding-shell-script-idiom-redirect/