Por que o 'nohup command & / dev / null' parece funcionar em alguns shells?

Question

Eu editei uma resposta no Ask do Ubuntu que estava sugerindo o seguinte

nohup gedit >& /dev/null & 

Quando eles realmente querem dizer

nohup gedit &> /dev/null & 

O último redireciona corretamente stderr e stdout para /dev/null . Eu esperava que o primeiro criasse um arquivo chamado & ou, mais provavelmente, desse 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 o anterior, aparece uma janela gedit 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 é iniciado um processo ( 1223 ), embora não apareça nenhuma janela 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 & 
                 ^
  

Então, por que esse comando simplesmente roda sem erros (e nenhum arquivo de saída é criado) em alguns shells e falha em outros? O que o >& está fazendo no caso aparentemente especial de nohup ? Eu estou supondo que >& /dev/null está sendo interpretado como >&/dev/null , mas por que o espaço não está causando um erro nesses shells?

    

Answer 1

nohup gedit &> /dev/null

é a sintaxe POSIX e é a mesma que:

nohup gedit &
> /dev/null

Isso é executado em nohup gedit em segundo plano e, em seguida, faz um redirecionamento > /dev/null sem executar um comando.

nohup gedit >& /dev/null

não é a sintaxe POSIX e é a maneira csh de redirecionar stdout e stderr para / dev / null. csh não tem o operador 2>&1 como encontrado em Bourne, então é a única maneira de csh redirecionar o stderr.

zsh (como sempre) também fornece a sintaxe csh , mas também suporta o operador x>&y fd duplicação do shell Bourne, o que significa que existe um conflito.

ls >&file

redireciona stdout e stderr de ls para file , mas se o arquivo for 2 , você tem um problema como

ls >&2

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

ls >& ./2

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

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

ksh copiou esse operador em ksh93t + em 2009, mksh em R35 em 2008 (desabilitado no modo posix ) mas não >& .

bash adicionou suporte para >& em 2.05.

busybox sh adicionou suporte para &> e >& em 1.13 (2008).

Nem >& nem &> como significando redirect stdout e stderr são POSIX / Bourne.

Se você quiser redirecionar ambos, stdout e stderr, a sintaxe é

cmd > file 2>&1