Questa è la sequenza di comandi, gedit si avvia, ma non può essere terminato dal suo ID processo

$ gedit&
$ t=$!
$ echo $t
4824
$ kill $t
bash: kill: (4824) - No such process

Funzionerebbe bene per un sleep processo, come

sleep 999&
[1] 4881
$ t=$!
$ echo $t
4881
$ kill $t
$ ps -p $t
[1]   Terminated              sleep 999

Qual è la differenza? Come può il gedit processo essere terminato?

Risposta accettata:

Il gedit processo è già terminato.

Ricorda come le applicazioni Windows funzionavano principalmente nei giorni Win16 prima che Win32 arrivasse e lo eliminasse:dove c'erano hInstance e hPrevInstance , il tentativo di eseguire una seconda istanza di molte applicazioni passava semplicemente le cose alla prima istanza, e questo rendeva le cose difficili per gli strumenti di scripting dei comandi (come Take Command) perché si invocava un'applicazione una seconda volta, sarebbe visibilmente presente sul schermo come finestra aggiunta, ma per quanto riguarda l'interprete dei comandi il processo figlio che aveva appena eseguito è uscito immediatamente?

Bene, GNOME ha riportato il comportamento di Win16 per Linux.

Con applicazioni GIO come gedit , l'applicazione si comporta come segue:

• Se non esiste un "server" registrato denominato org.gnome.gedit già sul bus desktop per utente/accesso, gedit decide che è la prima istanza. diventa il org.gnome.gedit server e continua a funzionare.
• Se esiste un "server" registrato denominato org.gnome.gedit già sul bus desktop per utente/accesso, gedit decide che si tratta di una seconda o successiva istanza. Costruisce messaggi Desktop Bus alla prima istanza, passando lungo le opzioni e gli argomenti della riga di comando, e quindi esce semplicemente .

Quindi quello che vedi dipende dal fatto che tu abbia il gedit server già in esecuzione. In caso contrario, sarai nei panni di Sebvieira e ti chiederai perché non vedi il comportamento descritto. Se lo hai, sarai nei tuoi panni e vedrai il gedit processo che termina quasi immediatamente, soprattutto perché non gli hai fornito alcuna opzione o argomento della riga di comando da inviare alla "prima istanza". Da qui il motivo per cui non esiste più un processo con quell'ID.

Ne consegue molto divertimento quando, come accennato in precedenza, il bus desktop per accesso passa al "nuovo" stile di un bus desktop per utente e improvvisamente non c'è una relazione 1:1 tra un bus desktop e un display X. Di Più. Improvvisamente, le singole applicazioni a livello di bus utente devono essere in grado di comunicare con più display X contemporaneamente.

Segue ulteriore ilarità quando le persone tentano di eseguire gedit come superutente tramite sudo , poiché non può connettersi a un bus desktop per utente o si connette al bus desktop sbagliato (del superutente).

Correlati:come eseguire chmod senza /usr/bin/chmod?

C'è una proposta per dare gedit un'opzione della riga di comando che rende il processo invocato solo l'effettiva applicazione dell'editor , in modo che gedit sarebbe utile come editor indicato da EDITOR variabile di ambiente (che non è per molti usi comuni di EDITOR , da crontab a git , quando esce immediatamente). Questa proposta non è ancora diventata realtà.

Nel frattempo, le persone hanno vari modi per avere una semplice seconda istanza di un "editor di testo leggero", come invocare un'istanza Desktop Bus completamente nuova, privata dell'invocazione di gedit , con dbus-run-session . Ovviamente, questo tende a far girare altri server GNOME Desktop Bus su questo bus privato poiché a loro volta vengono invocati da gedit , rendendolo per niente “leggero”.

La ciliegina sulla torta è quando hai seguito questa raccomandazione o una simile e hai interposto una funzione shell chiamata gedit che rimuove immediatamente il gedit processo dall'elenco dei lavori della shell. Non solo il processo termina rapidamente in modo da non vederlo più tardi con kill o ps , ma la shell non lo monitora nemmeno come un lavoro controllato dalla shell.

Ulteriori letture

• App/Gedit/NewSingleInstance. wiki di GNOME. 2013.
• "Descrizione". GApplication . Wiki per sviluppatori GNOME.
• https://stackoverflow.com/questions/7553452/
• Stefan Löffler (04-05-2011). non riutilizza l'istanza in esecuzione quando viene avviata da nautilus. Bug #777292. Launchpad.