☰

进一步阅读

tag-icon • tag-icon shell process kill background-process gedit
进一步阅读

这是命令序列，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终止该进程？

答案1

这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服务器是否已在运行。如果您没有这样做，您就会处于塞维埃拉的境地，并想知道为什么您没有看到所描述的行为。如果有，您将处于自己的位置并看到该gedit过程几乎立即终止，特别是因为您没有为其提供任何命令行选项或参数以发送到“第一个实例”。因此，不再有具有该 ID 的进程。

正如上面提到的，当每次登录的桌面总线切换到每用户桌面总线的“新”样式时，就会产生很多乐趣，并且突然间桌面总线和 X 显示之间不再存在 1:1 的关系。更多的。单个用户总线范围的实例应用程序突然必须能够同时与多个 X 显示器通信。

当人们尝试gedit通过 以超级用户身份运行时sudo，会发生进一步的欢闹，因为它要么无法连接到每个用户的桌面总线，要么连接到错误的（超级用户的）桌面总线。

有人建议提供gedit一个命令行选项，使调用的进程只是实际的编辑器应用程序，因此这gedit将很有用，因为编辑器由环境变量指向（当它立即退出时，EDITOR它不适用于EDITOR, from crontabto的许多常见用法）。git这一提议尚未成为现实。

与此同时，人们可以通过各种方式获得“轻量级文本编辑器”的第二个简单实例，例如调用一个全新的桌面总线实例，该实例是gedit,的调用私有的dbus-run-session。当然，这往往会在该专用总线上启动其他 GNOME 桌面总线服务器，因为它们依次由 调用gedit，这使得它根本不是“轻量级”的。

锦上添花是当你跟随这个建议或者类似的方法并插入一个名为 的 shell 函数gedit，该函数立即gedit从 shell 的作业列表中删除该进程。该进程不仅会快速终止，以便您稍后不会使用kill或看到它ps，而且 shell 甚至不会将其作为 shell 控制的作业进行监视。

进一步阅读

答案2

抱歉地说，但这对我有用：

$ gedit&
[1] 9391
$ t=$! 
$ echo $t
9391
$ kill $t
[1]+  Terminated         gedit

ps -ef通过执行或检查进程是否仍然存在pidof gedit。如果是这样，你也可以这样做kill $(pidof gedit)

答案3

我已经尝试过以下代码并且它在脚本中有效，请尝试一下

     gedit&
     t=$! 
     echo $t
    #sleep 2
     kill -9 $t

相关内容