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 <[EMAIL PROTECTED]> 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@python.org > http://mail.python.org/mailman/listinfo/tutor > -- Michael Langford Phone: 404-386-0495 Consulting: http://www.TierOneDesign.com/
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
