[bug #59247] function shell eats a newline

[Paul D. Smith]

Follow-up Comment #3, bug #59247 (project make):

This behavior is not related to bug #59395; that issue has to do with how
target recipes are split into individual command lines.  This issue is
discussing how an individual command line (or in this case the arguments to
the shell function) are handled when they are sent to the shell (or not).

However, I am also not sure that the provided patch is correct.  This will
always convert a newline to a space, regardless, which may not be correct in
all situations (consider single-quoted strings for example).

I think there's a larger problem here.  Consider this makefile:


x := $(shell echo $(FOO))
all:;: x='$x'


The original request clearly expected that FOO would be treated the same way
as a shell variable.  In the shell you'd get this:


$ FOO='
foo
bar
'

$ echo $FOO
foo bar


But, it's not a shell variable it's a make variable!  Make variables are
expanded by make, before invoking the shell, and they don't follow the same
escaping and quoting rules as the shell does.  So, if we have the above
makefile and we run it like this:


$ make FOO='
foo
bar
'


then I'd expect that make would invoke the equivalent of this shell command:


/bin/sh -c 'echo 
foo
bar
'


and that would yield errors because the commands "foo" and "bar" cannot be
found.

Of course, if we had a makefile like this:


x := $(shell echo "$(FOO)")
all:;: x='$x'


(with quotes) then this would be the shell invocation:


/bin/sh -c 'echo "
foo
bar
"'


and the results (after newlines are converted on the output as discussed in
the manual) would be " foo bar"

So, I'm a bit unsure how to proceed here.  Clearly the current behavior is not
right, where adding a semicolon gives different output : the slow-path is
causing issues.  But I'm not sure that fixing it to work completely correctly
wouldn't be an issue with compatibility even though it's the right thing to
do.

The problem is the overly complex way that make invokes subshells in the "slow
path".  The slow path should be the SIMPLEST solution but instead it's more
complicated and I'm not sure why.  It's not documented anywhere how shell will
handle _input_ strings that contain newlines; it only talks about _output_
newlines, so I think that this behavior is more of an unanticipated result of
how the parsing is done than anything intended.  Which doesn't mean that it
won't be a backward-compatibility problem to change it.

I'll need to think about this a bit.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59247>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/