Perché 'nohup command> & / dev / null' sembra "funzionare" in alcune shell?

Ho modificato una risposta su Ask Ubuntu che suggeriva quanto segue

nohup gedit >& /dev/null & 

Quando in realtà intendevano

nohup gedit &> /dev/null & 

Quest'ultimo reindirizza correttamente sia stderr che stdout a /dev/null. Mi aspettavo che il primo creasse un file chiamato &o, più probabilmente, generasse un errore come accade per altri casi:

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

Invece, sembra funzionare esattamente allo stesso modo del primo, geditappare una finestra e non viene stampato alcun messaggio di errore.

Dovrei anche notare che questo è specifico della shell:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(versione del pacchetto deb: 20110502-2) e tcsh(6.18.01): funziona come descritto sopra, nessun messaggio di errore, nessun file creato.

• dash (0.5.7-3):

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

• ksh(93u + 2012-08-01): non riesce, ma a quanto pare viene avviato un processo ( 1223) sebbene non venga geditvisualizzata alcuna finestra:

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

Quindi, perché questo comando viene semplicemente eseguito senza errori (e senza file di output creato) in alcune shell e fallisce in altre? Cosa sta >&facendo nel caso apparentemente speciale di nohup? Immagino che >& /dev/nullvenga interpretato come >&/dev/nullma perché lo spazio non causa un errore in queste shell?

nohup gedit &> /dev/null

è la sintassi POSIX ed è uguale a:

nohup gedit &
> /dev/null

Viene eseguito nohup geditin background e quindi esegue un > /dev/nullreindirizzamento senza eseguire un comando.

nohup gedit >& /dev/null

non è sintassi POSIX ed è il cshmodo per reindirizzare sia stdout che stderr su / dev / null. cshnon ha l' 2>&1operatore come si trova a Bourne, quindi è l'unico modo cshper reindirizzare stderr.

zsh(come spesso) fornisce anche la cshsintassi, ma supporta anche l' operatore di x>&y duplicazione fd della shell Bourne, il che significa che c'è un conflitto lì.

ls >&file

reindirizza lsstdout e stderr a file, ma se il file è 2, hai un problema come

ls >&2

significa reindirizzare stdout alla risorsa indicata da fd 2 ( dup(2, 1)). Quindi devi scriverlo:

ls >& ./2

se si desidera reindirizzare sia lo stdout che lo stderr lsin un file chiamato 2nella directory corrente; oppure usa la sintassi standard.

bashinizialmente non capiva >&, ma ha introdotto l' &>operatore per quello, rompendo la conformità POSIX nel processo (anche se è improbabile che uno script userebbe cmd &> xxx).

kshcopiato quell'operatore in ksh93t + nel 2009, mksh in R35 nel 2008 (disabilitato in posixmodalità) ma non >&.

bashaggiunto supporto per >&in 2.05.

busybox ha shaggiunto il supporto per entrambi &>e >&in 1.13 (2008).

Né >&, né &>nel senso di reindirizzamento stdout e stderr sono POSIX / Bourne.

Se si desidera reindirizzare in modo portabile sia stdout che stderr, la sintassi è

cmd > file 2>&1