[Python-bugs-list] "Fix" os.system() on Windows (PR#406)

[Tim Peters]

[Howard B. Golden]
> So it can be done, but it's not a simple fix, because you have to
> distinguish between command.com builtin commands and external
> commands.  I'll look at Tcl to see what's involved.  It sounds like
> it's far more trouble than it's worth!

Alas, it's much worse than just guessing which cmds are builtin on your
current flavor of Windows.

> It is my "wish" to clean up MS's design glitches, but I guess they
> put them there for a reason (incompatibility, perhaps?).

Not really.  DOS and Windows ran on much feebler systems than, e.g., Unix
ever ran on, and MS has decades of backward compatibility to worry about
too.  For example, you'll find a bunch of code in the Tcl source trying to
fake pipes on versions of Windows too old to support them directly (Tcl's
flavor of "system" is called "exec", and tries to give robust portable
meaning to the usual cmdline metasymbols too, like ">" and "|").  The *kind*
of executable under Windows can also make a difference, as stuff compiled
for the 16-bit subsystem can act differently than that compiled for the
32-bit one, and the ancient Win32s subsystem throws in its own surprises.
Tcl tries to make sense out of all of that -- and you *do* need to make
sense of it all if you want it to be as usable as it is under Unix.  Even
so, the Tcl manpages bristle with warnings about things that can still go
wrong with "exec" under Windows.  It's simply a mess.

> ...
> Buying a "real shell" is a great idea, in general, but it doesn't fix
> the problem on Windows in general, unless you can get everyone to buy
> the shell, too.

Right -- there's no clear way out of this.

> Thanks to you both for considering the suggestion!

Oh, it's been under consideration for years <wink>.  Last time somebody got
excited about this was 1-2 years ago.  They ran off to look at the Tcl
source too, and were never heard from again <wink/sigh>.