Re: Why SHELL defaults to sh.exe

[Eli Zaretskii]

> From: "Christian Jullien" <address@hidden>
> Cc: <address@hidden>
> Date: Thu, 23 Jan 2020 21:07:26 +0100
> 
> Perhaps my sample was too simple.
> If I supply a Makefile that can work with or without sh.exe presence (on any
> user machines) I must rely on what make knows about the shell.

I'm saying such strategy is not the best one on Windows, because there
are too many variables the name of the shell doesn't capture.  Even if
you have some sh.exe somewhere, you cannot know what kind of shell is
it (Bash? zsh? something else?) and what exactly is it capable of on
Windows.  Programs that can be expected to be found on Unix might
exist on Windows as well, but you cannot be sure.

So a better strategy is to leave it up to the user to decide whether
to run in Unix mode or in Windows mode, and whether to call, say,
'del' or 'rm'.

Another, better method of detecting whether you are on Windows is to
probe the $(OS) variable: all modern versions of Windows have it set,
so your probability of a correct decision is much higher in that
case.  (But issues with what commands to employ still apply even in
that case.)

> Another example, Cygwin which provides a sh.exe also dir.exe which gives a
> different output. If SHELL is sh.exe or cmd.exe output is different

That's the same problem as the one with having 'find' from GNU
Findutils or from Windows.  It's part of the "which commands to
invoke" issue discussed above, nothing new.

> For my need, which is to have a gnumake coming with tcc.exe, I know how to
> automatically patch and build make with sh.exe replaced by cmd.exe in source
> file. So it's not a problem for me. I just wanted to point out something
> which I find not consistency (aka a bug).

It is a subtle issue, but I don't consider it a bug, since GNU Make on
Windows behaves like that since its first ported version.  You need to
be aware of that subtlety, but once you are, it is rarely a real issue
in practice.

Maybe we could remove that nowadays, but I have no way of knowing
what, if anything, that will break, and no motivation to work on a
change that can potentially destabilize what has been a very stable
program.