[Python-Dev] FW: Fixing os.popen on Win32 => is the win32pipe stuff going to be adopted? (original) (raw)

James C. Ahlstrom jim@interet.com
Thu, 09 Mar 2000 10:45:54 -0500


Tim Peters wrote:

I had another take on all this, which I'll now share 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 that 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"), or 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 inherited by other Console programs in Unix fashion.

Is this what doesn't work? If so, there is a bug in _popen(). Otherwise 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:

Platform SDK Windows Base Services Executables 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 implementation.

Of course, the strength of Python is portable code. popen() should be fixed the right way.

JimA