Re: Why does the shell I invoke Make with have an effect on its output?

[Kaz Kylheku]

On 2022-03-08 18:42, Peter0x44 wrote:
> On Tue Mar 8, 2022 at 11:23 PM GMT, Kaz Kylheku wrote:
> > On 2022-03-08 13:37, Peter0x44 wrote:
> > >> But the rules Make applies are supposed to follow the semantics of the
> > >> shell that Make would have invoked. So if you have sh.exe on PATH, I
> > >> think Make will try to use the Posix shell semantics.
> > > So, there is there no way to tell which shell Make is trying to
> > > invoke/follow
> > > the semantics of in my Makefile?
> > >
> > > That's all I really want to know.
> >
> > This topic is covered in the GNU Make manual:
> >
> > https://www.gnu.org/software/make/manual/make.html#Choosing-the-Shell
> >
> > I suspect any of these aspects could be influenced by exactly how GNU
> > Make
> > is ported to Windows. As an example, I wouldn't expect GNU Make ported
> > to a POSIX environment on Windows like Cygwin to follow this.
> >
> > I believe the documentation refers to a version of GNU Make built
> > for Windows according to one of the project's own recommended
> > methods:
> >
> > http://git.savannah.gnu.org/cgit/make.git/tree/README.W32.template
> I have read this page, but I am not sure how to apply the contained
> information.
>
> I simply want to have a variable SHELLTYPE, that is set to msdos if 
> cmd.exe is
> being used as the shell, and posix if sh.exe is being used.
>
> Checking the value of SHELL in the Makefile does not work, because as
> documented on that page:
>
> "However, if none of these is found, the value of SHELL will not be 
> changed"

Yes; so it appears there is no easy way to detect whether that search
succeeded or not, without replicating it.

However, these remarks only apply to the situation when SHELL has been 
set
in the Makefile or command line (or via the environment, on Windows).

If you haven't set SHELL, then COMSPEC is used for the interpreter, 
without
any search for the $(SHELL). The documentation is saying that the 
variable
will contain /bin/sh but no search for it takes place.

I think a way out of this whole complexity is to use the $(shell ...)
function to execute some tests. Possibly a single "polyglot" test that
executes either in a Posix shell or a Windows interpreter like cmd.exe,
producing a distinguishing result.

(I'm saying this on the assumption that the $(shell ...) function uses
exactly the same shell that was found by the documented process we
are referring to and used for recipes.)

for instance, under this assumption, we might do:

  ifeq ($(shell echo %PATH%),PATH)
  SHELLTYPE := posix
  else
  SHELLTYPE := nonposix
  endif

A POSIX shell just echoes %PATH%, whereas cmd.exe expands %PATH%.

> I am also not sure if this information applies:
>
> On MS-DOS, if SHELL is not set, the value of the variable COMSPEC 
> (which is
> always set) is used instead.
>
> I am obviously not running MS-DOS, and from my testing, COMSPEC always 
> contains
> a path to the location of cmd.exe

I think that probably applies to DOS or Windows.

The problem is that COMSPEC is still set in POSIX-like build of Make.
So that is to say  the assumption that the presence of COMSPEC means
we are not using a POSIX shell is not portable.

Here is Cygwin:

  $ make
  C:\WINDOWS\system32\cmd.exe
  make: Nothing to be done for 'all'.

  $ cat Makefile
  $(info $(COMSPEC))

  all: