[Tutor] "standard output: Broken pipe"

[James]

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" <jtp at nc.rr.com> 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 at python.org
> http://mail.python.org/mailman/listinfo/tutor