[bug #30714] List of shell commands is outdated/Fallback to shell

[Eli Zaretskii]

Follow-up Comment #6, bug #30714 (project make):

Savannah is not suited well for having a discussion.  (Maybe we should start
a thread on address@hidden, if this is going to continue.)  I respond to
some of the comments after quoting the relevant portion of it.

>As for MOVE being external program in Windows 9x: please note >that Windows
9x uses command.com, while NT line uses cmd.exe - 

Not true: there's Windows ME that uses cmd.exe, but is still W9X vintage
under the hood.  It's a mess.

>Please also note that you already have cmd.exe's specific >commands on the
list (like setlocal/endlocal).

These are never external programs, so the problem does not arise.

>Again, falling back to running shell would keep such problems >away.

So would an explicit use of "cmd /c move".  I actually think that this is TRT
in a Makefile that should run on Windows, because you can never know what
shells are installed on the end-user's machine.  For example, if there's a
sh.exe anywhere on PATH, Make will invoke it by default, and then "move" will
fail anyway.

>How far do you expect you can get with logic with people who >think that
throwing two internal function names
>("process_begin: CreateProcess") is anyway good enough as an >error message
for you stupid windoze user.

People who coded that are no longer active in Make maintenance.  Feel free to
submit patches to make the diagnostics more user-friendly, such patches will
be welcome here.  Alternatively, feel free to file a separate bug report about
that.

>My point here is that the shell should be called here, not the >system
directly. After all the system won't do anything more >than the shell would
do, but it can do less

Are you sure?  AFAIR, CreateProcess doesn't only search PATH, but also a few
other places, see the MS docs.  Are you positive that the shell searches
exactly those same places?  What about with the directory where Make's
executable lives, for example? will the shell look there?

You see, these additional places where CreateProcess looks for a program are
one reason why we call CreateProcess even though the search along PATH fails.

(Invoking the shell has another disadvantage: cmd.exe supports only 4K long
command lines, while CreateProcess supports 32K.)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30714>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/