From: Grant E. <gr...@vi...> - 2008-01-22 21:49:50
|
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? -- Grant Edwards grante Yow! The PILLSBURY DOUGHBOY at is CRYING for an END to visi.com BURT REYNOLDS movies!! |
From: Thomas H. <th...@ct...> - 2008-01-23 10:50:05
|
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. Could be changed by hacking the file boot_common.py somewhere is Lib/site-packages/py2exe or by reassining sys.stdout on your script. But that doesn't mean stdout from a GUI program will appear on the console; you will get an exception after the stdout buffer is full. Thomas |
From: Grant E. <gr...@vi...> - 2008-01-23 16:11:36
|
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. > Could be changed by hacking the file boot_common.py somewhere > is Lib/site-packages/py2exe or by reassining sys.stdout on > your script. But that doesn't mean stdout from a GUI program > will appear on the console; you will get an exception after > the stdout buffer is full. Under XP, is there any way to get ahold of a file handle that will write to the invoking terminal so that I can write diagnostic stuff to the console as I did under 2K and 9x? -- Grant Edwards grante Yow! RHAPSODY in Glue! at visi.com |
From: Thomas H. <th...@ct...> - 2008-01-23 17:10:40
|
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: C:\test>type test.py import sys print "Hello from", sys.executable C:\test>c:\python25\python test.py Hello from c:\python25\python.exe C:\test>c:\python25\pythonw test.py C:\test> As you can see, pythonW.exe doesn't print anything to the console. >> Could be changed by hacking the file boot_common.py somewhere >> is Lib/site-packages/py2exe or by reassining sys.stdout on >> your script. But that doesn't mean stdout from a GUI program >> will appear on the console; you will get an exception after >> the stdout buffer is full. > > Under XP, is there any way to get ahold of a file handle that > will write to the invoking terminal so that I can write > diagnostic stuff to the console as I did under 2K and 9x? > AFAIK, GUI programs start with the three standard handles closed; probably because there is no connection to the invoking terminal or whatever. 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. Thomas |
From: Grant E. <gr...@vi...> - 2008-01-23 18:55:28
|
On 2008-01-23, Daniel Pryden <da...@pr...> wrote: >> So a windows _executable_ is either a windows program which >> can't have a stdin/stdout/stderr even when started from a >> console, or a console program which _must_ have a >> stdin/stdout/stderr even it never uses them? > > The problem actually lies with the Windows SDK, which (by > convention, but very entrenched convention) uses an entrypoint > called WinMain() instead of the standard C main(). One of the > arguments to WinMain() is a HINSTANCE handle to your > application, which you will need if you create any windows > (since the OS needs to know which process owns the given > windows). Since WinMain() and main() define different > arguments, only one or the other gets called at startup, > depending on the EXE -- (and that's where my knowledge of how > Windows works gets fuzzy). I see: you provide a WinMain() entry point if you want an hInstance handle which is required to use the Windowing API. What doesn't make sens (to me) is why that has anything to do with whether or not the stdio handles are connected to anything. The prohibition against using stdin/out/err in a WinMain() app seems completely pointless and arbitrary (at least to a Unix native). > Here's a link: http://msdn2.microsoft.com/en-us/library/ms633559(VS.85).aspx Thanks. > Probably an easier solution would be to replace all your > stdout/stderr writes with something like the logging module. Yup, that's pretty much what I've done. -- Grant Edwards grante Yow! I wonder if there's at anything GOOD on tonight? visi.com |
From: Grant E. <gr...@vi...> - 2008-01-23 16:44:14
|
On 2008-01-23, Grant Edwards <gr...@vi...> wrote: > 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 just ran the program "normally" from the command line (e.g. python foo.py), and it works fine. It seems to be something that py2exe is doing: it's going to special effort to replace stdout with some sort of bit-sink. Does it save the old value of stdout somehwere so that I can put it back? >> Could be changed by hacking the file boot_common.py somewhere >> is Lib/site-packages/py2exe or by reassining sys.stdout on >> your script. But that doesn't mean stdout from a GUI program >> will appear on the console; you will get an exception after >> the stdout buffer is full. > > Under XP, is there any way to get ahold of a file handle that > will write to the invoking terminal so that I can write > diagnostic stuff to the console as I did under 2K and 9x? Better yet, can py2exe be told to just leave stdout alone? -- Grant Edwards grante Yow! MMM-MM!! So THIS is at BIO-NEBULATION! visi.com |
From: Fuzzyman <fuz...@vo...> - 2008-01-23 17:02:25
|
Grant Edwards wrote: >On 2008-01-23, Grant Edwards <gr...@vi...> wrote: > > >>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 just ran the program "normally" from the command line (e.g. >python foo.py), > Try "pythonw foo.py" and see what happens. This is standard Windows behaviour for 'windows' applications and 'console' applications. A windows application detatches from a console it was launched from - so I *doubt* that it will be easy to get a handle back to that pipe, even doing win32 magic. I may be wrong though. Michael Foord http://www.manning.com/foord > and it works fine. It seems to be something >that py2exe is doing: it's going to special effort to replace >stdout with some sort of bit-sink. Does it save the old value >of stdout somehwere so that I can put it back? > > > >>>Could be changed by hacking the file boot_common.py somewhere >>>is Lib/site-packages/py2exe or by reassining sys.stdout on >>>your script. But that doesn't mean stdout from a GUI program >>>will appear on the console; you will get an exception after >>>the stdout buffer is full. >>> >>> >>Under XP, is there any way to get ahold of a file handle that >>will write to the invoking terminal so that I can write >>diagnostic stuff to the console as I did under 2K and 9x? >> >> > >Better yet, can py2exe be told to just leave stdout alone? > > > |
From: Grant E. <gr...@vi...> - 2008-01-23 17:24:30
|
On 2008-01-23, Fuzzyman <fuz...@vo...> wrote: >>I just ran the program "normally" from the command line (e.g. >>python foo.py), > > Try "pythonw foo.py" and see what happens. Exactly nothing. > This is standard Windows behaviour for 'windows' applications > and 'console' applications. So a windows _executable_ is either a windows program which can't have a stdin/stdout/stderr even when started from a console, or a console program which _must_ have a stdin/stdout/stderr even it never uses them? > A windows application detatches from a console it was launched > from - so I *doubt* that it will be easy to get a handle back > to that pipe, even doing win32 magic. I may be wrong though. Once again, I'm completely amazed by the mind-numbing level of brokenness in windows. Why should there be any difference at all when it comes to stdio behavior between a "windows" application and a "console" application? Either a process has stdin/out/err file-handles connected to something when its started or it doesn't. What's it got to do with whether it's a "windows" application or a "console" application? One presumes that a "windows" application is one that uses the windowing API, and a console app is one that doesn't. Shouldn't the presence or absence of stdin/stdout/stderr be dependent on how/where the program was started and not a characteristic of the program itself? Does absolutely _every_ feature in windows have bizarre side effects on and connections to all other (even unrelated) features? Just when I didn't think I couldn't despise windows any more... -- Grant Edwards grante Yow! Alright, you!! at Imitate a WOUNDED SEAL visi.com pleading for a PARKING SPACE!! |
From: Daniel P. <da...@pr...> - 2008-01-23 18:22:42
|
Grant Edwards wrote: > So a windows _executable_ is either a windows program which > can't have a stdin/stdout/stderr even when started from a > console, or a console program which _must_ have a > stdin/stdout/stderr even it never uses them? The problem actually lies with the Windows SDK, which (by convention, but very entrenched convention) uses an entrypoint called WinMain() instead of the standard C main(). One of the arguments to WinMain() is a HINSTANCE handle to your application, which you will need if you create any windows (since the OS needs to know which process owns the given windows). Since WinMain() and main() define different arguments, only one or the other gets called at startup, depending on the EXE -- (and that's where my knowledge of how Windows works gets fuzzy). Here's a link: http://msdn2.microsoft.com/en-us/library/ms633559(VS.85).aspx So... why can't you get the HINSTANCE some other way? I don't know, but I've never seen an example of it being done. I suppose with some deep C & Win32 wizardry it might be possible to build an executable that bootstraps differently depending on how it was invoked, but I've yet to see a program that does that. Probably an easier solution would be to replace all your stdout/stderr writes with something like the logging module. - Daniel. |
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?? |
From: Thomas H. <th...@ct...> - 2008-01-23 18:10:03
|
Grant Edwards schrieb: > 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. I cannot explain that to you. And there are large books about this stuff ;-). > 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? > Well, the standard behaviour of a py2exe GUI program is to silently swallow all output to stdout (for me, this is coming from debugging print statements that I forgot to remove), and to append the output that goes to stderr to a logfile named like the exe-file + ".log". When the process finishes, and something has been written to this error-logfile, a messagebox pops up informing the user about these errors. This behaviour is defined (did I say this before?) in the script Lib/site-packages/boot_common.py which is executed before your own script starts. You can either hack this script, or assign sys.stdout and sys.stderr to something else in your own script. Thomas |