Re: Output quoting (was: Re: Possible solution for special characters in makefile paths)

On Sun, 2014-04-13 at 19:04 +0300, Eli Zaretskii wrote:
> > Backward-compatibility.  If this problem had been considered and
> > addressed back when makefile syntax was being created, like it was for
> > the shell etc., then we wouldn't be having this conversation.  It
> > wasn't, so there are hundreds of thousands of makefiles out there that
> > contain unescaped backslashes in variable values.
> 
> What would those makefiles use backslashes for?  Anything other than
> escaping characters special to Posix shells?

Either way make cannot determine which ones are there only to escape
characters important to make and which are there because they're needed
for the shell.

However, yes, there are instances where the backslash is passed to a
program that the shell invokes, and they are important to that program.

For example, here's an (elided) variable assignment that appears in the
Makefile that automake generates and is shipped with GNU make itself
(see Makefile.in in the distribution):

1|  am__make_running_with_option = \
2|    [...] \
3|      case $$MAKEFLAGS in \
4|        *\\[\ \   ]*) \
5|          bs=\\; \
6|          sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
7|            | sed "s/$$bs$$bs[$$bs $$bs   ]*//g"`;; \
8|      esac; \
0|    [...]

Here we can see backslashes used for various purposes in the shell
script.  In lines 4 and 5 the backslash is doubled to match itself.  In
line 4 backslashes are used to escape a space and a TAB (I think the
paste of this into this email lost the TAB, but it's there in the
makefile).  These are escaping from the shell.

And in line 6 we see backslash used inside single quotes to send the
literal token \n to the printf program, to represent a newline.


And this doesn't even start to address the situation where SHELL is not
a POSIX shell.