Por que 'nohup command> & / dev / null' parece “funcionar” em alguns shells?

Editei uma resposta no Ask Ubuntu que sugeria o seguinte

nohup gedit >& /dev/null & 

Quando eles realmente quiseram dizer

nohup gedit &> /dev/null & 

O último redireciona corretamente o stderr e o stdout para /dev/null. Eu esperava que o primeiro crie um arquivo chamado &ou, mais provavelmente, dê um erro, como ocorre em outros casos:

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

Em vez disso, parece funcionar exatamente da mesma maneira que a anterior, uma geditjanela aparece e nenhuma mensagem de erro é impressa.

Também devo observar que isso é específico do shell:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(versão do pacote deb: 20110502-2) e tcsh(6.18.01): funciona como descrito acima, sem mensagem de erro, sem arquivos criados.

• dash (0.5.7-3):

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

• ksh(93u + 2012-08-01): falha, mas aparentemente um processo foi iniciado ( 1223) embora nenhuma geditjanela apareça:

  $ 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 & 
                 ^

Então, por que esse comando simplesmente é executado sem erros (e nenhum arquivo de saída criado) em alguns shells e falha em outros? O que está >&fazendo no caso aparentemente especial de nohup? Suponho que isso >& /dev/nullesteja sendo interpretado como >&/dev/nullmas por que o espaço não está causando um erro nessas conchas?

nohup gedit &> /dev/null

é a sintaxe POSIX e é o mesmo que:

nohup gedit &
> /dev/null

Isso é executado nohup geditem segundo plano e, em seguida, faz um > /dev/nullredirecionamento sem executar um comando.

nohup gedit >& /dev/null

não é sintaxe POSIX e é a cshmaneira de redirecionar stdout e stderr para / dev / null. cshnão possui o 2>&1operador encontrado em Bourne, portanto, é a única maneira cshde redirecionar o stderr.

zsh(com frequência) também fornece a cshsintaxe, mas também suporta o operador de x>&y duplicação fd do shell Bourne, o que significa que há um conflito lá.

ls >&file

redireciona lso stdout e o stderr para file, mas se o arquivo for 2, você terá um problema como

ls >&2

significa redirecionar stdout para o recurso apontado por fd 2 ( dup(2, 1)). Então você precisa escrever:

ls >& ./2

se você deseja redirecionar o stdout e o stderr lspara um arquivo chamado 2no diretório atual; ou use a sintaxe padrão.

bash inicialmente não entendi >& , mas introduziu o &>operador para isso, quebrando a conformidade com POSIX no processo (embora seja improvável que um script usasse cmd &> xxx).

kshcopiou esse operador no ksh93t + em 2009, mksh no R35 em 2008 (desativado no posixmodo), mas não >&.

bash suporte adicionado para >& 2.05.

O busybox shadicionou suporte para ambos&> e >&em 1.13 (2008).

Nem como >&nem &>o redirecionamento de significado stdout e stderr são POSIX / Bourne.

Se você deseja redirecionar stdout e stderr de forma portável, a sintaxe é

cmd > file 2>&1