Chaining programs with pipe

[Gabriel Genellina]

En Mon, 27 Aug 2007 05:35:51 -0300, Lawrence D'Oliveiro  
<ldo at geek-central.gen.new_zealand> escribi�:

> In message <1187795716.083417.299540 at q4g2000prc.googlegroups.com>,  
> Gabriel
> Genellina wrote:
>
>> On 22 ago, 11:08, Grant Edwards <gra... at visi.com> wrote:
>>
>>> but I'm a Unix guy who occasionally tries
>>> to ship a Windows version of a Python app: the concept of a
>>> process defaulting to having a stderr or stdout that wasn't
>>> writable was utterly foreign to me.
>>
>> Ah, that explains your previous post telling that things on Windows
>> don't work as they "should". They work, but not necesarily as a
>> "foreigner" would expect.
>
> So what's the good reason for Windows having unusable defaults for stderr
> and stdout, then?

You should ask the wxPython/wxWidgets guys why they choose to do things  
that way. Perhaps it's just an option that should be turned on. I'm not a  
wx guru. Tk programs don't have that problem, by example: you have a GUI  
*and* a console, if you want. A simple print statement with no console  
just goes into void space - no error, no crash, no GPF...
You get what you ask for: if you pass /SUBSYSTEM:WINDOWS as an option to  
the linker (or put equivalent flags in the executable) you don't get a  
console by default. That's fine for most GUI programs that don't use  
stdout/stderr. If you want a console, create one using AllocConsole. Or do  
that on the parent process, and let the children inherit it (as when  
running the application from the command line, as opposed to double  
clicking an icon). Or link with /SUBSYSTEM:CONSOLE. Or use  
GetStdHandle/SetStdHandle inside the app to redirect STD_OUTPUT_HANDLE etc.

-- 
Gabriel Genellina