Risposte:
L' &
operatore finale alla fine di un comando viene utilizzato per mettere i comandi in background. Questa è in realtà una sintassi standard specificata dallo standard POSIX :
Elenchi asincroni
Se un comando viene terminato dall'operatore di controllo ('&'), la shell eseguirà il comando in modo asincrono in una subshell. Ciò significa che la shell non deve attendere il termine del comando prima di eseguire il comando successivo.
Il formato per l'esecuzione di un comando in background è:
command1 & [command2 & ...]
Lo scopo dei comandi in background è quello di eseguire un comando senza la shell principale nello script o la shell interattiva in attesa di un comando, che bloccherebbe l'esecuzione di altri comandi e causerebbe un inconveniente per l'attesa dell'utente. Questo è utile per avviare comandi di lunga durata ma è necessario continuare a lavorare nella shell corrente. Come puoi immaginare, questo ha avuto origine dal momento in cui non c'erano emulatori di terminali multi-scheda, ma i terminali erano veri e propri hardware fisici collegati a un computer stesso.
Dalla definizione si può vedere che &
funge anche da terminatore di comando per elenchi di comandi, proprio come ;
fa. Nel tuo esempio specifico, pyprogramm >> /dev/null 2>&1 &
c'è un solo comando nell'elenco.
Più generalmente,
echo Hello ; echo World ;
e
echo Hello & echo World &
sono due esempi di elenchi terminati dagli operatori ;
e &
. Una differenza è che l' &
elenco terminato avrà input collegato /dev/null
se il controllo del lavoro è disabilitato:
Se il controllo del lavoro è disabilitato (vedere set, -m), l'input standard per un elenco asincrono, prima che vengano eseguiti reindirizzamenti espliciti, deve essere considerato assegnato a un file che ha le stesse proprietà di / dev / null. Ciò non deve avvenire se il controllo del lavoro è abilitato. In tutti i casi, il reindirizzamento esplicito dell'input standard avrà la precedenza su questa attività.
Nell'elenco sequenziale, tuttavia, ogni comando è ancora stdin
connesso al terminale se non ci sono reindirizzamenti espliciti.
Si noti inoltre che dalla definizione che abbiamo menzionato in precedenza, &
esegue i comandi in subshell. Al contrario, l' ;
elenco terminato viene eseguito nella shell corrente. C'è anche una differenza negli stati di uscita. Per &
lo standard dice:
Lo stato di uscita di un elenco asincrono deve essere zero.
Ciò è significativo quando si desidera mettere più comandi in background. Quando scrivi uno script o un comando dovrai scegliere i comandi per i quali non ti importa se falliscono o no, o dovrai trovare un modo per gestire lo stato di uscita diverso da zero (errore). Nel tuo esempio specifico, l' pyprogramm >> /dev/null 2>&1 &
esecuzione in background dovrebbe avere un modo per indicare se ha avuto esito negativo o meno, tuttavia, a giudicare dal fatto che stai usando, 2>&1
stai nascondendo l'output degli errori reindirizzando e probabilmente supponi che lo script non dovrebbe fallire.
Al contrario, lo ;
stato di uscita è definito come:
Lo stato di uscita di un elenco sequenziale deve essere lo stato di uscita dell'ultimo comando nell'elenco.
Ancora una volta, ciò ha implicazioni su come si scrive un elenco sequenziale di comandi nella riga di comando e su come si desidera che le cose vengano gestite se alcuni dei comandi dell'elenco falliscono.
Il fatto che questo è un mezzo di definizione POSIX che tutti Bourne-come conchiglie, significato bash
, dash
e ksh
deve sostenerlo.
&
nel reindirizzamento è diverso da &
come terminatore di comando. Significa duplicare (copiare) l'oggetto descrittore di file. Vedi Cosa significa esattamente nel reindirizzamento dell'output?
Al bash
suo interno c'è anche l' |&
operatore (notare che non c'è spazio tra pipe e e commerciale). Dal manuale di bash :
Se viene utilizzato | &, l'errore standard del comando, oltre all'output standard, è collegato all'input standard del comando2 attraverso la pipe; è una scorciatoia per 2> & 1 |. Questo reindirizzamento implicito dell'errore standard sull'output standard viene eseguito dopo qualsiasi reindirizzamento specificato dal comando.
Significa eseguire il comando in background. Lo script chiamante continua invece di bloccarsi fino al completamento del comando chiamato.
&
nascondere l'output non sembra corretto. Il paragrafo dello standard che stai citando parla di input , non di output . Il motivo della distinzione tra il controllo dei processi abilitato o meno è che un processo in background che tenta di leggere dal tty verrà sospeso. A quel punto è necessario utilizzare il controllo del lavoro per metterlo in primo piano per fornire l'input che sta aspettando. Tutto ciò non può essere fatto senza il controllo del lavoro e quindi se il controllo del lavoro è disabilitato, lo stdin deve essere reindirizzato/dev/null
o equivalente.