Re: Quoting special characters

> From: Paul Smith <[email protected]>
> Cc: Eli Zaretskii <[email protected]>, make-alpha <[email protected]>
> Date: Sat, 22 Feb 2014 19:26:42 -0500
> 
> I'm with David here.  I've seen, first-hand, people using lots of
> different interpreters with make including R, Python, Perl, and Ruby at
> least.  We can't afford to ignore these and the solution we provide
> needs to work for them as well.

I don't think anyone suggested ignoring them.  The suggestion is to
prefer users of Posix shells, something we already do for a long time.

> I've spent most of the day playing with different possibilities.  I've
> convinced myself that trying to support either single- or double-quoting
> behaviors in make variables is simply not going to work.  The issues are
> too widespread.  For example many interpreters (Perl for one) don't
> allow you to specify two strings next to each other and have them
> concatenated:
> 
>    SHELL = /usr/bin/perl
>    .SHELLFLAGS = -e
> 
>    FOO = '1 2'
>    BAR := $(addsuffix '.txt',$(FOO))
>    $(BAR): ; @print $@ . "\n" ;
> 
> If BAR is now "'1 2''.txt'" then by POSIX shell rules that's a valid
> target, but it's completely illegal Perl.  On the other hand if you use
> the right syntax for Perl:
> 
>    BAR := $(addsuffix .'.txt',$(FOO))
> 
> Now that's completely wrong for make and cannot be used as a target.  It
> could conceivably be possible to teach functions like addsuffix to
> manage quotes, so that $(addsuffix .txt,$(FOO)) gives '1 2.txt' instead,
> but I'm not so sure this can be done reliably.  Seems dodgy to me at
> best.

Again, you are mixing here 3 different issues, each one of which needs
to be discussed separately.  Only the first one, namely, how to
express these strings in a Makefile, has a clear and present danger of
breaking Makefiles, so I suggest to discuss it first.  Then we can
discuss how to expand those strings in commands.  And finally, we
should talk about internal representation, since that is Make's
internal business and cannot possibly cause any trouble, except coding
and debugging.

> If we restrict ourselves to considering backslash escaping, then the
> outlook is brighter.  Because backslashes only escape the next character
> it's a much simpler situation and many of the above confusions don't
> occur.

Then maybe backslashes are the way to go.  But again, let's consider
each issue separately, please, and this one first and foremost.