This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients asvetlov, jnoller, kristjan.jonsson, loewis, ocean-city
Date 2009-04-02.09:46:09
SpamBayes Score 2.1424862e-11
Marked as misclassified No
Message-id <1238665571.66.0.863081444621.issue5619@psf.upfronthosting.co.za>
In-reply-to
Content
Correction, Martin, just to be pedantic:
FILE * fp = _fdopen(fh)
_close(fh)
... leaving an automatic fclose(fp) at process exit to fail.

Look, I understand that buildbot can't put up dialogue boxes.  And as 
frustrating as it may be, it appears that Windows can't cause dialogue 
box functions (such as MessageBox()) to simply 'fail' when run 
unattended, e.g. as a Service.  In fact, if the service isn't allowed 
to interact with the desktop, these functions just hang.  So, we need 
to disable them.

But what I'm trying to say, in the case of subprocess, is that this 
disablement should be done _early_ then.  Not as a last resort before 
exit.  Turning them on before exit caught this particular problem, 
which needed fixing anyway, but it won't cause other strange things 
that might happen _during_ the executionof the subprocess code.

Since you object to a command line parameter, how about an environment 
variable? PYTHONUNATTENDED could be used in the library startup to turn 
off any conceivable dialogue boxes and would be passed on to child 
processes.  This could then also easily be added in the build slave 
config script:  sys.env[PYTHONUNATTENDED] = "1"
History
Date User Action Args
2009-04-02 09:46:11kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis, ocean-city, jnoller, asvetlov
2009-04-02 09:46:11kristjan.jonssonsetmessageid: <1238665571.66.0.863081444621.issue5619@psf.upfronthosting.co.za>
2009-04-02 09:46:10kristjan.jonssonlinkissue5619 messages
2009-04-02 09:46:09kristjan.jonssoncreate