Toto je sekvence příkazů gedit spustí, ale nelze jej zabít z jeho ID procesu

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

Pro sleep by to fungovalo dobře proces, jako

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

Jaký je v tom rozdíl? Jak může gedit proces ukončit?

Přijatá odpověď:

gedit proces je již ukončeno.

Vzpomeňte si, jak aplikace pro Windows fungovaly hlavně v době 16 dnů před Win32, než se objevil Win32 a zmizel:tam, kde byly hInstance a hPrevInstance , při pokusu o spuštění druhé instance mnoha aplikací se věci jednoduše předaly první instanci, a to zkomplikovalo práci nástrojům pro skriptování příkazů (jako je Take Command), protože člověk by vyvolal aplikaci podruhé, viditelně by tam byla na obrazovka jako přidané okno, ale pokud jde o interpret příkazů, podřízený proces, který právě spustil, okamžitě skončil?

GNOME přineslo zpět chování Win16 pro Linux.

S GIO aplikacemi jako gedit , aplikace se chová následovně:

• Pokud neexistuje žádný registrovaný „server“ s názvem org.gnome.gedit již na sběrnici pro jednotlivé uživatele/přihlášení, gedit rozhodne, že je to první instance. stane se org.gnome.gedit serveru a běží dál.
• Pokud existuje registrovaný „server“ s názvem org.gnome.gedit již na sběrnici pro jednotlivé uživatele/přihlášení, gedit rozhodne, že jde o druhý nebo následující případ. Konstruuje zprávy Desktop Bus do první instance, předává možnosti a argumenty příkazového řádku a pak jednoduše končí .

To, co vidíte, tedy závisí na tom, zda máte gedit server již běží. Pokud ne, budete v kůži Sebvieira a budete se divit, proč nevidíte popsané chování. Pokud ano, budete ve své kůži a uvidíte gedit proces se ukončí téměř okamžitě, zejména proto, že jste mu nedali žádné možnosti příkazového řádku nebo argumenty, které by se měly odeslat do „první instance“. To je důvod, proč již neexistuje proces s tímto ID.

Mnoho zábavy nastane, když, jak již bylo zmíněno výše, se desktopová sběrnice pro přihlášení přepne na „nový“ styl desktopové sběrnice pro jednotlivé uživatele a mezi desktopovou sběrnicí a X displejem najednou není žádný vztah 1:1. více. Aplikace s jedinou uživatelskou sběrnicí najednou musí být schopny komunikovat s více X displeji současně.

Další veselí nastává, když se lidé pokoušejí spustit gedit jako superuživatel pomocí sudo , protože se buď nemůže připojit ke sběrnici desktopu pro jednotlivé uživatele, nebo se připojuje k nesprávné sběrnici desktopu (superuživatele).

Související:Jak chmod bez /usr/bin/chmod?

Existuje návrh dát gedit možnost příkazového řádku, díky níž je proces, který je vyvolán, pouze skutečnou editorovou aplikací , takže gedit by bylo užitečné jako editor, na který ukazuje EDITOR proměnná prostředí (což pro mnoho běžných použití EDITOR není , z crontab na git , když prostě okamžitě vystoupí). Tento návrh se zatím nestal skutečností.

Mezitím mají lidé různé způsoby, jak mít jednoduchou druhou instanci „odlehčeného textového editoru“, jako je vyvolání celé nové instance Desktop Bus, soukromé pro vyvolání gedit , s dbus-run-session . Samozřejmě to má tendenci roztáčet další servery GNOME Desktop Bus na této soukromé sběrnici, protože je zase vyvolává gedit , takže není vůbec „lehký“.

Třešničkou na dortu je, když se budete řídit tímto nebo podobným doporučením a vložíte shellovou funkci s názvem gedit který okamžitě odstraní gedit proces ze seznamu úloh shellu. Nejen, že se proces rychle ukončí, takže ho později neuvidíte pomocí kill nebo ps , ale shell to ani nemonitoruje jako úlohu řízenou shellem.

Další čtení

• Apps/Gedit/NewSingleInstance. Wiki GNOME. 2013.
• „Popis“. GApplication . Wiki vývojářů GNOME.
• https://stackoverflow.com/questions/7553452/
• Stefan Löffler (2011-05-04). při spuštění z nautilus znovu nepoužívá spuštěnou instanci. Chyba #777292. Launchpad.