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

> From: Paul Smith <[email protected]>
> Cc: [email protected]
> Date: Sat, 22 Feb 2014 13:15:46 -0500
> 
> Suppose I have a variable like this:
> 
>   FOO = "foo bar" " biz " "foo\baz"
> 
> Now I write:
> 
>   all: $(FOO)
>   $(FOO): ; @echo "'$(firstword $@)'"
> 
> What do we expect the output to be?

'foo bar'

> What if instead I do this:
> 
>   OUTPUT := $(patsubst %,echo '%' ;,$(FOO))
>   all: ; @$(OUTPUT)
> 
> ??

I'm sorry, but I don't see the problem.  Please be more explicit, I'm
not as fluent with Make tricks as you are.

> What if I do this:
> 
>   SHELL = /usr/bin/python
>   all: $(FOO)
>   $(FOO): ; @print """$@"""
> 
> ??

Why is that our problem?  _The_User_ must set up the quotes in the
command line; we cannot do this for them.  And anyway, how will your
other suggestion solve these same problems?

> > First, we don't _have_ to strip them; we could keep the quotes.  And
> > second, we could strip them, but record in the variable that it was
> > quoted.  In both cases, we will restore the quoting in the context
> > that needs them, such as when they are part of a shell command line.
> 
> Restore what quoting?  What if SHELL is set to R, or Ruby, or Lisp, or
> something with very different quoting rules than whatever make
> understands?

Then we leave the string unquoted; the user will have to do that.

> That doesn't change the fact that make may have to chop the strings
> up into words to do its job.

A quoted string is a single word.

> You're basically saying that make would need to understand the quoting
> rules for any interpreter SHELL is set to

No, only for the shells it understands now and whose quoting it
already supports on the command lines.

> Make must have its own out-of-band quoting syntax, because we cannot
> use the interpreter's quoting syntax.

I think we can do this for the shells whose quoting we understand now.

> > Why should we bother about these hypothetical use cases?  Are there
> > any real-life Makefiles that do anything like that?  If there are,
> > let's look at them, and let's understand why they need this quote
> > juggling in the first place.
> 
> No matter how unlikely a given make sequence may look to us, someone,
> somewhere will be doing it.

That goes for your other suggestion as well.  So, in itself, this
isn't an argument for or against my suggestion.

> > Exactly my point: using a backslash to escape a blank is a natural
> > extension of what we already do with a colon.  I fail to see why is it
> > so different.
> 
> It's a huge compatibility problem.  Let's take a more realistic example.
> Suppose you wanted to have a variable containing two words, "foo\" and
> "bar".  Today you write this:
> 
>   FOO = foo\ bar
> 
> Now if you want to use this as a list of targets (we'll say they're
> phony to avoid issues with real filenames, although "foo\" is a
> perfectly valid POSIX filename):
> 
>   .PHONY: all $(FOO)
>   all: ; $(FOO)
>   $(FOO): ; @echo '$@'
> 
> Running "make 'foo\'" is perfectly valid.  And maybe you want to massage
> these into URLs (having backslashes in URLs is pretty common, even
> today):
> 
>   all: ; for a in $(patsubst %,'http:\\%',$(FOO)); do echo "$$a"; done
> 
> 
> Now we come along with the next release of GNU make, and say that if a
> space is prefixed with a backslash it's no longer a word separator, but
> instead a literal space, and instead of two words, FOO is now the single
> word "foo bar".  If you want "foo\" and "bar" you have to modify your
> makefile:
> 
>   FOO = foo\\ bar
> 
> Right?

It's one possibility, yes.  Why is that a problem?  Don't we have such
a problem already with files that include colons?