On 28 ago, 02:11, Lawrence D'Oliveiro <[EMAIL PROTECTED] central.gen.new_zealand> wrote: > In message <[EMAIL PROTECTED]>, Gabriel > > > > > > Genellina wrote: > > En Mon, 27 Aug 2007 05:35:51 -0300, Lawrence D'Oliveiro > > <[EMAIL PROTECTED]> escribi?: > > >> In message <[EMAIL PROTECTED]>, > >> Gabriel Genellina wrote: > > >>> On 22 ago, 11:08, Grant Edwards <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
