[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kaz Kylheku
Subject: Re: Why does the shell I invoke Make with have an effect on its output?
Date: Wed, 09 Mar 2022 08:09:13 -0800
User-agent: Roundcube Webmail/1.4.13

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:

I suspect any of these aspects could be influenced by exactly how GNU
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
I have read this page, but I am not sure how to apply the contained

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
  SHELLTYPE := nonposix

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
  make: Nothing to be done for 'all'.

  $ cat Makefile
  $(info $(COMSPEC))


reply via email to

[Prev in Thread] Current Thread [Next in Thread]