bugmake - Bugs: bug #10593, $(shell) doesn't honor export but...


bug #10593: $(shell) doesn't honor export but this is undocumented?

Submitted by:  None
Submitted on:  Wed 06 Oct 2004 02:55:07 AM UTC  
Votes:  110  
Severity:  3 - Normal Item Group:  Documentation
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  3.80 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 02 Jan 2017 08:14:47 PM UTC, comment #6: 

See also duplicate bug #35323

Paul D. Smith <psmith>
Project Administrator
Tue 10 May 2016 02:51:17 PM UTC, comment #5: 

Of course this creates a backward compatibility problem if it is fixed. It is a change to existing behavior. For any such change, we can contrive code which depends on the old behavior.

For instance, when ISO C added // comments in 1999, it broke code such as a//*comment*/b which denotes the division a/b.

If any such a change is forbidden, then it leaves the language development hamstrung against fixing certain kinds of bugs and improvements.

The improvements still happen, but in kludgy ways which are like legs growing out of a forehead. You always have to think: if I started with a clean slate, not saddled by backward compatibility, could I still justify doing it this way?

The way to address this is to have some controls over the language dialect. For instance, GNU Make could have a command line option for emulating a prior version. As well as a special variable that cold be deposited into a Makefile. Say, --emulate=3.81 or __GMAKE_EMULATE := 3.81.

Someone whose code breaks because of a fix like this can use the mechanism as a quick workaround.

Kaz Kylheku <kkylheku>
Tue 10 May 2016 01:53:56 PM UTC, comment #4: 

Or just 'fexport' or control export behavior with some variable.

Gennady <gena3x>
Tue 10 May 2016 01:09:44 PM UTC, comment #3: 

Or perhaps the better named:

$(setenv TEST,something else)

Brian Vandenberg <phantal>
Tue 10 May 2016 01:05:03 PM UTC, comment #2: 

This has the potential to create a backward compatibility problem if it were fixed.  Currently someone could take advantage of the fact that "export" does not export to $(shell) environments and "fixing" this would alter that behavior.

As an alternative I think it would be better to add a new macro function for exporting:

$ cat <<'EOF' | env TEST=stuff gmake -f -
$(warning ${TEST})
$(warning echo $${TEST})
export TEST := blah
$(warning echo $${TEST})
$(export TEST)
$(warning echo $${TEST})
$(export TEST,something else)
$(warning echo $${TEST})
/tmp/Gmp3tNks:1: stuff
/tmp/Gmp3tNks:2: stuff
/tmp/Gmp3tNks:4: stuff
/tmp/Gmp3tNks:6: blah
/tmp/Gmp3tNks:8: something else
make: *** No targets.  Stop.

Brian Vandenberg <phantal>
Tue 10 May 2016 09:21:21 AM UTC, comment #1: 

Faced this today, as many other people do: http://stackoverflow.com/questions/2838715/makefile-variable-initialization-and-export

If some of gmake contributors have a time, please fix.

Gennady <gena3x>
Wed 06 Oct 2004 02:55:07 AM UTC, original submission:  

I haven't seen anything in the documentation to suggest that $(shell) doesn't give its child process an environment containing exported variables.  For example, I expected this makefile:

export foo = bar
baz := $(shell echo $$foo)
$(error baz was :$(baz):)

To error with:

Makefile:3: *** baz was :bar:.  Stop.

When it actually errors with:

Makefile:3: *** baz was ::.  Stop.

The relevant part of the source may or may not be:

  /* Using a target environment for `shell' loses in cases like:
     export var = $(shell echo foobie)
     because target_environment hits a loop trying to expand $(var)
     to put it in the environment.  This is even more confusing when
     var was not explicitly exported, but just appeared in the
     calling environment.  */

  envp = environ;

One could make a case that this is a bit lame - that it couldn't be so difficult (could it?) to not export partially defined variables but to honor other exports.  It sounds easier and less risky and less performance-sapping to document the existing behaviour.



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

Attach Files:

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 kkylheku (Posted a comment)
  • -email is unavailable- added by phantal (Posted a comment)
  • -email is unavailable- added by gena3x (Posted a comment)
  • -email is unavailable- added by urzds
  • -email is unavailable- added by kkylheku (Voted in favor of this item)
  • -email is unavailable- added by srivasta (So that thje Debian BTS can track progress on this)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 110 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-01 urzds Carbon-Copy- => Added urzds
    2015-01-07 kkylheku Carbon-Copy- => Added kkylheku
    2006-03-20 srivasta Carbon-Copy- => Added 354602-forwarded@bugs.debian.org

    Back to the top

    Powered by Savane 3.6