Re: Handling of SHELL by GNU make: not POSIX compliant

[Soren A]

address@hidden wrote around 25 Sep 2002
news:address@hidden: 

I don't see this issue affecting me much anytime soon, and probably i
ought to keep my mouth shut. But I found myself provoked in a wondering
kind of way. 

> %% David Boyce <address@hidden> writes:
> 
>   db> 1. Why does GNU make automatically export settings of SHELL
>   db>    without the 'export' keyword?
>   db> 2. The unexport directive should not *remove* SHELL from the
>   environment db>    but rather just suppress the export of the
>   internal variable. 
> 
> I don't know the answer to #1, really.
> 
> Originally I thought it might be required by POSIX, but actually
> looking at the POSIX spec now I think maybe GNU make is wrong, and is
> not conforming to the standard--that's why I'm forwarding this message
> to make-alpha so others can comment.
> 
> The POSIX 1003.1-2001 "Shell and Utilities, Issue 6" spec (page 614,
> lines 23699-23704) says:
> 
>   The SHELL macro shall be treated specially.  It shall be provided by
>   make and set to the pathname f the shell command language
>   interpreter (see sh).  The SHELL environment variable shall not
>   affect the value of the SHELL macro.  If SHELL is defined in the
>   makefile or is specified on the command line, it shall replace the
>   original value of the SHELL macro, *but shall not affect the SHELL
>   environment variable*. Other effects of defining SHELL in the
>   makefile or on the command line are implementation-defined.
> 
> (emphasis mine).  So, it seems GNU make is not handling this properly,
> since any setting of the make variable SHELL _is_ reflected in the
> environment variable.

I am "provoked" into having questions about the meaning of all this. It
seems to me that "What You Expect (tm)" would be for any subprocess (sub
shell, child process) to inherit the setting for "SHELL" that is in
effect in the Makefile. I strain my meager experience to think of a
situation in which you'd want child processes of 'make' to have a value
of SHELL that's different in the environment of that process than it is
in the value of the 'make' macro 'SHELL'. To what possible end would
such an inconsistency be maintained? Can anyone give me an example? 

As a 'make' user on a platform that requires shell issues to be handled
differently (historically always has -- Windows / DOS) I am also
wondering how an attempt to change the behavior of 'make' in the manner
David Boyce seems to be suggesting would impact me and those like me. It
appears IMHO that we totally rely on 'make' setting SHELL in the
environment of child processes since we cannot be guaranteed otherwise
that SHELL will be useful or correct -- the native "shell"-like entity
on our platforms being basically a big problem issue that many have
sought to avoid by installing a foreign, ported Bourne-compatible shell
(sh, bash, zsh, ksh). 

To sum up, my possibly naive understanding is that one would ordinarily
expect the setting for a parameter of such a primary importance as SHELL
to be propagated to all children -- and to their children, which is what
we are talking about right? -- of the 'make' application. We who have
any familiarity with 'make' at all understand how SHELL is already
specially-treated in that there is a "no-inherit" policy on *nix-ish
platforms and a differing "inherit" policy on DOS/Win -ish ones; and it
seems to me that layering on additional complexity (that 'make's idea of
SHELL and 'make's children's idea of SHELL would possibly differ) to
that already complex situation simply makes things harder for users
without achieving any practical improvement for anybody? 

   Regards,
    Soren A