[bug #23922] On XP 64 with sh.exe installed in "Program Files (x86)" gmake generates a stack overflow exception.

[Eli Zaretskii]

Follow-up Comment #4, bug #23922 (project make):

The original problem happened because 32-bit programs on 64-bit versions of
MS-Windows are routinely installed under the system directory called
"C:/Program Files (x86)/".  For GNU Make to work correctly on such systems,
when SHELL is simply set to the absolute file name of a shell installed under
that directory, the parentheses must be quoted.  If we don't do that, GNU Make
on Windows would be useless with alternate shells.

IOW, the fix in commit b5c06541 fixed a serious problem whose probability of
showing up on MS-Windows is very high.

By contrast, the use case it broke is quite rare, and the way it (ab)uses the
SHELL variable is quite frankly unsupported on MS-Windows -- unlike on Posix
systems, the MS-Windows port of Make does not yet support arbitrary commands
as the value of SHELL, and never did.  So it's a small wonder that this use
case became broken.

> Whoever defines SHELL can be presumed to know what they mean by it.

There's nothing wrong with using a file name whose directories include
parentheses.  Users on Windows should not be required to escape them.  We
cannot ask them to; this is a non-starter.

> Surely it doesn't matter if SHELL has characters special to the shell,
unless it is being invoked by the shell, in which case can we limit the
escaping to the circumstance when it is actually invoked by the shell, and not
by execve ? 

Unfortunately, this distinction on Windows is problematic.  Even if we
initially intend to bypass the shell, later we might decide we do need it, for
various obscure reasons.  Also, CreateProcess, the API used to run subsidiary
programs on Windows, needs its command-line arguments to observe some of the
rules that are identical to those of the shell.

> If we insist on doing this, can we have an option to disable it? Or to
enforce that it be invoked by the shell instead of execve?

Patches to achieve that will be welcome, if they are clean and don't affect
any other use cases.  Personally, I think the latter alternative is all but
impossible, but I could be wrong.

Please note that for a large enough changeset you will have to sign legal
papers before the changes can be accepted.

Thanks.


    _______________________________________________________

Reply to this item at:

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

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