> Date: Fri, 19 Oct 2007 14:51:23 -0700
> From: Tom Honermann <[EMAIL PROTECTED]>
> CC: make-w32@gnu.org
>
> 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.
Actually, what Make does in this case is this: If the program is found
along PATH, it is invoked directly (no need for any shell at all);
otherwise, if the program name is one of the built-in commands, or if
the command line includes redirection or other shell-specific
features, and no sh.exe is available, Make generates a batch file and
invokes it. Batch files are by default invoked through cmd.exe, but
that's the OS feature; Make has no explicit knowledge about that.
> 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'.
I'm not sure this is a good idea, as it would be a nuisance for those
who use GNU Make only on Windows, and don't care about any such
portability: they would see this warning time and again. Maybe this
would be appropriate under some pedantic-style command-line switch, or
some new --debug flag, but not as default.
Really, the Windows port tries to be conforming where it makes sense,
given its popular use cases, and deviates where necessary. Granted,
that requires some deviant, sometimes undocumented behavior, but I
think on balance those subtle aspects are few and most of the time
result in expected behavior.
> 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.
Also, this would be against Posix specifications for Make, I think.
> 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.
There's much more to security on Windows than a potentially rogue
sh.exe. There's the whole bunch of file security features on NTFS
filesystems, complete with ACLs and stuff, that Make doesn't currently
support (because we use the native Windows version of `stat' that
doesn't consider file security attributes). I don't think we should
consider isolated issues such as bad sh.exe before we have reasonably
full support for file security in general.
_______________________________________________
Make-w32 mailing list
Make-w32@gnu.org
http://lists.gnu.org/mailman/listinfo/make-w32
