Bug 219409 - multi-line commands don't work when SHELL is set
multi-line commands don't work when SHELL is set
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: make (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Machata
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-12 17:37 EST by Ian Collier
Modified: 2015-05-04 21:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-22 12:58:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a Makefile showing the problem (72 bytes, text/plain)
2006-12-12 17:37 EST, Ian Collier
no flags Details

  None (edit)
Description Ian Collier 2006-12-12 17:37:22 EST
Description of problem:
make 3.81 differs in how it treats multi-line statements depending on whether or
not the SHELL is specified.  It didn't do this in 3.80.

Version-Release number of selected component (if applicable):
make-3.81-1.1

How reproducible:
Always

Steps to Reproduce:
1. Use the attached Makefile
2. make
3. Un-comment the first line
4. make
  
Actual results:
First run:
for i in one two three; do \
                echo $i; \
        done
one
two
three

Second run:
for i in one two three; do \
                echo $i; \
        done
/bin/sh: -c: line 1: syntax error: unexpected end of file
/bin/sh: line 1:        echo $i; \: command not found
/bin/sh: -c: line 2: syntax error near unexpected token `done'
/bin/sh: -c: line 2: `done'
make: *** [all] Error 2

Expected results:
Same both times, no syntax error

Additional info:
Since the docs say that when SHELL is not set, /bin/sh is used, I wouldn't
expect a difference.  Indeed, the docs say that every Makefile should set the
SHELL to /bin/sh (section 14.1, "General Conventions for Makefiles").  However,
tracing shows that when SHELL is set, make invokes an extra shell like this:

/bin/sh -c "\"/bin/sh\" -c for\\ i\\ in\\ one\\ two\\ three\\;\\ do\\ \\\\\n..."

That part hasn't changed since 3.80, though.  What has changed is the treatment
of line-ends.  The newlines are passed without quoting them, so they are
interpreted by the outer shell instead of the inner shell.  The inner shell only
ever gets the first line of the command; the outer shell gets the rest of the
lines as quoted strings and thus usually can't execute them.

Eliminating the double shell would fix this in the case that SHELL=/bin/sh. 
However, single-quoting the newlines might also fix it:

/bin/sh -c "\"/bin/sh\" -c for\\ i\\ in\\ one\\ two\\ three\\;\\ do\\ \\\\'\n'..."

The Makefile mentioned above, which I'll also try to attach, is as follows:

#SHELL="/bin/sh"
all:
        for i in one two three; do \
                echo $$i; \
        done
Comment 1 Ian Collier 2006-12-12 17:37:22 EST
Created attachment 143470 [details]
a Makefile showing the problem
Comment 2 Petr Machata 2007-02-21 11:59:25 EST
Confirmed.  Didn't find anything relevant in documentation.  Didn't find related
bug upstream, only several bugs with backshlash-eol handling.  The problem
arises when shell program, or any of its arguments, contain non-path characters.
 In that case, another shell is invoked, and whole command is passed through
that. This includes e.g. cases when SHELL contents is quoted or back-ticked. 
White space is handled just fine, make will consider them argument separators.

This works:

SHELL:=/usr/bin/env python
all:; @print 6,\
	 5

This fails:

SHELL:=/usr/bin/env ""python
all:; @print 6,\
	 5
Comment 3 Petr Machata 2007-02-22 12:58:59 EST
Fixed in rawhide.

Note You need to log in before you can comment on or make changes to this bug.