Re: Patch for missing shell commands in rc2

[Eli Zaretskii]

> From: "J. David Bryan" <address@hidden>
> Date: Wed, 22 Mar 2006 13:05:03 -0500
> CC: address@hidden
> 
> On 22 Mar 2006 at 6:40, Eli Zaretskii wrote:
> 
> > My example is with the following command:
> > 
> >    start c:/foo/bar/baz.exe
> > 
> > Do you see the issue now?
> 
> I'm afraid not, because the above works fine in Win95 and Win98, e.g.  Try:
> 
>   start c:/windows/notepad.exe
> 
> ...under command.com, and I believe that you'll see that notepad starts as 
> expected.

I don't have Windows 9x handy, so I cannot try this, but that was only
an example (btw, `start' does exist on Windows 9x, albeit not as an
internal command, IIRC).  Maybe another example will explain what I
mean:

      cmd /c dir c:/windows
vs
      dir c:/windows

(assuming you have dir.exe from the ported Coreutils).  Now, if DIR
was not in the internal commands, Make would run the second variant
and succeed; while if we add it to internal commands, Make will run
the first variant and fail.

Again, DIR is just an example, so please don't tell me that both
COMMAND.COM and CMD.EXE have it.  What I'm arguing is that running
commands through the Windows shell may well produce different results.

> > Another problem is the 126-character limit on COMMAND.COM's command
> > line; invoking programs directly via CreateProcess won't hit this
> > limit. 
> 
> MSDN says that the limit for batch command lines, i.e., how make runs shell 
> commands, is 1024 characters under command.com:
> 
>   http://msdn.microsoft.com/archive/en-us/win9x/msdos_694j.asp

Did you actually try this?  I don't have Windows 9x handy anymore, but
I remember I had unpleasant surprises with this.

> So I believe that the only incompatibility my original patch would cause 
> would be to existing makefiles running under command.com that had issued 
> command lines longer than 1024 characters to programs whose names conflict 
> with the added cmd.exe shell command names.

That is already enough to try to solve the problem in another way.
And I believe I suggested a better way, which is to defer the test to
the run time.

> If you believe that limitation is too restrictive, however, I'm willing to 
> undertake the selection of sh_cmds_dos at run time.

Yes, please.

> That would appear to add some overhead to every command execution,
> though.

I believe the overhead will be negligible, since all you need is a
bunch of string comparisons.

> > I cannot imagine you really need to invoke a command via "start" in a
> > Makefile.  If that's a real example, can you describe it in mode
> > detail? 
> 
> I have three situations that use "start" in the makefile as a convenience:

Well, these aren't jobs for Make, but okay.