Chaining programs with pipe

Lawrence D'Oliveiro ldo at geek-central.gen.new_zealand
Tue Aug 28 01:11:32 EDT 2007


In message <mailman.51.1188274035.28954.python-list at python.org>, Gabriel
Genellina wrote:

> 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.

But I assumed you knew, since you were the one who used to term "foreigner"
to describe Grant Edwards' mystification at why things worked this way. So
in fact you are equally a "foreigner" to the way Windows works?

> 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.

But why should I need to do that? On Unix/Linux systems, there is no
distinction between "GUI" and "non-GUI" programs--_all_ processes can (and
usually do) have stdin, stdout and stderr. stderr is particularly important
for GUI programs, so the desktop environment typically captures this to a
file, commonly called ".xsession-errors". This is very useful when things
go wrong (programs crash etc), to see what error messages were reported.

Copying text messages from a file is somewhat easier than trying to capture
them from a screenshot.



More information about the Python-list mailing list