¿Por qué 'nohup command> & / dev / null' parece "funcionar" en algunos shells?

Edité una respuesta en Ask Ubuntu que sugería lo siguiente

nohup gedit >& /dev/null & 

Cuando realmente querían decir

nohup gedit &> /dev/null & 

Este último redirige correctamente stderr y stdout a /dev/null. Esperaba que el primero creara un archivo llamado &o, más probablemente, diera un error como lo hace para otros casos:

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

En cambio, parece funcionar exactamente de la misma manera que la primera, geditaparece una ventana y no se imprime ningún mensaje de error.

También debo tener en cuenta que esto es específico del shell:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(versión del paquete deb: 20110502-2) y tcsh(6.18.01): funciona como se describe anteriormente, sin mensaje de error, sin archivos creados.

• dash (0.5.7-3):

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

• ksh(93u + 2012-08-01): falla, pero aparentemente se inicia un proceso ( 1223) aunque no geditaparece ninguna ventana:

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

Entonces, ¿por qué este comando simplemente se ejecuta sin errores (y sin archivos de salida creados) en algunos shells y falla en otros? ¿Qué está >&haciendo en el caso aparentemente especial de nohup? Supongo que >& /dev/nullse está interpretando, >&/dev/nullpero ¿por qué el espacio no está causando un error en estos depósitos?

nohup gedit &> /dev/null

es la sintaxis POSIX y es lo mismo que:

nohup gedit &
> /dev/null

Eso se ejecuta nohup gediten segundo plano y luego realiza una > /dev/nullredirección sin ejecutar un comando.

nohup gedit >& /dev/null

no es la sintaxis POSIX y es la cshforma de redirigir stdout y stderr a / dev / null. cshno tiene el 2>&1operador como se encuentra en Bourne, por lo que es la única forma cshde redirigir stderr.

zsh(tan a menudo) también proporciona la cshsintaxis, pero también admite el operador de x>&y duplicación fd del shell Bourne, lo que significa que hay un conflicto allí.

ls >&file

redirecciona lsstdout y stderr a file, pero si el archivo es 2, tienes un problema como

ls >&2

significa redireccionar stdout al recurso al que apunta fd 2 ( dup(2, 1)). Entonces necesitas escribirlo:

ls >& ./2

si desea redirigir tanto stdout como stderr de lsa un archivo llamado 2en el directorio actual; o use la sintaxis estándar.

bashinicialmente no entendía >&, pero introdujo al &>operador en su lugar para eso, rompiendo el cumplimiento de POSIX en el proceso (aunque es poco probable que use un script cmd &> xxx).

kshCopié ese operador en ksh93t + en 2009, mksh en R35 en 2008 (desactivado en posixmodo) pero no >&.

bashSoporte adicional para >&en 2.05.

busybox shagregó soporte para ambos &>y >&en 1.13 (2008).

Ni >&tampoco &>en el sentido de la salida estándar de redirección y stderr son POSIX / Bourne.

Si desea redirigir tanto stdout como stderr de forma portátil, la sintaxis es

cmd > file 2>&1