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 - NormalItem Group: Documentation
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: 3.80Operating System: POSIX-Based
Fixed Release: NoneTriage 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 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:

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:

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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by kkylheku (Posted a comment)
  • -unavailable- added by phantal (Posted a comment)
  • -unavailable- added by gena3x (Posted a comment)
  • -unavailable- added by urzds
  • -unavailable- added by kkylheku (Voted in favor of this item)
  • -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 click here to add your encouragement to it.
    This task has 110 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 01 Apr 2016 12:16:13 PM UTCurzdsCarbon-Copy-=>Added urzds
    Wed 07 Jan 2015 08:28:29 PM UTCkkylhekuCarbon-Copy-=>Added kkylheku
    Mon 20 Mar 2006 09:28:48 PM UTCsrivastaCarbon-Copy-=>Added -unavailable-

    Back to the top

    Powered by Savane 3.1-cleanup1