[Tutor] "standard output: Broken pipe"

[Michael Langford]

I think Alan is exaggerating the danger of signal handlers. They are *not*
dangerous at all, but you should know what each signal means before you
install a handler over its default, so you don't surprise yourself with
behavior. For instance, you can capture ctrl-C which usually send a SIGINT.
Python does this in the interactive shell, and prints out the words
"KeyboardInterrupt". You can send SIGTSTP (which means pause the program for
now, but let it be resumed later) with ctrl-Z. Python doesn't do this by
default on at least my linux 2.4.4 release, as you'll see the application
stop. But if you then type "fg", it will resume pythin by sending the
SIGCONT signal.

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)"

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.

Here is what all the signals available do:
http://www.delorie.com/gnu/docs/glibc/libc_471.html

Just learn what a signal does before you mess with it, and remember to keep
your signal handlers respectful of the original intent of the signal. If
you're writing any serious program that *must* shutdown cleanly, signal
handling is an essential item to put into your program.

                --Michael

On 10/19/07, James <jtp at nc.rr.com> wrote:
>
> Hi,
>
> I have a snippet of code in a Python script I'm whipping up that's
> causing a not-so-pretty output.  Here's the code:
>
> subprocess.call( "yes '' | make oldconfig" , shell=True )
>
> When I run this code, Python loyally executes the command, and then I
> see the following error on my console:
>
> -----
>
> yes: standard output: Broken pipe
> yes: write error
>
> -----
>
> I did some Googling and I believe found the reason for this error
> ("yes" executes forever, and complains when Python kills the process
> off).  However, I'd like to figure out a way to get rid of the error
> (or hide it) so that it's not visible to the person running the
> script (it's not the prettiest thing to see scroll by your screen :)).
>
> Thoughts / ideas?
>
> Thanks!
> .james
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>



-- 
Michael Langford
Phone: 404-386-0495
Consulting: http://www.TierOneDesign.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20071021/efd0052e/attachment.htm