我正在查看，这是启动程序的dmenu_run默认脚本，并看到其中的这一部分引起了我的兴趣：dmenu
[..other stuff..] | dmenu | sh &
所以我做了一些测试。
先决条件信息
我正在运行 GNU/Linux。
sh在dash我的系统上。我的登录外壳是bash.
st和xterm是终端模拟器。
替换为测试期间创建的窗口$XTERMPID的 PID 。xterm您可以使用xprop它来获取它。
xterm似乎不会产生日志输出，除非出现问题。您可以将其替换为另一个实际生成日志输出以执行该部分测试的程序。
测试
场景#1 - 运行xterm（或xterm &）st：
可以看到xterm登录了st。
pstree -s $XTERMPID输出：systemd───sddm───sddm-helper───i3───st───bash───xterm───bash
关闭后st
xterm被杀。
场景#2 - 运行echo xterm | sh（或echo xterm | sh &）于st：
您可以xterm在 中看到日志st。
pstree -s $XTERMPID输出：systemd───sddm───sddm-helper───i3───st───bash───sh───xterm───bash
关闭后st：
xterm以某种方式幸存下来（这是我不明白的部分。不是所有的孩子都应该被杀吗？）
pstree -s $XTERMPID输出：systemd───xterm───bash
场景 #3 - 运行setsid -f xterm于st：
你不能请参阅xterm中的日志st。
pstree -s $XTERMPID输出：systemd───xterm───bash
关闭后st：
与预期一致。
场景#4 - 运行echo "echo xterm | sh" | sh（或echo "echo xterm | sh &" | sh &）于st：
你可以仍然查看xterm日志st，但xterm它不再是 的子项st。我也不明白这个。
pstree -s $XTERMPID输出：systemd───sh───xterm───bash
关闭后st：
与预期一致。
问题：
- 当
st在场景 #2 中被杀死时，为什么xterm当其父级sh被杀死时不会被杀死？ - 是它
st还是内核害死了孩子们？ - 它只会杀死直系孩子吗？那么为什么当你关闭终端时，在终端 shell 中运行的程序就会死掉呢？
- 为什么在场景 #4 中，即使不是 的子项，
xterm仍显示的输出？这是如何运作的？stxtermst
测试#2
(echo "echo xterm | sh &" | sh &) >/dev/null 2>&1从i3blocks脚本运行
一直有效，直到您重新启动 i3i3-msg restart或 Super+Shift+R。窗口仍然存在，但实际进程将被终止，窗口将充满黑色。
请参阅此错误报告以获取更多详细信息：https://github.com/vivien/i3blocks/issues/483
setsid -f xterm从i3blocks脚本运行
工作没有问题
问题：
- 有什么额外的事情可以
setsid -f做而双管道sh却不能做？当它们看起来与 相同时，为什么setsid -f在该i3blocks场景中起作用而不是在另一个场景中起作用pstree？ setsid似乎是一个仅限 Linux 的命令，如何仅使用 POSIX 兼容的 shell 和 coreutils 复制它？- 如果进程死亡，为什么窗口仍然可见？