這是命令序列，gedit啟動，但不能從它的程序 ID 中殺死

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

它適用於一個sleep過程，比如

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

有什麼不同？如何gedit終止程序？

該gedit過程已經終止。

記住在 Win32 出現並取消它之前的 Win16 天，Windows 應用程序主要是如何工作的：在哪裡有hInstance和hPrevInstance，嘗試執行許多應用程序的第二個實例只是將事情交給第一個實例，這讓事情變得困難命令腳本工具（如 Take Command），因為它會第二次呼叫應用程序，它會在螢幕上作為添加的視窗可見，但就命令解釋器而言，它剛剛執行的子程序立即退出?

好吧，GNOME 為 Linux 帶來了 Win16 行為。

使用 GIO 應用程序，如gedit，應用程序的行為如下：

• org.gnome.gedit如果在每個使用者/每個登錄的桌面匯流排上沒有已命名的註冊“伺服器” ，gedit則確定它是第一個實例。它成為伺服器並org.gnome.gedit繼續執行。
• org.gnome.gedit如果在每個使用者/每個登錄的桌面匯流排上已經有一個註冊的“伺服器” ，gedit則確定它是第二個或後續實例。它構造桌面匯流排消息到第一個實例，傳遞它的命令行選項和參數，然後簡單地退出。

所以你看到的取決於你是否gedit已經執行了伺服器。如果你沒有，你會站在 sebvieira 的位置，想知道為什麼你沒有看到所描述的行為。如果你有，你會在你的鞋子裡看到這個gedit過程幾乎立即終止，特別是因為你沒有給它任何命令行選項或參數來發送到“第一個實例”。因此，不再有具有該 ID 的程序的原因。

就像上面提到的那樣，當每次登錄的桌面匯流排切換到每個使用者桌面匯流排的“新”樣式時，就會產生很多樂趣，並且桌面匯流排和 X 顯示器之間突然之間不再存在 1:1 的關係。更多的。單個使用者匯流排範圍的實例應用程序突然必須能夠同時與多個 X 顯示器通信。

gedit當人們嘗試通過 以超級使用者身份執行時，會發生進一步的歡鬧sudo，因為它要麼無法連接到每個使用者的桌面匯流排，要麼連接到錯誤的（超級使用者的）桌面匯流排。

有一個建議提供gedit一個命令行選項，使被呼叫的程序只是實際的編輯器應用程序，因此這對於環境變數gedit指向的編輯器很有用EDITOR（它不適用於許多常見的用法EDITOR，從crontab到git，當它立即退出時）。這個提議還沒有成為現實。

與此同時，人們有多種方式來獲得“輕量級文本編輯器”的第二個簡單實例，例如呼叫一個全新的桌面匯流排實例，專用於gedit呼叫dbus-run-session. 當然，這往往會在此私有匯流排上啟動其他 GNOME 桌面匯流排伺服器，因為它們依次由 呼叫gedit，使其根本不是“輕量級”的。

錦上添花的是，當您遵循此建議或類似建議並插入一個名為的 shell 函式時，該函式會立即從 shell 的作業列表中gedit刪除該程序。gedit不僅程序會迅速終止，因此您以後不會看到它，而且 shellkill甚至ps不會將其作為 shell 控制的作業進行監視。

進一步閱讀

• 應用程序/Gedit/NewSingleInstance。GNOME 維基。2013 年。
• “說明”。GApplication. GNOME 開發者的維基。
• https://stackoverflow.com/questions/7553452/
• Stefan Löffler (2011-05-04)。 從 nautilus 啟動時不重用正在執行的實例。錯誤 #777292。發射台。

引用自：https://unix.stackexchange.com/questions/323663