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

[Tim Peters]

[Gordon McM, aspires to make sense of the mess]
> It doesn't work for commands builtin to whatever "shell" you're
> using. That's different between cmd and command, and the
> various flavors, versions and extensions thereof.

It's not that simple, either; e.g., old apps invoking the 16-bit subsystem
can screw up too.  Look at Tcl's man page for "exec" and just *try* to wrap
your brain around all the caveats they were left with after throwing a few
thousand lines of C at this under their Windows port <wink>.

> FWIW, I gave up a long time ago. I use redirection and a
> tempfile. The few times I've wanted "interactive" control, I've
> used Win32Process, dup'ed, inherited handles... the whole 9
> yards. Why? Look at all the questions about popen and child
> processes in general, on platforms where it *works*, (if it
> weren't for Donn Cave, nobody'd get it to work anywhere <wink>).

Donn is downright scary that way.  I stopped using 'em too, of course.

> To reiterate Tim's point: *none* of the c runtime routines for
> process control on Windows are adequate (beyond os.system
> and living with a DOS box popping up).

No, os.system is a problem under command.com flavors of Windows too, as
system spawns a new shell and command.com's exit code is *always* 0.  So
Python's os.system returns 0 no matter what app the user *thinks* they were
running, and whether it worked or set the baby on fire.

> The raw Win32 CreateProcess does everything you could possibly want, but
> takes a week or more to understand, (if this arg is a that, then that arg
> is a whatsit, and the next is limited to the values X  and Z unless...).

Except that CreateProcess doesn't handle shell metacharacters, right?  Tcl
is the only language I've seen that really works hard at making
cmdline-style process control portable.

so-all-we-need-to-do-is-a-single-createprocess-to-invoke-tcl<wink>-ly y'rs
    - tim