Warum scheint der Befehl 'nohup> & / dev / null' in einigen Shells zu "funktionieren"?

Ich habe eine Antwort auf Ask Ubuntu bearbeitet , die Folgendes vorschlug

nohup gedit >& /dev/null & 

Als sie es tatsächlich meinten

nohup gedit &> /dev/null & 

Letzteres leitet sowohl stderr als auch stdout korrekt nach um /dev/null. Ich hatte damit gerechnet, dass ersteres entweder eine Datei mit dem Namen "" erstellt &oder eher einen Fehler ausgibt, wie dies in anderen Fällen der Fall ist:

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

Stattdessen scheint es genauso zu funktionieren wie das vorherige, es gediterscheint ein Fenster und es wird keine Fehlermeldung ausgegeben.

Ich sollte auch beachten, dass dies Shell-spezifisch ist:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(deb package version: 20110502-2) und tcsh(6.18.01): Funktioniert wie oben beschrieben, keine Fehlermeldung, keine Dateien erstellt.

• dash (0,5,7-3):

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

• ksh(93u + 2012-08-01): schlägt fehl, aber anscheinend wird ein Prozess gestartet ( 1223), obwohl kein geditFenster angezeigt wird:

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

Warum wird dieser Befehl in einigen Shells einfach ohne Fehler (und ohne erstellte Ausgabedatei) ausgeführt und in anderen schlägt er fehl? Was >&macht man in dem scheinbar besonderen Fall von nohup? Ich vermute, dass >& /dev/nulldies so interpretiert wird, >&/dev/nullaber warum verursacht der Raum in diesen Shells keinen Fehler?

nohup gedit &> /dev/null

ist POSIX-Syntax und entspricht:

nohup gedit &
> /dev/null

Das wird nohup geditim Hintergrund ausgeführt und führt dann eine > /dev/nullUmleitung durch, ohne einen Befehl auszuführen .

nohup gedit >& /dev/null

ist keine POSIX-Syntax und ist die cshMöglichkeit, sowohl stdout als auch stderr nach / dev / null umzuleiten. cshhat nicht den 2>&1Operator wie in Bourne, daher ist es der einzige Weg csh, stderr umzuleiten.

zsh(wie oft) bietet auch die cshSyntax, unterstützt aber auch den x>&y fd-Duplizierungsoperator der Bourne-Shell, was bedeutet, dass dort ein Konflikt vorliegt.

ls >&file

leitet lsdie Befehle stdout und stderr weiter an file, aber wenn die Datei ist 2, haben Sie ein Problem als

ls >&2

bedeutet, dass stdout zu der Ressource umgeleitet wird, auf die fd 2 ( dup(2, 1)) zeigt. Also musst du es schreiben:

ls >& ./2

Wenn Sie sowohl stdout als auch stderr von lsin eine Datei umleiten möchten, die 2im aktuellen Verzeichnis aufgerufen wird . oder verwenden Sie die Standardsyntax.

bashanfangs nicht verstanden >&, aber &>stattdessen wurde der Operator eingeführt , wodurch die POSIX-Konformität verletzt wurde (obwohl es unwahrscheinlich ist, dass ein Skript verwendet wird cmd &> xxx).

kshkopierte diesen Operator in ksh93t + im Jahr 2009, mksh in R35 im Jahr 2008 (deaktiviert im posixModus), aber nicht >&.

bashUnterstützung für >&in 2.05 hinzugefügt .

busybox shhat die Unterstützung sowohl für &>als auch >&für 1.13 (2008) hinzugefügt .

Weder als Redirect >&noch &>als stdout oder stderr gelten POSIX / Bourne.

Wenn Sie sowohl stdout als auch stderr portabel umleiten möchten, lautet die Syntax

cmd > file 2>&1