Re: Make on XP - shell selection?

[Tom Honermann]

Eli Zaretskii wrote:

I 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.
  

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 SHELL
assignment to 'perl(.exe)'

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.
  

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'
('sh.exe' on Windows) in PATH.

_______________________________________________
Make-w32 mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/make-w32