Dies ist die Befehlsfolge gedit gestartet, kann aber nicht von seiner Prozess-ID beendet werden

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

Für einen sleep würde es gut funktionieren Prozess, wie

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

Was ist der Unterschied? Wie kann die gedit Prozess beendet werden?

Akzeptierte Antwort:

Der gedit Prozess ist bereits beendet.

Denken Sie daran, wie Windows-Anwendungen hauptsächlich in den Win16-Tagen funktionierten, bevor Win32 auftauchte und es abschaffte:wo es hInstance gab und hPrevInstance , der Versuch, eine zweite Instanz vieler Anwendungen auszuführen, übergab die Dinge einfach an die erste Instanz, und dies erschwerte die Dinge für Befehlsskripting-Tools (wie Take Command), da eine Anwendung ein zweites Mal aufgerufen wurde und sie sichtbar auf der vorhanden war screen als hinzugefügtes Fenster angezeigt, aber soweit es den Befehlsinterpreter betraf, wurde der untergeordnete Prozess, den er gerade ausgeführt hatte, sofort beendet?

Nun, GNOME hat das Win16-Verhalten für Linux zurückgebracht.

Mit GIO-Anwendungen wie gedit , verhält sich die Anwendung wie folgt:

• Wenn es keinen registrierten „Server“ mit dem Namen org.gnome.gedit gibt bereits auf dem Desktop-Bus pro Benutzer/pro Anmeldung, gedit entscheidet, dass es die erste Instanz ist. Es wird die org.gnome.gedit Server und läuft weiter.
• Wenn es einen registrierten „Server“ mit dem Namen org.gnome.gedit gibt bereits auf dem Desktop-Bus pro Benutzer/pro Anmeldung, gedit entscheidet, dass es sich um eine zweite oder nachfolgende Instanz handelt. Es erstellt Desktop-Bus-Nachrichten an die erste Instanz, gibt seine Befehlszeilenoptionen und -argumente weiter, und wird dann einfach beendet .

Was Sie sehen, hängt also davon ab, ob Sie den gedit haben Server läuft bereits. Wenn nicht, stecken Sie in Sebvieiras Schuhen und fragen sich, warum Sie das beschriebene Verhalten nicht sehen. Wenn ja, sind Sie in Ihren Schuhen und sehen den gedit Der Prozess wird fast sofort beendet, zumal Sie ihm keine Befehlszeilenoptionen oder Argumente zum Senden an die „erste Instanz“ gegeben haben. Daher gibt es keinen Prozess mehr mit dieser ID.

Viel Spaß macht es, wenn, wie oben angedeutet, der Per-Login-Desktop-Bus auf den „neuen“ Stil eines Per-User-Desktop-Bus umgestellt wird und plötzlich keine 1:1-Beziehung zwischen einem Desktop-Bus und einem X-Display mehr besteht mehr. Einzelne benutzerbusweite Instanzanwendungen müssen plötzlich in der Lage sein, gleichzeitig mit mehreren X-Displays zu kommunizieren.

Weitere Heiterkeit entsteht, wenn Leute versuchen, gedit auszuführen als Superuser über sudo , da es entweder keine Verbindung zu einem Desktop-Bus pro Benutzer herstellen kann oder sich mit dem falschen Desktop-Bus (dem des Superusers) verbindet.

Verwandte:Wie chmod ohne /usr/bin/chmod?

Es gibt einen Vorschlag, gedit zu geben eine Befehlszeilenoption, die den aufgerufenen Prozess einfach zur eigentlichen Editor-Anwendung macht , sodass gedit wäre nützlich als der Editor, auf den der EDITOR zeigt Umgebungsvariable (was für viele gängige Verwendungen von EDITOR nicht der Fall ist , von crontab zu git , wenn es einfach sofort beendet wird). Dieser Vorschlag ist noch nicht verwirklicht worden.

In der Zwischenzeit haben die Leute verschiedene Möglichkeiten, eine einfache zweite Instanz eines „leichten Texteditors“ zu haben, wie z. B. das Aufrufen einer ganz neuen Desktop Bus-Instanz, die privat zum Aufruf von gedit ist , mit dbus-run-session . Dies neigt natürlich dazu, andere GNOME-Desktop-Bus-Server auf diesem privaten Bus hochzufahren, da sie wiederum von gedit aufgerufen werden , was es überhaupt nicht „leicht“ macht.

Das i-Tüpfelchen ist, wenn Sie dieser oder einer ähnlichen Empfehlung gefolgt sind und eine Shell-Funktion namens gedit dazwischengeschaltet haben das entfernt sofort den gedit process aus der Jobliste der Shell. Der Prozess wird nicht nur schnell beendet, damit Sie ihn später nicht mit kill sehen oder ps , aber die Shell überwacht es nicht einmal als Shell-gesteuerten Job.

Weiterführende Literatur

• Apps/Gedit/NewSingleInstance. GNOME-Wiki. 2013.
• „Beschreibung“. GApplication . GNOME-Entwickler-Wiki.
• https://stackoverflow.com/questions/7553452/
• Stefan Löffler (04.05.2011). verwendet die laufende Instanz nicht wieder, wenn sie von Nautilus aus gestartet wird. Fehler Nr. 777292. Startrampe.