From: Grant E. <gr...@vi...> - 2008-01-23 17:43:38
|
On 2008-01-23, Thomas Heller <th...@ct...> wrote: > Grant Edwards schrieb: >> On 2008-01-23, Thomas Heller <th...@ct...> 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 >>>> going? >>> >>> 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 not. 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?? |