Thanks for the response, Alan. Given this explanation, it's probably not a great idea to use signal.signal() then. ;)
Any other thoughts? I've tried about redirecting my output using subprocess.Popen( ... , stdout=*something* ), but I haven't had much luck. The error still appears. Or should I be redirecting the "stderr" instead of "stdout"? Any ideas on how to use subprocess.Popen() to make this lovely little error disappear? Thanks! .james On Oct 20, 2007, at 7:34 PM, Alan Gauld wrote: > "James" <[EMAIL PROTECTED]> wrote > >> signal.signal(signal.SIGPIPE, signal.SIG_DFL) >> >> Before the snippet of code I included in my original e-mail >> (subprocess.call( "yes '' | make oldconfig" , shell=True )) got rid >> of the error. I can't seem to figure out precisely what the >> signal.signal() function does (as shown above). > > A signal is basically an interrupt. Its raised by the OS. > signal.signal catches the named signal(s) and handles it. > The default handler appears to just swallow the signal > silently. > > Its a bit like, in Python, doing > > try: someFunc() > except SomeError: pass > > The except clause catches the error but ignores it. > > signal.signal is doing much the same but at the OS level. > > My personal approach is to avoid using signal to trap > and ignore signals since they can be needed by other > processes running concurrently on the machine, > but in this case it appears harmless. But in general, > any approach which could interfere in unpredicable > ways with other processes on the computer is a > risky strategy IMHO. > > HTH, > > Alan G. > > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
