On 2008-01-23, Thomas Heller <theller@...> wrote:
> Grant Edwards schrieb:
>> On 2008-01-23, Thomas Heller <theller@...> wrote:
>>> Grant Edwards schrieb:
>>>> When I run one of my bundled .exe files from the command line,
>>>> I don't see any output from print commands? Where is stdout
>>> If you built with 'windows=[...]' instead of 'console=[...]'
>>> then stdout goes to a null sink.
>> So a "windows" program doesn't have a stdout even when it's
>> being run from a terminal? That must be new in XP -- I'm
>> pretty sure stdout used to work in Win2K and Win9x.
> I do not know if this is new in XP or not, but python.exe vs. pythonW.exe
> shows the same behaviour:
You're right. After messing about some more, I don't think it
was 2K vs. XP: it's a python vs. pythonw difference.
> AFAIK, GUI programs start with the three standard handles
> closed; probably because there is no connection to the
> invoking terminal or whatever.
I always presumed that a "GUI" program was simply one that
called the windowing API, but apparently there's some innate
property of an .exe that makes it a "GUI" program regardless
of whether it uses the windowing API or not.
I had also presumed that programs started from a console had
stdin/stderr/stdout, and programs started from windows explorer
didn't regardless of whether they used the windowing API or
It seems I was wrong on both counts. I still don't see any
reason why GUI and stdio behavior aren't completely orthogonal,
but the list of things in Windows that don't make sense to me
would fill a very large book.
> You may be able to play some tricks with AllocConsole(), see
> MSDN for that. I never had the need for this and have no
> experience with that.
I'll figure out some other work-around (e.g. a flag that
enables status logging). It's certainly not worth trying to
warp my brain into thinking like the designers of Windows. ;)
The hope was that in the case where the program was started
from the console, stdout would be connected to that console
(hey, it makes sense to Unix guy), and I could just write
status messages to stdout. Under normal circumstances (program
not started from a console) the status stuff being written to
stdout would just go into a black-hole.
I also tried just writing to stderr instead of stdout, but that
had several undesired effects: on some systems, it pops up a
window (this is just some diagnostic and status stuff that
normal uses don't need/want to see 99% of the time). On other
systems, it appends to a log file that never gets deleted or
truncated. In the latter case, it also seems to pop up a
dialog window telling the user that errors occurred even though
I'm pretty sure the program exited with a success status. Is
writing to stderr what triggers that dialog?
Grant Edwards grante Yow! Do you have exactly
at what I want in a plaid
visi.com poindexter bar bat??