Traping output from os.system

[David Bolen]

"Mark Hammond" <MarkH at ActiveState.com> writes:

> > Any chance that a future update to the extensions will be able to
> > return the result code of the child process on a close(), as
> > os.popen() does?
> 
> Unlikely that Bill or I will look into this.  The problem is that the file
> object doesnt know anything about the popen child process.

Hmm, yeah, but couldn't the win32popen module just pass a different
close routine (to PyFile_FromFile()) and then keep track of which file
handles were for which pipe?  True, it would have to manage that
mapping, but could probably just use an internal dictionary for it :-)
(Note I haven't actually tried this myself yet - just guessing from a
few glances at the source)

Ah, well - unfortunately exit codes are key for me, since the gate
decisions.  So I'll just keep valid consoles around for the moment :-)

> Personally, I would prefer to _remove_ win32pipe.popen's implementation,
> and re-write it in pure-python using the raw win32pipe functions - just to
> prove we can :-) And also so it would be easier to hack to do this sort of
> stuff, or cloned for "custom" requirements, etc.

Makes sense - I may try that at the point where I need to get rid of
thge consoles, although I'm definitely targeted at NT, so I get to
avoid all the Win95/98 ugliness I keep hearing about :-)

Doing it this way would probably make it easier to return an object
that looked like a file object (although it wouldn't really be the
actual type) but knew enough about how to access the child process
during the close() operation.

Thanks.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/