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

[Tim Peters]

[James C. Ahlstrom]
> 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 ...

Screw the docs.  Pretend you're a newbie and *try* it.  Here:

import os
p = os.popen("dir")
while 1:
    line = p.readline()
    if not line:
        break
    print line

Type that in by hand, or stick it in a file & run it from a cmdline
python.exe (which is a Windows console program).  Under Win95 the process
freezes solid, and even trying to close the DOS box doesn't work.  You have
to bring up the task manager and kill it that way.  I once traced this under
the debugger -- it's hung inside an MS DLL.  "dir" is not entirely arbitrary
here:  for *some* cmds it works fine, for others not.  The set of which work
appears to vary across Windows flavors.  Sometimes you can worm around it by
wrapping "a bad" cmd in a .bat file, and popen'ing the latter instead; but
sometimes not.

After hours of poke-&-hope (in the past), as I said, I've never been able to
predict which cases will work.

> ...
> It further states that it does NOT work in a Windows program and ONLY
> works when called from a Windows Console program.

The latter is a necessary condition but not sufficient; don't know what *is*
sufficient, and AFAIK nobody else does either.

> 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"),

See above for a counterexample to both <wink>.  I actually have much better
luck with cmds command.com *doesn't* know anything about.  So this appears
to vary by shell too.

> ...
> If there is something wrong with _popen() then the way to fix it is
> to avoid using it and create the pipes directly.

libc pipes ares as flaky as libc popen under Windows, Jim!  MarkH has the
only versions of these things that come close to working under Windows (he
wraps the native Win32 spellings of these things; MS's libc entry points
(which Python uses now) are much worse).

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

pipes too, but users get baffled by popen much more often simply because
they try popen much more often.

there's-no-question-about-whether-it-works-right-it-doesn't-ly y'rs  - tim