[Python-Dev] FW: Fixing os.popen on Win32 => is the win32pipe stuff
going to be adopted?
James C. Ahlstrom
Thu, 09 Mar 2000 10:45:54 -0500
Tim Peters wrote:
> I had another take on all this, which I'll now share <wink> since nobody
> seems inclined to fold in the Win32 popen: perhaps os.popen should not be
> supported at all under Windows!
> The current function is a mystery wrapped in an enigma -- sometimes it
> works, sometimes it doesn't, and I've never been able to outguess which one
> will obtain (there's more to it than just whether a console window is
> attached). If it's not reliable (it's not), and we can't document the
> conditions under which it can be used safely (I can't), Python shouldn't
> expose it.
OK, I admit I don't understand this either, but here goes...
It looks like Python popen() uses the Windows _popen() function.
The _popen() docs say that it creates a spawned copy of the command
processor (shell) with the given string argument. It further states
it does NOT work in a Windows program and ONLY works when called from a
Windows Console program.
From this I assume that popen() works from python.exe (it is a Console
app) if the command can be directly executed by the shell (like "dir"),
if the command starts a Console Windows application. It can't work when
starting a regular Windows program because those don't have a stdin nor
stdout. But Console apps do have stdin and stdout, and these are
by other Console programs in Unix fashion.
Is this what doesn't work? If so, there is a bug in _popen().
we are just expecting Unix behavior from Windows. Or perhaps we expect
popen() to work from a Windows non-Console app, which _popen() is
guaranteed not to do.
If there is something wrong with _popen() then the way to fix it is
to avoid using it and create the pipes directly. For an example
look in the docs under:
Windows Base Services
Processes and Threads
Using Processes and Threads
Creating a Child Process with Redirected Input and Output
The sample code can be extraced and put into posixmodule.c. Note that
this is what OS2 does. See the #ifdef.
> Failing that, the os.popen docs should caution it's "use at your own risk"
> under Windows, and that this is directly inherited from MS's popen
Of course, the strength of Python is portable code. popen() should be
fixed the right way.