Perché alcuni comandi "bloccano" il terminale fino a quando non hanno terminato?

A volte esegui un programma dal terminale, diciamo, lxpanel^† . Il terminale non ti riporterà al prompt, si bloccherà. Puoi premere Ctrl+ Cper tornare al prompt, ma questo ucciderà lxpanel. Tuttavia, premendo Alt+ F2(che si apre una finestra per prendere un comando) e l'esecuzione lxpanelfunziona con grazia.

Perchè è questo? Cosa c'è di diverso tra l'esecuzione di un comando dal terminale e dalla finestra "Esegui" che appare quando si preme Alt+ F2?

_{^{† lxpanel qui è stato appena usato come esempio. L'ho sperimentato con più programmi}}

Per impostazione predefinita, il terminale eseguirà il programma in primo piano, quindi non si tornerà alla shell fino al termine del programma. Ciò è utile per i programmi che leggono da stdin e / o scrivono su stdout - in genere non si desidera che molti di essi vengano eseguiti contemporaneamente. Se vuoi eseguire un programma in background, puoi avviarlo in questo modo:

$ lxpanel &

Oppure, se è già in esecuzione, puoi sospenderlo con Ctrl+ Ze quindi eseguirlo bgper spostarlo in background. Ad ogni modo finirai con un nuovo prompt della shell, ma il programma è ancora in esecuzione e il suo output apparirà nel terminale (quindi può apparire improvvisamente mentre sei nel mezzo della digitazione)

Alcuni programmi (in genere demoni) eseguiranno il fork di un processo separato all'avvio, quindi lasceranno immediatamente il processo principale. Ciò consente al programma di continuare a funzionare senza bloccare la shell

Quando si avvia un programma in un terminale, il terminale si "bloccherà" fino a quando il programma non si arresta. Premendo Ctrl+ csi chiude il programma e si ritorna quindi al prompt. Lo vedrai con tutte le app della GUI, ad esempio prova Firefox.

Quando si utilizza un altro metodo come Alt + F2 o si fa clic sui menu, il programma viene avviato in background in modo che non accada nulla di strano (e comunque non c'è nessun prompt dei comandi).

Se vuoi ancora avviare le app della GUI dal terminale, aggiungi &alla fine del tuo comando, in questo modo

lxpanel &

Questo dice al terminale di funzionare lxpanelin background e darti immediatamente un altro prompt.

I programmi vengono eseguiti in modo predefinito tramite una shell in primo piano. Questo fa sì che la shell sospenda l'operazione e diriga stdin / stdout / sterr dal terminale al programma. I programmi eseguiti tramite l'ambiente desktop sono biforcati , il che li fa funzionare indipendentemente dal programma che li ha eseguiti. Questo può essere simulato nella maggior parte delle shell aggiungendo &a al comando, anche se questo collegherà ancora std * al terminale (sebbene la lettura da stdin su un programma in background abbia ulteriori complicazioni).

Gli sfondi & bene tranne per i programmi che ritornano che richiedono in seguito l'interazione con la console (ad esempio un "apt -y update &" che alla fine entra nello stato STOP poiché vuole chiedere all'utente una domanda "davvero forzata?" Molto più tardi .... quando nessuno sta più guardando).

Per collegare quel buco e informare il processo che un terminale non sarà mai realmente disponibile, aggiungo un <& - ad alcuni dei miei comandi, staccandoli completamente dal terminale attivo dicendo che STDIN non è più possibile. Assicurati che / bin / bash sia la tua shell se la usi comunque. Lo script continuerà a registrare tutti gli errori relativi alla mancanza di pseudoterminali su cui inviare qualsiasi prompt.

Per esempio:

`./runme.sh &> runme.log <&- & disown`

è il mio modo ultimo di dissociarmi dall'attuale sessione terminale. Sia STDOUT che STDERR vengono registrati su runme.log, non importa se la tua console o shell si chiudono prima o se esci / esegui il logout su un altro account (nessuna immondizia terminale dal runme), e grazie a rinnegare anche il genitore-figlio La relazione PID è stata rimossa.

AGGIORNAMENTO: anche con quello ho avuto problemi con un semaforo che lo associa al nome del genitore originale, quindi ora raccomando invece:

at now <<< "(cmd1; cmd2; etc.) &> logfile.log"

Ovviamente, rimuovi &> se vuoi ricevere l'output via e-mail da CRON, o reindirizza tutto su / dev / null invece che su un file.