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


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

Submitter:  None
Submitted:  Wed 06 Oct 2004 02:55:07 AM UTC
Votes:  100  
Severity:  3 - Normal Item Group:  Documentation
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.80 Operating System:  POSIX-Based
Fixed Release:  4.4 Triage Status:  Small Effort
* Mandatory Fields

Add a New Comment (Rich Markup)

( Jump to the original submission )

Sat 09 Jul 2022 05:09:06 PM UTC, comment #8: 

This solution works for me, thanks to $(shell var=val .... command arg ...) working fine:

  # put desired env vars into "shell_env" variable
  shell_exports := foo000=bar000 foo001=bar001
  # interpolate variable as a prefix of shell command
  $(info $(shell $(shell_exports) env | grep bar))

The Makefile can maintain a shell_exports variable as it sees fit, adding to it with +=, removing using filter/filter-out and whatnot.

Kaz Kylheku <kkylheku>
Sat 09 Jul 2022 04:50:05 PM UTC, comment #7: 

I added support for exporting variables into $(shell ...) operations.  I didn't try to make it backward-compatible.  We'll see if this causes a problem but I doubt that it will, and trying to create multiple ways to do it seemed too onerous.

Paul D. Smith <psmith>
Project Administrator
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)

    There are 100 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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-09 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.4
        Triage StatusNone Small Effort
    2016-04-01 urzds Carbon-Copy- Added urzds
    2015-01-07 kkylheku Carbon-Copy- Added kkylheku
    2006-03-20 srivasta Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.11