破管不再结束程序？

Question

当您管道两个进程并在管道的"输出"处终止该进程时,第一个进程用于接收"Broken Pipe"信号,该信号通常也会终止它.比如跑步

$> do_something_intensive | less

然后退出较少用于立即返回到SuSE8或以前版本的响应shell.当我今天尝试时,do_something_intensive显然仍在运行,直到我手动杀死它.似乎某些事情发生了变化(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)

当少被杀害.我可以肯定在我的程序中编写一个信号处理程序并确保它终止,但我更需要一些环境变量或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）。我认为结案了。