From: Zsban Ambrus <ambrus@...>
Date: 2004-04-26T17:16:08+09:00
Subject: ignores SIGPIPE, why ruby

Ruby ignores SIGPIPE.  In this mail, I'll argue against the usefulness of
this decision.

When you type something like

ruby -we 'n= 1; puts n+=1 while 1;' | head

then after the 10th line the puts function raises Errno::EPIPE (cause that's
what syscalls return when they raise an EPIPE signal) and ruby dies with an
ugly annoying message like

-e:1:in `write': Broken pipe (Errno::EPIPE)
        from -e:1:in `puts'
        from -e:1

I think that ruby should either silently die from the EPIPE signal (or else
raise an Errno::EPIPE exception that you can catch but if you don't catch it
ruby should just exit silently just like when you call Kernel.exit())

I belive that one of the biggest advantage of the UN*X-like systems is the
well-thought job-control scheme.  It works quite automatically: you can
redirect, suspend, resume, background etc a procaess, and everything works
fine even if the processes itself do not have any special support for it. 
This is especially true for simple processes that don't do anything special
with stdin and stdout just use them in cooked mode.

It would take nothing to implement this behaviour, as the OS kills ruby, so
ruby has to do nothing.  In the above example, you don't need an error
message, as you asked for "|head", so the os killing the process would be right
(and the shell not printing a message about what signal killed the process
on the left side on the pipeline is also right, note that when a process
dies from a signal, new shells usually report this with a short line).

What makes the situation even worse is that when I try to change tshi
behaiviour like this:

ruby -we 'trap "PIPE" do exit end; n= 1; puts n+=1 while 1;' | head

the trap function does not do anything, it does not catch the SIGPIPE. The
trap function should at least raise an error because it does not catch the
signal.  The only way to silence the error message is to wrap the whole
script in a begin .... rescue Errno::EPIPE; end;

If ruby would just leave the signal as is, you could probabyl still have the
old behaiviour by adding a trap for SIGPIPE that raises an Errno::EPIPE
exception, or just by ignoring the signal and supposing that the syscall
that raised SIGPIPE will get an EPIPE error anyway thus raise the exception.

What do you think of this idea?

ambrus