Python - SIGPIPE handled bug

[Randall Hopper]

Dieter Maurer:
 |Hallo Randall

Hi.  Thanks for the reply.

 |>   ------------------------------------------------------------------------
 |>     > python -c "for i in xrange(1000): print 'Some output'" | head -2
 |>     Some output
 |>     Some output
 |>     Traceback (innermost last):
 |>       File "<string>", line 1, in ?
 |>     IOError: [Errno 32] Broken pipe
 |>   ------------------------------------------------------------------------
 |> 
 |> python getting a SIGPIPE is appropriate behavior.  "Whether" it gets a
 |> SIGPIPE is up to the shell, in UNIX:
 |
 |It seems, that in your case Python does not get a SIGPIPE but
 |the "write" returns "-1" and "errno==EPIPE".
 |
 |According to POSIX, this is the behaviour, if SIGPIPE is not handled
 |by the default action:
 |       EPIPE  fd is connected to a pipe or socket  whose  reading
 |              end  is closed.  When this happens the writing pro­
 |              cess will receive a SIGPIPE signal; if it  catches,
 |              blocks or ignores this the error EPIPE is returned.
 |
 |The SIGPIPE handling under Python 1.5.2/Linux 2/Bash seems to be
 |to ignore the signal (possibly inherited from the bash!).

I'm getting this behavior with tcsh 6.04.00 on SGI IRIX, which delivers
SIGPIPE.

Looking at the code, the problem is that Python resets this signal so that
it is ignored (see pythonrun.c), deferring the handling until the failed
read() gets EPIPE as you said.  This is why an otherwise quiet-exit
scenario (delivery of SIGPIPE) is being transformed into a noisy error
condition in Python.

What's at issue is whether every Python app meant to be piped into another
program has to munge exceptions or signals to avoid emitting bogus errors.
Take for example:

    python -c "for i in xrange(100000): print 'Lots of output'" | more

If we quit our pager before scrolling to the bottom of the python-generated
stream, is that an error?  Well no, of course not.  So as with default
delivery of SIGPIPE (which calls _exit(2), Python IMO shouldn't generate
errors for this situation.

-- 
Randall Hopper
aa8vb at yahoo.com