[bug #59154] Multiline environment variables handled poorly

URL: Summary: Multiline environment variables handled poorly Project: make Submitted by: dankegel Submitted on: Mon 21 Sep 2020 02:58:39 PM UTC Severity: 3 - Normal Item

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #1, bug #59154 (project make): I thought this might be related to https://en.wikipedia.org/wiki/Shellshock_(software_bug) but make is exec()ing the wrong command: martind@sirius:~/tmp/make-59154$ export PUB="$(echo hello; echo world)" martind@sirius:~/tmp/make-59154$ cat Makefi

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #2, bug #59154 (project make): This is done on purpose. Newlines in variable expansions are treated as real newlines in the rule. If they weren't, then multiline definitions would not work at all: define MYRULE echo hello echo world endef all: ; $(MYRULE) I suppose there m

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #3, bug #59154 (project make): Since, IN THIS CASE, the value should really only be processed once, isn't the solution to defer the expansion to the shell by using echo PUB is "$${PUB}" as the recipe? ___ Reply to

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #5, bug #59154 (project make): (To be precise, the line echo "${BLAH}" works in all the shells I've tested, and in BSD Make, but not GNU Make. If BSD Make can get this right, seems like gnu make should be able to, too.) ___

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #6, bug #59154 (project make): [comment #5 comment #5:] > (To be precise, the line >echo "${BLAH}" > works in all the shells I've tested, and in BSD Make, but not GNU Make. If BSD Make can get this right, seems like gnu make should be able to, too.) This could break a t

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #7, bug #59154 (project make): If the string isn't quoted, the first newline would naturally signal a new command to the shell, wouldn't it? Got an example of a real-world Makefile that would break? ___ Reply to this item

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #4, bug #59154 (project make): "Newlines in variable expansions are treated as real newlines in the rule." Well, yes, of course. What I didn't expect is for the command to be truncated at the first newline. The shell script BLAH="hi there" export BLAH echo "$BLAH" properly

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #10, bug #59154 (project make): I already explained below why it works the way it does... maybe my mic is not on? Am I on mute? I do that all the time on my video calls. BSD make doesn't support multiline variable definitions the way GNU make does, so it makes sense that they

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #8, bug #59154 (project make): [comment #7 comment #7:] > If the string isn't quoted, the first newline would naturally signal a new command to the shell, wouldn't it? > > Got an example of a real-world Makefile that would break? Nope. But that doesn't mean there isn't one. Th

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #9, bug #59154 (project make): I don't think this would require Make to parse double quotes. My guess is it would mean passing along expanded variables to the shell without parsing the variable contents for newlines. If I have time, maybe I'll have a look at whether my guess is

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #11, bug #59154 (project make): [comment #9 comment #9:] > I don't think this would require Make to parse double quotes. > > My guess is it would mean passing along expanded variables to the shell without parsing the variable contents for newlines. > > If I have time, maybe I'l

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #12, bug #59154 (project make): [comment #10 comment #10:] > If the variable is passed to a single shell then it will print an error at the second "cd". Eh? martind@sirius:~/tmp/make-59154$ bash -c 'cd foo && echo one cd foo && echo two' one two martind@sirius:~/tmp/make-59154

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #13, bug #59154 (project make): Yes, I said: > when there is a subdirectory "foo" which is empty. Your subdirectory "foo" is not empty, it contains a sub-subdirectory "foo" :). Basically people use define/endef to create recipes which can span multiple lines, and they expect

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #14, bug #59154 (project make): [comment #10 comment #10:] > GNU makefiles will allow the following makefile: > > > define SOMECOMMAND > cd foo && echo one > cd foo && echo two > endef > > all: ; $(SOMECOMMAND) > > > to print both "one" and "two" when there is a subdirectory

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #15, bug #59154 (project make): Also: I have great respect for the difficulty of getting stuff like this right. (I recently stared down the maw of commandline issues in response files in meson... https://github.com/mesonbuild/meson/pull/7245 ) so while I may have sounded glib, I

[bug #59154] Multiline environment variables handled poorly

Follow-up Comment #16, bug #59154 (project make): Hi Dan, using BSD make as an example in general is not a good idea since BSD make implements plenty of non-POSIX compliant "features". Since this command however works fine with SunPro Make and smake and produces the same output as bmake, it must