为什么“ nohup命令>＆/ dev / null”在某些shell中似乎“起作用”？

我在Ask Ubuntu上编辑了一个建议以下内容的答案

nohup gedit >& /dev/null & 

当他们真正的意思是

nohup gedit &> /dev/null & 

后者正确地将stderr和stdout都重定向到/dev/null。我期望前者会创建一个称为的文件，&或者更有可能像其他情况一样产生错误：

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

相反，它的工作方式gedit似乎与前者完全相同，出现一个窗口，并且未打印任何错误消息。

我还要注意，这是特定于shell的：

• bash（4.2.45（1）-发行版），zsh（5.0.2），csh（deb软件包版本：20110502-2）和tcsh（6.18.01）：如上所述工作，没有错误消息，没有创建文件。

• dash （0.5.7-3）：

  $ nohup gedit >& /dev/null & 
  $ dash: 2: Syntax error: Bad fd number

• ksh（93u + 2012-08-01）：失败，但是1223尽管没有gedit出现窗口，但显然已启动了一个进程（）：

  $ nohup gedit >& /dev/null & 
  [1] 1223
  $ ksh: /dev/null: bad file unit number

• fish （2.0.0）：

  > nohup gedit >& /dev/null & 
  fish: Requested redirection to something that is not a file descriptor /dev/null
  nohup gedit >& /dev/null & 
                 ^

那么，为什么在某些shell中此命令简单地运行而没有错误（也没有创建输出文件），而在其他shell中失败呢？什么是>&中的明显特例干什么nohup？我猜这>& /dev/null被解释为，>&/dev/null但是为什么空间不引起这些shell错误？

nohup gedit &> /dev/null

是POSIX语法，并且与：

nohup gedit &
> /dev/null

该操作nohup gedit在后台运行，然后在> /dev/null不运行命令的情况下进行重定向。

nohup gedit >& /dev/null

不是POSIX语法，而是csh将stdout和stderr都重定向到/ dev / null的方法。csh没有2>&1Bourne中的运算符，因此这是csh重定向stderr 的唯一方法。

zsh（通常）还提供了csh语法，但它也支持Bourne shell 的x>&y fd复制运算符，这意味着那里存在冲突。

ls >&file

将ls的stdout和stderr 重定向到file，但是如果文件是的2，你会遇到问题。

ls >&2

表示将标准输出重定向到fd 2（dup(2, 1)）指向的资源。因此，您需要编写它：

ls >& ./2

如果您想将stdout和stderr都重定向ls到2当前目录中的一个文件中；或使用标准语法。

bash最初不了解>&，但&>为此引入了运算符，从而破坏了POSIX的合规性（尽管脚本不太可能使用cmd &> xxx）。

ksh在2009年以ksh93t +复制了该运算符，在2008年以R35复制了mksh（在posix模式下禁用），但没有>&。

bash增加了>&对2.05的支持。

busybox的sh添加都支持&>和>&在1.13（2008年）。

既不>&也不&>为意重定向输出和错误是POSIX /伯恩。

如果要便携式重定向stdout和stderr，则语法为

cmd > file 2>&1