Чому команда "nohup> & / dev / null", здається, "працює" в деяких оболонках?

Я відредагував відповідь на запитання Ubuntu, яка передбачала наступне

nohup gedit >& /dev/null & 

Коли вони насправді мали на увазі

nohup gedit &> /dev/null & 

Останній правильно переспрямовує як stderr, так і stdout на /dev/null. Я очікував, що колишній створить файл, який називається, &або, що більше ймовірно, помилиться, як це стосується інших випадків:

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

Натомість, здається, працює точно так само, як і колишнє, geditз'являється вікно, і повідомлення про помилку не друкується.

Я також повинен зазначити, що це специфічно оболонки:

• bash(4.2.45 (1) -випуск), zsh(5.0.2), csh(версія пакета tcshдебютування: 20110502-2) та (6.18.01): працює, як описано вище, повідомлення про помилку, файлів не створено.

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

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

• ksh(93u + 2012-08-01): не вдається, але процес, мабуть, запускається ( 1223), хоча не geditз'являється вікна:

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

Отже, чому ця команда просто запускається без помилок (і не створюється вихідний файл) в одних оболонках, а в інших не виходить з ладу? Що >&робити у, мабуть, особливому випадку nohup? Я здогадуюсь, що >& /dev/nullце трактується як, >&/dev/nullале чому простір не спричинив помилку в цих оболонках?

nohup gedit &> /dev/null

є синтаксисом POSIX і є тим же, що:

nohup gedit &
> /dev/null

Це запускається nohup geditу фоновому режимі, а потім виконується > /dev/nullперенаправлення без виконання команди.

nohup gedit >& /dev/null

не є синтаксисом POSIX і є cshспособом перенаправити як stdout, так і stderr на / dev / null. cshне має 2>&1оператора, як знайдено в Bourne, тому єдиний спосіб cshповинен перенаправити stderr.

zsh(як часто) також надає cshсинтаксис, але він також підтримує оператор x>&y дублювання fd оболонки Bourne, що означає, що там конфлікт.

ls >&file

перенаправляє lsstdout і stderr до file, але якщо файл є 2, у вас є проблема як

ls >&2

означає перенаправлення stdout на ресурс, на який вказує fd 2 ( dup(2, 1)). Тому вам потрібно написати це:

ls >& ./2

якщо ви хотіли перенаправити як stdout, так і stderr lsу файл, викликаний 2у поточному каталозі; або використовувати стандартний синтаксис.

bashспочатку нічого не зрозумів >&, але &>замість цього він представив оператора, порушуючи відповідність POSIX у процесі (хоча навряд чи сценарій буде використаний cmd &> xxx).

kshскопіював цього оператора в ksh93t + в 2009 році, mksh в R35 в 2008 році (відключений в posixрежимі), але ні >&.

bashдодано підтримку >&в 2.05.

busbox shдодав підтримку &>і >&в 1.13 (2008).

Ні, >&ні &>як значення перенаправлення stdout та stderr не є POSIX / Bourne.

Якщо ви хочете перенаправити як stdout, так і stderr портативно, синтаксис є

cmd > file 2>&1