Chaining programs with pipe

[Gabriel Genellina]

On 28 ago, 02:11, Lawrence D'Oliveiro <l... at geek-
central.gen.new_zealand> wrote:
> In message <mailman.51.1188274035.28954.python-l... at python.org>, Gabriel
>
>
>
>
>
> Genellina wrote:
> > En Mon, 27 Aug 2007 05:35:51 -0300, Lawrence D'Oliveiro
> > <l... at geek-central.gen.new_zealand> escribi?:
>
> >> In message <1187795716.083417.299... 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?

I do know how to create console applications, but that is not
relevant. If a wxPython application crashes when something is written
to stdout/stderr, this is either the programmer fault or the framework
fault, *not* Windows fault. As I said, a Tk application doesn't crash
in those circunstances, by example. Many other applications don't
crash either. The default behavior for a GUI application is to simply
discard the output.
(And my comment was not referring to that specific problem - this
thread is too broad now).

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

Because the distinction IS relevant on Windows?

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

On Windows, windowed applications (as opposed to console applications)
start with no stdin/stdout/stderr by default. The application
developer can modify that if desired, of course - I've menctioned some
ways to do that.
This fact simply means that those OS's *are* different - most of the
time one can ignore the differences, but not always. Neither of them
is doing the absolute "Right Thing".

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

There are plenty of logging systems to choose. Redirecting stderr to a
file can be done either by the app itself or by its caller (for a well
behaved application, of course; the crashing wxPython app menctioned
earlier appears not to be one of those).

--
Gabriel Genellina