RE: Why SHELL defaults to sh.exe

[Christian Jullien]

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.
Forcing SHELL= obviously does not work.
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

ifeq ($(SHELL),sh.exe)
LIST=$(shell dir)
else
LIST=$(shell dir /b)
endif

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

I'm more interested to have my patches for built_w32.bat and
src/config.h.W32.template integrated to the next release.

Anyway many thanks you're your time and patience.


C. 


-----Original Message-----
From: Eli Zaretskii [mailto:address@hidden] 
Sent: Thursday, January 23, 2020 20:26
To: address@hidden
Cc: address@hidden
Subject: Re: Why SHELL defaults to sh.exe

> From: "Christian Jullien" <address@hidden>
> Date: Thu, 23 Jan 2020 20:18:17 +0100
> 
> Hum I see! It only a problem if I want to execute something if a sh.exe
> exists.
> 
> search:
> ifeq ($(SHELL),sh.exe)
>       grep something file
> else
>       find "something" file
> endif

If you want to depend on the value of $(SHELL), set it explicitly in
the Makefile.

In any case, the above logic is flawed, because 'grep' can be
available on Windows as well (I certainly have it here), and 'find'
could actually invoke a ported GNU 'find'.  IME, it is much better to
have Make variables for such commands, and let users set them from the
Make command line.