破损的管道不再终止程序？

Question

当您通过管道传输两个进程并在管道的“输出”处终止一个进程时，第一个进程用于接收“损坏的管道”信号，该信号通常也会终止它。 例如，在 SuSE8 或以前的版本上，运行

$> do_something_intensive | less

然后退出 less 用于立即返回到响应式 shell。 当我今天尝试时，do_something_intense 显然仍在运行，直到我手动终止它。 似乎有些东西发生了变化（glib？shell？），使程序忽略“损坏的管道”......

你们中的任何人对此有提示吗？ 如何恢复以前的行为？ 为什么它被改变了（或者为什么它总是存在多种语义）？

编辑：进一步的测试（使用 strace）显示生成了“SIGPIPE”，但程序并未中断。 一个简单的事情

#include <stdio.h>
int main() 
{
   while(1) printf("dumb test\n");
   exit(0);
}

将会继续下去

--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(1, "dumb test\ndumb test\ndumb test\ndu"..., 1024) = -1 EPIPE (Broken pipe)

当 less 被杀死时， 。 我肯定可以在我的程序中编写一个信号处理程序并确保它终止，但我更多的是寻找一些环境变量或 shell 选项来强制程序在 SIGPIPE 上终止

再次编辑：看起来是一个特定于 tcsh 的问题（bash 可以正确处理它）并且依赖于终端（Eterm 0.9.4）

Answer 1

“做一些密集的事情”有改变吗？

正如丹尼尔所提到的，SIGPIPE 不是一个神奇的“你的管道消失了”信号，而是一个“很好的尝试，你不能再读/写那个管道”信号。

如果您可以控制“做一些密集的事情”，您可以更改它以在旋转时写出一些“进度指示器”输出。 这将及时引发 SIGPIPE。

Answer 2

感谢您的建议，解决方案越来越接近...

根据 tcsh 的联机帮助页，“非登录 shell 继承了其父级的终止行为。其他信号具有 shell 从其父级继承的值。”

这表明我的终端实际上是问题的根源...如果它忽略了SIGPIPE，shell本身也会忽略SIGPIPE...

编辑：我有明确的答案确认该问题仅在 Eterm+tcsh 中出现，并在 Eterm 源代码中发现可疑的缺失信号（SIGPIPE、SIG_DFL）。 我认为结案了。

Answer 3

好吧，如果在读取器离开后尝试写入管道，则会生成 SIGPIPE 信号。 应用程序有能力捕获此信号，但如果没有捕获到，则进程将被终止。

在调用进程尝试写入之前，不会生成 SIGPIPE，因此如果没有更多输出，则不会生成它。