Home/ Questions/Q 46667
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T16:00:06+00:00

When you pipe two process and kill the one at the output of the

  • 0

When you pipe two process and kill the one at the ‘output’ of the pipe, the first process used to receive the ‘Broken Pipe’ signal, which usually terminated it aswell. E.g. running

$> do_something_intensive | less

and then exiting less used to return you immediately to a responsive shell, on a SuSE8 or former releases. when i’m trying that today, do_something_intensive is obviously still running until i kill it manually. It seems that something has changed (glib ? shell ?) that makes program ignore ‘broken pipes’ …

Anyone of you has hints on this ? how to restore the former behaviour ? why it has been changed (or why it always existed multiple semantics) ?

edit : further tests (using strace) reveal that ‘SIGPIPE’ is generated, but that the program is not interrupted. A simple

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

will go on with an endless

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

when less is killed. I could for sure program a signal handler in my program and ensure it terminates, but i’m more looking for some environment variable or a shell option that would force programs to terminate on SIGPIPE

edit again: it seems to be a tcsh-specific issue (bash handles it properly) and terminal-dependent (Eterm 0.9.4)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Thanks for your advices, the solution is getting closer…

    According to the manpage of tcsh, ‘non-login shells inherit the terminate behavior from their parents. Other signals have the values which the shell inherited from its parent.’

    Which suggest my terminal is actually the root of the problem … if it ignored SIGPIPE, the shell itself will ignore SIGPIPE as well …

    edit: i have the definitive confirmation that the problem only arise with Eterm+tcsh and found a suspiciously missing signal(SIGPIPE,SIG_DFL) in Eterm source code. I think that close the case.

    • 0