Re: exported vs command line variables

[Philip Guenther]

On Fri, Sep 23, 2016 at 11:23 AM, Paul Smith <address@hidden> wrote:
> On Fri, 2016-09-23 at 05:52 -0700, David Boyce wrote:
>> I still think that's a good plan, except that now I find out it ends
>> up exporting anyway. I'm sure it's too late to change now but is
>> there a reason for this (unfortunate IMHO) behavior?
>
> I can't tell you: this behavior has existed since the very first import
> of GNU make code into source code control, back in 1991.

...and in System III in 1980:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/make

Looks like BSD picked it up in 4.4 around 1993 with the switch to pmake:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/usr.bin/make


POSIX specifies this behavior in the "Macros" subsection of the
EXTENDED DESCRIPTION section for 'make'.  About a page and half in is
this paragraph:
    Before the makefile(s) are read, all of the make utility command
line macro definitions (except the
    MAKEFLAGS macro or the SHELL macro) shall be added to the
environment of make. Other
+   implementation-defined variables may also be added to the
environment of make. Macros
+  defined by the MAKEFLAGS environment variable and macros defined in
the makefile(s) shall
+   not be added to the environment of make if they are not already in
its environment. With the
+   exception of SHELL (see below), it is unspecified whether macros
defined in these ways update
    the value of an environment variable that already exists in the
environment of make.

(That's from the 2013 draft update; the '+' lines were modified from
the original 2008 version of the standard, but that doesn't affect the
first sentence.)


Philip Guenther