Pourquoi la «commande nohup> & / dev / null» semble-t-elle «fonctionner» dans certains shells?

J'ai édité une réponse sur Ask Ubuntu qui suggérait ce qui suit

nohup gedit >& /dev/null & 

Quand ils voulaient dire

nohup gedit &> /dev/null & 

Ce dernier redirige correctement stderr et stdout vers /dev/null. Je m'attendais à ce que le premier crée un fichier appelé &ou, plus probablement, produise une erreur comme il le fait pour d'autres cas:

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

Au lieu de cela, il semble fonctionner exactement de la même manière que le premier, une geditfenêtre apparaît et aucun message d'erreur n'est imprimé.

Je dois également noter que cela est spécifique au shell:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(version du paquet deb: 20110502-2) et tcsh(6.18.01): fonctionne comme décrit ci-dessus, aucun message d'erreur, aucun fichier créé.

• dash (0.5.7-3):

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

• ksh(93u + 2012-08-01): échoue, mais un processus est apparemment démarré ( 1223) bien qu'aucune geditfenêtre n'apparaisse:

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

Alors, pourquoi cette commande s'exécute-t-elle simplement sans erreur (et sans fichier de sortie créé) dans certains shells et échoue dans d'autres? Que >&fait-on dans le cas apparemment spécial de nohup? Je suppose que cela >& /dev/nullest interprété comme >&/dev/nullmais pourquoi l'espace ne provoque-t-il pas une erreur dans ces coquilles?

nohup gedit &> /dev/null

est la syntaxe POSIX et est la même que:

nohup gedit &
> /dev/null

Cela est exécuté nohup gediten arrière-plan, puis effectuez une > /dev/nullredirection sans exécuter de commande.

nohup gedit >& /dev/null

n'est pas une syntaxe POSIX et est le cshmoyen de rediriger stdout et stderr vers / dev / null. cshn'a pas l' 2>&1opérateur comme dans Bourne, c'est donc le seul moyen cshde rediriger stderr.

zsh(comme souvent) fournit également la cshsyntaxe, mais il prend également en charge l' opérateur de x>&y duplication fd du shell Bourne, ce qui signifie qu'il y a un conflit.

ls >&file

redirige lsstdout et stderr vers file, mais si le fichier est 2, vous avez un problème

ls >&2

signifie rediriger stdout vers la ressource pointée par fd 2 ( dup(2, 1)). Vous devez donc l'écrire:

ls >& ./2

si vous vouliez rediriger à la fois stdout et stderr de lsdans un fichier appelé 2dans le répertoire courant; ou utilisez la syntaxe standard.

bashne comprenait pas initialement >&, mais il a &>plutôt introduit l' opérateur pour cela, rompant la conformité POSIX dans le processus (bien qu'il soit peu probable qu'un script utilise cmd &> xxx).

kshcopié cet opérateur dans ksh93t + en 2009, mksh dans R35 en 2008 (désactivé en posixmode) mais pas >&.

bashajout de la prise >&en charge de la version 2.05.

busybox a shajouté un support pour les deux &>et >&dans 1.13 (2008).

Ni >&ni &>comme signifiant redirection stdout et stderr ne sont POSIX / Bourne.

Si vous souhaitez rediriger stdout et stderr de manière portative, la syntaxe est

cmd > file 2>&1