[Tutor] "standard output: Broken pipe"

[Eric Brunson]

Martin Walsh wrote:
> Michael Langford wrote:
>   
>> This signal is not something you care about. All SIGPIPE means is that
>> the source of the signal found itself writing to a pipe with no sender.
>> Your line  "signal.signal(signal.SIGPIPE, signal.SIG_DFL)" means use the
>> default signal handler for SIGPIPE. While this works (as the default
>> signal handler is the ignore handler, you actually want to explicitly
>> use the IGN handler, which will just ignore the signal.  To do this use
>> " signal.signal(signal.SIGPIPE, signal.SIG_IGN)"
>>     
>
> I don't think this is quite right, but please correct me if I'm
> misinformed, or just plain wrong. :)
>
> Using "signal.signal(signal.SIGPIPE, signal.SIG_IGN)" (kernel 2.6.20,
> bash 3.2, python2.5) 

I just noticed something, Martin.  subprocess.call() on my machine is 
calling the shell as /bin/sh, not /bin/bash.  This changes the behavior 
of bash, possibly causing it to print the message.  (Anyone else think 
that subprocess should honor the SHELL environment variable?)

I can't get any invocation of the commands to generate the error 
message, only when it's called from python does the ouput get 
generated.  Quite interesting, I'd love to know the explanation for that.

Still poking at it, though.

> still produces a broken pipe with the following code:
>
> import signal
> import subprocess as sp
> signal.signal(signal.SIGPIPE, signal.SIG_IGN)
> sp.call("yes 'Spam' | head -n 10", shell=True)
>
> My understanding is that python is *already* overriding with a SIG_IGN
> for SIGPIPE, and child processes inherit, which explains the difference
> in behavior when running the command from a shell terminal (on my system
> at least) vs. a python subprocess object. This is referenced in the
> signal module docs (http://docs.python.org/lib/module-signal.html), and
> appears to be confirmed in the python2.5 source (pythonrun.c).
>
> Also, while it is unclear in the signal module docs (to me at least), my
> take on the use of SIG_DFL is to revert (if necessary) to the *system*
> default action for a signal, not the python default (which is SIG_IGN).
> Again, this is my interpretation based on a very minimal understanding
> -- please correct me if I'm wrong.
>
>   
>> The reason you don't see the error on the shell is that the bash shell
>> does not print notifications of SIGPIPE when running interactively. If
>> you instead copied your snippit of scripting into a shell script then
>> called that with "bash foo.sh", you'd see the exact same broken pipe.
>>     
>
> Ok, this isn't true on my system either -- I don't get a broken pipe
> from a bash script. So, perhaps this is due to the differences in our
> kernel or bash versions. The version of bash on my system (3.2) has a
> DONT_REPORT_SIGPIPE define that is honored in both interactive and
> non-interactive shells. Presumably, this is how the ubuntu binary was
> compiled.
>
>   
>> Here is what all the signals available do:
>> http://www.delorie.com/gnu/docs/glibc/libc_471.html
>>
>>     
>
> Excellent link, thanks! IMO, the signal manpage ('man signal') is also a
> good resource. On my system, it contains a table of default actions.
> Here's what it has to say about SIGPIPE:
>
> """
> Signal     Value     Action   Comment
> -------------------------------------
> SIGPIPE      13       Term    Broken pipe: write to pipe with no readers
> """
>
> and, the 'Term' action is defined as follows:
>
> """
> Term   Default action is to terminate the process.
> """
>
> Thanks!
> Marty
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>