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

On Tue, 2014-02-25 at 00:05 +0100, Frank Heckenbach wrote:
> Let me chime in with my interpretation of Eli's suggestion. In this
> case, FOO would be stored as is (foo\ bar) with make understanding
> that (every) variable value is a string quoted according to shell
> syntax,

Yes, I understand that part.

> so this would be treated as a single word (e.g. when used in
> a prerequisite list, in $(addprefix) etc.).

Yes, I understand that as well.

It's not the parsing part I am concerned about, or even how the value is
interpreted in contexts where we know that the result should be a "list
of words":, like a target or prerequisite or a function like addprefix,
etc.: that is very clear.

> In the command-line it would also substituted as is, so no change from
> the existing behaviour here.

Ouch; this statement is not precise and this is THE CRUX of the problem.
What exactly do you mean by "substituted as is"?  As is what?

I'll refer you to my previous email with Eli where, when I asked what is
the result of this makefile:

> >   FOO = foo\ bar
> >   $(FOO): ; @echo '"$@"' '"$(FOO)"' '"$(addsuffix .txt,$(FOO))"'

His position was that it should yield this (he hoped):

> >   "foo bar" "foo bar" "foo bar.txt"

However:

> >   FOO = foo\ bar
> >   $(FOO): ; @echo '$(FOO)' > '$@'
> 
> I'd say it should run "echo 'foo\ bar' > 'foo\ bar'", i.e. write to a
> file with an embedded backslash.

OK, so this is not, after all, what I understood Eli to suggest.  I
assume from this that in the previous example, you would expect to get
output like this:

  "foo\ bar" "foo\ bar" "foo\ bar.txt"

?

What you're saying is that when a variable is expanded the backslashes
are always preserved in the expansion.  If the result of the expansion
is used in a context where make will break it up into words (for example
in a target or prerequisite list, or as an argument to a function like
addsuffix or addprefix) then make will pay attention to the backslashes
when parsing words.  If it's in some other context, the result will just
contain backslashes and it's up to the user to deal with them.

This behavior I can understand and I understand how it could be
implemented.  So the question becomes, what are the compatibility and
usage ramifications?  I'll think about that and post later.

> That's probably not what was intended, but I'd blame this on the
> users.

Well, I think it's a little harsh to blame the users for doing what 40
years of make history and portability have taught them is best-practice.