bugmake - Bugs: bug #46585, variables being auto-exported to...

 
 

bug #46585: variables being auto-exported to the environment if it was set in the environment

Submitter:  Brian Vandenberg <phantal>
Submitted:  Wed 02 Dec 2015 02:06:52 AM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.1 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 26 Dec 2016 04:53:28 PM UTC, comment #3: 

See also duplicate bug #48360.

I've reviewed the POSIX spec and it does seem to say that GNU make's current behavior is the expected one; I see this (although in the Rationale section:

The environment is the same as the environment to make except that MAKEFLAGS and macros defined on the make command line are added, and except that macros defined by the MAKEFLAGS environment variable and macros defined in the makefile(s) may update the value of an existing environment variable (other than SHELL).

I don't see any great way to avoid this; many makefiles have been written expecting this behavior (consider, for example, resetting common environment variables such as PATH, etc.) so we can't just turn it off completely... and makefile writers already have a way to avoid exporting variables they don't want to export (via the unexport command).

Paul D. Smith <psmith>
Group administrator
Mon 29 Feb 2016 03:27:07 AM UTC, comment #2: 

This is the way GNU make has always worked.  It's not clear from the POSIX spec whether this behavior is allowed.

I'll leave this open as an enhancement request until we can determine if POSIX requires the original environment variable to be passed through to the sub-command.  If so we can enable that behavior when the .POSIX: target is detected.

Paul D. Smith <psmith>
Group administrator
Wed 02 Dec 2015 02:13:00 AM UTC, comment #1: 

This may not actually be a bug:

http://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html#Variables_002fRecursion

Quoting:

Except by explicit request, make exports a variable only if it is either defined in the environment initially or set on the command line, and if its name consists only of letters, numbers, and underscores. Some shells cannot cope with environment variable names consisting of characters other than letters, numbers, and underscores. (emphasis mine)

This seems surprising to me, but that's what the docs say.

Brian Vandenberg <phantal>
Wed 02 Dec 2015 02:06:52 AM UTC, original submission:  

The short version:

  • If a variable is set in the environment then you set the variable in a makefile without the "export" keyword, it's auto-exported to the environment.
  • If the variable is not set in the environment, the value set in the makefile is not exported to the environment.



.RECIPEPREFIX := >

BLAH := from makefile

$(warning ${BLAH}, $(shell echo $$BLAH))

all:

> @echo In $@: ${BLAH}, should be from makefile
> @echo In $@: $$BLAH, should be from env
> @echo In $@: $(shell echo $$BLAH), should be from env



Executed with:

~ env BLAH="from env" gmake -f /tmp/makefile
/tmp/makefile:5: from makefile, from env
In all: from makefile, should be from makefile
In all: from makefile, should be from env
In all: from env, should be from env
~ gmake -f /tmp/makefile
/tmp/makefile:5: from makefile,
In all: from makefile, should be from makefile
In all: , should be from env
In all: , should be from env

I was under the impression that it would only export to the shell if you did one of the following:

  • "export" on a line by itself, forcing all variables to auto-export
  • "export BLAH", or some variation thereof


... but it looks as though it's exporting always if it was set in the original environment make was executed with.

Brian Vandenberg <phantal>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by phantal (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-26 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed
    2016-02-29 psmith Item GroupBug Enhancement

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code