Re: Patch for missing shell commands in rc2

[Eli Zaretskii]

> From: "J. David Bryan" <address@hidden>
> Date: Tue, 21 Mar 2006 11:58:43 -0500
> CC: address@hidden
> 
> > However, this cannot be accepted as you sent it, because we still
> > support older Windows versions where the shell is COMMAND.COM. 
> 
> I'm not sure I see why that is a problem.  With the patch, if one uses a 
> cmd.exe shell command that isn't present (e.g., "pushd") or is implemented 
> as an external (e.g., "start") in command.com, then command.com gives an 
> error or runs the associated program, respectively.  Without the patch, 
> essentially the same thing occurs (make gives the error or runs the 
> associated program).

No, it's not the same thing: the way commands are invoked via the
shell is very different from how programs are invoked directly,
especially on Windows, and these two ways support subtly different
syntaxes on Windows.  Please step with the debugger thru the code and
I think you will see that.

One notable problem is the forward vs backslashes in file names: when
you invoke "c:/foo/bar/baz.exe" from the shell, you must first convert
the forward slashes to backslashes.

Another problem is the 126-character limit on COMMAND.COM's command
line; invoking programs directly via CreateProcess won't hit this
limit.

In short, this would be an incompatible change, which I don't think
we should do now, 5 minutes before the release of v3.81.

OTOH, it should be very easy to do this at run time rather than at
compile time, if $SHELL is cmd.exe.  Why risk problematic changes when
the Right Thing is so easily done?

> The use of sh_cmds_dos appears to be simply to decide whether the command 
> should be passed via the shell or executed directly.

Yes, that's true.

> Given that, I would 
> think that sh_cmds_dos should contain both cmd.exe and command.com internal 
> commands, to ensure that all shell commands are passed to the shell, 
> regardless of which one is used.  And if a listed command isn't implemented 
> in the shell being used but is an external program instead, then it still 
> is executed properly, albeit via the "slow path."

I hope I explained above why ``properly'' is not well defined in this
case.  In particular, invoking the same command via the shell and
directly might very well produce different results, although each one
of them is ``proper''.