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

[Eli Zaretskii]

> Date: Mon, 24 Feb 2014 00:11:36 +0100
> Cc: address@hidden, address@hidden
> From: Frank Heckenbach <address@hidden>
> 
> Eli Zaretskii wrote:
> 
> > > > If we know that a variable was quoted, we will treat it as a single
> > > > word.  So I don't really see any serious problems here (of course,
> > > > this special handling of quoted strings will have to be coded).
> > > 
> > > Unfortunately, it's not so easy. In my example above, the value
> > > could neither be words-separated-by-spaces like now (would become 4
> > > words), nor a single word as you suggest.
> > 
> > This is only a problem because you want to solve the quoting issue at
> > the same time.  If you remove that requirement, the problem goes away.
> 
> But I don't like to remove that requirement. :)

I hear you.  We must certainly keep this goal in our minds, but we
must not, IMO, treat it as a necessary condition for a viable
solution.  If we succeed in finding a solution that satisfies that
requirement as well, fine; but it's not a must.

> Really, it's nice if make can handle filenames with spaces
> internally, but that's just half of the way since if you have such
> filenames as targets or dependencies, you usually want to do
> something with them, i.e. use them in the command line.

We could introduce a $(quote) function which would fit this bill, as a
separate part of the solution.  Like this:

  $(quote foo)      => foo
  $(quote foo\ bar) => "foo bar" or foo\ bar or 'foo bar'
  $(quote foo\"bar) => 'foo"bar' or foo\"bar

etc.

> Take this example:
> 
> FILES = $(wildcard *)
> 
> target: $(FILES)
>       cat $(FILES) > $@
> 
> Obviously, the intention of that rule is to concat all files to the
> target file. (Don't care whether that's a useful command on its own;
> in reality it might create a library from selected files or
> whatever.)
> 
> Assume there are two files, "foo bar" and "ba\z qu'x". What
> does/should happen here?

$wildcard could return “foo\ bar ba\\z\ qu\'x” (without the outer
quotes) or some such.  But this is yet another issue: $wildcard is a
Make function, so how it formats file names with whitespace is up to
us.  I was talking about quoting things on command line if needed --
this is up to the user who knows what she and her Makefile is doing.

> - With Paul's proposals (and mine, which only differ in the internal
>   encoding which as you say doesn't matter at this point) FILES
>   would contain something like "fooSEPbar ba\zSEPqu'x" which at
>   least preserves all information and can be made to work correctly
>   in the target list because make will know to decode the string
>   there.

I understand, but I'm quite sure these SEP characters will eventually
leak into the outer world and cause user aggravation.

Besides, with so many languages that support strings with whitespace,
people will point fingers at us if we don't come up with a reasonably
clean solution, hopefully similar to one of the existing ones.

>   Now the question is how to get this value into a command-line
>   correctly.

It depends on the command line.  And only the user knows what the
command line does.

>   Of course, there are many practical disadvantages: It's quite a
>   mouthful, very unintuitive and easy to get wrong, and when writing
>   generic rules (where you don't know in advance which filenames may
>   contain spaces) you'd need to apply it to each expansion of a
>   variable, including $@, $<, $^ etc. So typical simple command like
>     $(COMPILE.o) -c $< -o $@
>   becomes
>     $(COMPILE.o) -c $(call Q,$<) -o $(call Q,$@)
>   which means calling 6 make functions. And implicit rules wouldn't
>   use it, meaning they'd be useless for filenames with spaces.

I don't see why implicit rules couldn't use them.  I also don't see
why you need to explicitly $call your Q, why not just $(Q $<) ?

But even if we end up not producing quoting in implicit rules, that's
not the end of the world; remember: currently, this is simply
unworkable, so getting it to work with some minor inconveniences
should be good progress.

>   That's why I suggested SHELL_QUOTE. It's still a bit ugly, but
>   less so (if it's automatically applied per word, we don't need the
>   addsuffix/addprefix part), and it wouldn't clutter the recipies
>   which could still be written as:
>     $(COMPILE.o) -c $< -o $@
>   This removes one source of errors, and works with implicit rules.

Why not automatically quote $< and $@ by default?

> - With your proposal, I'm still not sure what FILES should actually
>   contain in this case.

See above.  But again, we are putting the carriage ahead of the
horse.  We need first to decide which Makefile syntax we shall adopt
in order to reduce backward-compatibility problems to their minimum.
If the backslash-escaping emerges as the best (or only) solution to
that, we can then proceed to solving the use cases you described.

There are no magic "eureka" kind of solutions here, and no magic
wands.  We need to proceed methodically and resolve one issue at a
time, otherwise we will never find a good solution, at least not fast
enough to put it into some future version of Make.