Chaining programs with pipe
gagsl-py2 at yahoo.com.ar
Tue Aug 28 06:07:03 CEST 2007
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>,
> 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.
More information about the Python-list