bugmake - Bugs: bug #65359, submake might will lose variable...

 
 

bug #65359: submake might will lose variable values if their names contain special char

Submitter:  Howard <news_howardz>
Submitted:  Sat 24 Feb 2024 11:24:22 AM UTC
   
 
Severity:  3 - Normal Item Group:  Documentation
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.2.1 Operating System:  POSIX-Based
Fixed Release:  SCM Triage Status:  Small Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Mar 2024 11:17:18 PM UTC, comment #8: 

Added some notes about this, thanks for the note.

Paul D. Smith <psmith>
Group administrator
Mon 26 Feb 2024 02:28:51 PM UTC, comment #7: 

The manual says:

+quote+
When using export by itself or .EXPORT_ALL_VARIABLES to export variables by default, only variables whose names consist solely of alphanumerics and underscores will be exported. To export other variables you must specifically mention them in an export directive.
-quote-

I suppose we can add an extra admonishment saying that some shells will strip out environment variables with "special" names and so the only portable way to provide environment variables is with standard names.

There's nothing make itself can do about this obviously.

Paul D. Smith <psmith>
Group administrator
Mon 26 Feb 2024 05:12:59 AM UTC, comment #6: 

Hi, Martin,

Yes, you are right. My previous understanding was wrong. Exported variables in makefile can be seen by the recipes, as stated in make manual,

"To pass down, or export, a variable, make adds the variable and its value to the environment for running each line of the recipe. The sub-make, in turn, uses the environment to initialize its table of variable values. See Variables from the Environment."

comment #4:

> As demonstrated by eg:


> martind@stormy:~/tmp/make-65359$ cat Makefile
> export BADGER = wombat
> default:; echo BADGER = $$BADGER
> martind@stormy:~/tmp/make-65359$


>
> Variables are communicated to subprocesses, be they Make, the shell or otherwise, via the environment.  There is no other way.

Howard <news_howardz>
Mon 26 Feb 2024 05:10:19 AM UTC, comment #5: 

Hi, Dmitry,

Got it. This explains the test result well.

comment #3:

> Exporting a make variable makes it available for shell in recipes.
>
> Removal of a semicolon allows make to avoid shell. Instead makes calls posix_spawn or fork and exec.

Howard <news_howardz>
Mon 26 Feb 2024 04:01:59 AM UTC, comment #4: 

As demonstrated by eg:

martind@stormy:~/tmp/make-65359$ cat Makefile
export BADGER = wombat
default:; echo BADGER = $$BADGER
martind@stormy:~/tmp/make-65359$


Variables are communicated to subprocesses, be they Make, the shell or otherwise, via the environment.  There is no other way.

Martin Dorey <mdorey>
Mon 26 Feb 2024 03:48:09 AM UTC, comment #3: 

Exporting a make variable makes it available for shell in recipes.

Removal of a semicolon allows make to avoid shell. Instead makes calls posix_spawn or fork and exec.

Dmitry Goncharov <dgoncharov>
Mon 26 Feb 2024 02:58:36 AM UTC, comment #2: 

Hi, Martin,

Normally make variables are different with shell variables. Exported shell variables can be seen by make. However, exported make variables cannot be seen by shell in recipes.
I don't know whether submake gets make exported variables via shell variables. But even if this is true, it cannot explain why the submake works well if removing the ';' at the end of the recipe (which invokes submake).

comment #1:

> Because then Make runs the command with a shell and, perhaps particularly after Shellshock, shells are increasingly diligent about cleaning the environment (eg https://stackoverflow.com/questions/36989263/why-cant-environment-variables-with-dashes-be-accessed-in-bash-4-1-2), so what could Make do?  I guess it could warn that your export is unlikely to work reliably.

Howard <news_howardz>
Sat 24 Feb 2024 03:26:07 PM UTC, comment #1: 

Because then Make runs the command with a shell and, perhaps particularly after Shellshock, shells are increasingly diligent about cleaning the environment (eg https://stackoverflow.com/questions/36989263/why-cant-environment-variables-with-dashes-be-accessed-in-bash-4-1-2), so what could Make do?  I guess it could warn that your export is unlikely to work reliably.

Martin Dorey <mdorey>
Sat 24 Feb 2024 11:24:22 AM UTC, original submission:  

If the submake cmd line contains any separated char (e.g., ';', '&', '|', ...) at the end of the make cmd, export var will lose values in the submake process if these var contain special char (e.g., '+', '-').

Makefile:
-----------------
ifeq ($(LOOP),1)
LOOP = 2
else
export C++ = test1
export C-- = test2
export C__ = test3
export LOOP = 1
endif

$(info C++=$(C++))
$(info C--=$(C--))
$(info C__=$(C__))

ifeq ($(LOOP),2)
all:;
else
all:
$(MAKE);
endif
------------

$ make
C++=test1
C--=test2
C__=test3
make;
make[1]: Entering directory '/mnt/d/temp'
C++=
C--=
C__=test3
make[1]: 'all' is up to date.
make[1]: Leaving directory '/mnt/d/temp'

If change "$(MAKE);" to "$(MAKE)", we can get the correct result:

$ make
C++=test1
C--=test2
C__=test3
make
make[1]: Entering directory '/mnt/d/temp'
C++=test1
C--=test2
C__=test3
make[1]: 'all' is up to date.
make[1]: Leaving directory '/mnt/d/temp'


Howard <news_howardz>

 

(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 dgoncharov (Posted a comment)
  • -email is unavailable- added by mdorey (Posted a comment)
  • -email is unavailable- added by news_howardz (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-28 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone SCM
        Triage StatusNone Small Effort
    2024-02-26 psmith Item GroupBug Documentation

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code