Re: Quoting special characters

On Sat, 2014-02-22 at 13:27 -0800, David Boyce wrote:
> On Sat, Feb 22, 2014 at 10:43 AM, Eli Zaretskii <[email protected]> wrote:
> >> It might be better to use a quoting regime that exploits the shell
> >> rather than an independent quoting regime that operates entirely outside
> >> the shell.  People who write makefiles need to know the shell quoting
> >> rules already, so if 'make' uses compatible quoting rules it'd be one
> >> less thing to learn.
> >
> > Exactly my thoughts.
> 
> I don't agree. Recent enhancements have set make free from the
> presumption that the value of $(SHELL) is even a shell as commonly
> understood. Nowadays the recipe text can be passed blindly to whatever
> program is assigned to SHELL using the flags assigned to .SHELLFLAGS.
> True, there may be very few true shells which don't understand POSIX
> quoting but that cannot be said of the entire universe of programs
> modern make may pass its recipes to.

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'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.


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.

We'd need to look carefully at how different interpreters handle
backslashes: it's quite possible this still cannot be made portable
enough to satisfy.

Also, the backward-compatibility issues with backslashes still loom
large in my mind.