Dlaczego „nohup command> & / dev / null” wydaje się „działać” w niektórych powłokach?

Zredagowałem odpowiedź na Ask Ubuntu, która sugerowała, co następuje

nohup gedit >& /dev/null & 

Kiedy tak naprawdę mieli na myśli

nohup gedit &> /dev/null & 

Ten drugi poprawnie przekierowuje zarówno stderr, jak i stdout do /dev/null. Spodziewałem się, że ten pierwszy utworzy plik o nazwie &lub, co bardziej prawdopodobne, spowoduje błąd, tak jak w innych przypadkach:

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

Zamiast tego wydaje się, że działa dokładnie tak samo jak poprzedni, geditpojawia się okno i nie jest drukowany komunikat o błędzie.

Powinienem również zauważyć, że jest to specyficzne dla powłoki:

• bash(4.2.45 (1) -release), zsh(5.0.2), csh(wersja pakietu deb: 20110502-2) i tcsh(6.18.01): działa jak opisano powyżej, bez komunikatu o błędzie, nie utworzono plików.

• dash (0,5.7-3):

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

• ksh(93u + 2012-08-01): kończy się niepowodzeniem, ale proces najwyraźniej się rozpoczyna ( 1223), chociaż nie geditpojawia się żadne okno:

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

Dlaczego więc to polecenie po prostu działa bez błędów (i nie jest tworzony plik wyjściowy) w niektórych powłokach, aw innych nie działa? Co >&robi w pozornie szczególnym przypadku nohup? Zgaduję, że >& /dev/nulljest to interpretowane, >&/dev/nullale dlaczego przestrzeń nie powoduje błędu w tych powłokach?

nohup gedit &> /dev/null

jest składnią POSIX i jest taki sam jak:

nohup gedit &
> /dev/null

To jest uruchamiane nohup geditw tle, a następnie wykonaj > /dev/nullprzekierowanie bez uruchamiania polecenia.

nohup gedit >& /dev/null

nie jest składnią POSIX i jest cshsposobem na przekierowanie zarówno stdout, jak i stderr do / dev / null. cshnie ma 2>&1operatora takiego jak w Bourne, więc jest to jedyny sposób csh, aby przekierować stderr.

zsh(jak często) zapewnia również cshskładnię, ale obsługuje również operatora x>&y duplikacji fd powłoki Bourne'a, co oznacza, że ​​istnieje konflikt.

ls >&file

przekierowuje lsstdout i stderr do file, ale jeśli plik jest 2, masz problem z

ls >&2

oznacza przekierowanie standardowego wyjścia do zasobu wskazanego przez fd 2 ( dup(2, 1)). Musisz to napisać:

ls >& ./2

jeśli chcesz przekierować zarówno stdout, jak i stderr lsdo pliku wywoływanego 2w bieżącym katalogu; lub użyj standardowej składni.

bashpoczątkowo nie rozumiał >&, ale &>zamiast tego wprowadził operatora, łamiąc zgodność z POSIX w tym procesie (choć jest mało prawdopodobne, aby skrypt go użył cmd &> xxx).

kshskopiował tego operatora w ksh93t + w 2009 r., mksh w R35 w 2008 r. (wyłączony w posixtrybie), ale nie >&.

bashdodano obsługę >&w 2.05.

busybox shdodał obsługę obu wersji &>i >&1.13 (2008).

Ani >&ani &>jako znacznik przekierowania stdout i stderr nie są POSIX / Bourne.

Jeśli chcesz przekierować przenośnie stdout i stderr, składnia jest następująca

cmd > file 2>&1