☰

通过“xdg-open”从子 shell 启动程序而不阻塞

tag-icon • tag-icon terminal process zsh subshell xdg-open
通过“xdg-open”从子 shell 启动程序而不阻塞

我注意到，xdg-open从子 shell 调用将可靠地阻塞，直到启动的进程关闭。我怀疑这可能是有原因的，但我不确定为什么。例如，xdg-open直接从命令行调用时启动 Nautilus 不会阻塞：

xdg-open ~/dir ; echo foo              # doesn't block

但从子 shell 调用 xdg-open 将可靠地阻止终端

var=$(xdg-open ~/dir ; echo foo)       # blocks

{ xdg-open ~/dir ; echo foo ; } | cat  # blocks.

我的理解是，xdg-open将启动的进程与 shell 会话分离，使其不再是子进程。因此，我希望这与例如在子 shell 中调用不同，sleep 1 &对于子 shell 来说，终止子 shell 将阻塞直到所有子进程完成为止似乎是合理的，即

var=$(sleep 1 & echo foo)      # also blocks, but understandable.

但如果xdg-open正在分离进程，是什么导致子 shell 等待呢？

在什么可能（？）是部分答案中，我注意到运行

{ xdg-open <file> ; ps ; } | cat

显示根据 启动的程序<file>，那些阻止的程序也是那些将 tty 作为其控制终端的程序。这就引出了一个问题：为什么会发生这种情况，为什么这种情况只发生在子 shell 中，以及最终从终端启动桌面进程并完全可靠地与其分离的好方法是什么？

编辑：修复bash.

答案1

首先，在你的例子中， 

var=$(sleep 1 & ; echo foo)

不应该在 中工作bash，因为&已经用作行尾。
（-bash：命令替换：第 1 行：意外标记“;”附近的语法错误）


尝试

var=$(sleep 1 & echo foo) # no ';' !!

(回显 $var: foo)

以我的理解，一个简单的 

xdg-open <something> & # optional: echo foo

应该可以解决这个问题，无论是在子 shell 中还是在外部。

相关内容