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 ilorg.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).
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.