Eli Zaretskii wrote:
I think there is a difference in behavior here. On a UNIX system if '/bin/sh' were to be missing, Make would still attempt to exec '/bin/sh' and then would report the error. However, On Windows, Make has a fallback plan: It execs 'cmd.exe' instead. I'm sure some will object to this, but perhaps it would make sense for Make to issue an error on Windows if an 'sh.exe' cannot be found and therefore require a SHELL assignment in order to use 'cmd.exe'. This would keep Makefiles portable in the sense that it removes the environmental uncertainty caused by the addition or removal of a directory containing an 'sh.exe' from one's PATH. Makefiles that use 'cmd' syntax would therefore require a SHELL assignment just like Makefiles using 'perl' syntax require a SHELLI don't know who benefits from it but so far nobody dared to document it, either.I'm not sure it should be documented: the Windows port just behaves the same as the Unix original. Here's the relevant fragment executed by Make on Unix (job.c, around line 2100): # ifdef __EMX__ ... # else shell = getenv ("SHELL"); # endif if (shell == 0) shell = default_shell; and default_shell is "/bin/sh" on Unix, see line 74 in the same file. The same is done around line 2355 in job.c: if (shell == 0) shell = default_shell; Granted, the code in the Windows port that does the equivalent is more complicated, but the net effect, as far as user is concerned, is the same: sh.exe is used if it is available.
assignment to 'perl(.exe)'
Absolutely agreed that searching along PATH makes sense on Windows here. If we wanted to be pedantic, Make could do this on UNIX as well. However, doing so would generally be considered a security issue since a rogue 'sh' could be inserted in a directory in one's PATH without them realizing it. If we really wanted to make the behaivors the same without compromising secutiry, we could look for the correct shell by first trying '/bin/sh' (%SystemDrive%\bin\sh.exe on Windows), and if that fails, then look for an 'sh'Certainly it conflicts with the general rule that for makefile portability reasons the SHELL to be used shall not depend on individual environment settings.The OP's report was not about SHELL in the environment, it was about setting SHELL in the Makefile. Certainly, you won't claim that Make ignores _that_ on Unix, would you? And if by ``individual environment settings'' you mean the value of PATH, then I don't see how Make can do better, since, unlike on Posix platforms, there's no "/bin" directory on your garden-variety Windows box. So it looks along PATH, which is a reasonable thing to do, IMO.
('sh.exe' on Windows) in PATH.
_______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
_______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
