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

[Frank Heckenbach]

Just to avoid more confusion: This mail, like the ones it replies
to, talks about two different proposals, (a) some kind of encoding
(like Paul's and my suggestions) together with my SHELL_QUOTE
proposal and (b) shell-compatible quoting based on your suggestion.
I actually tend to prefer (b) now *if* it can be made to work
without breaking backward-compatibility (too much) or POSIX
requirements. Until we are sure it can, I'll also keep (a) on the
table.

Eli Zaretskii wrote:

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

Well, we clearly disagree here. But maybe it won't matter, if (b)
will actually solve "my" issue as well.

> > 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:

That's one way, but IMHO not the best way. Both (a) and (b) are less
cumbersome to the user.

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

Good, that's exactly what I had assumed in my last mail, so we agree
here.

> But this is yet another issue: $wildcard is a
> Make function, so how it formats file names with whitespace is up to
> us.

Of course it is. That's why we can discuss what it should do.

> I was talking about quoting things on command line if needed --

Actually I think you weren't talking about quoting things on command
lines only, but more generally about quoting strings in a makefile
(which also affects targets and prerequisite lists).

But that's alright. Quoted strings in makefiles and functions like
$(wildcard) are two different ways to arrive at values with embedded
spaces. (Environment variables may be another one.) We should
consider all of them.

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

I left your previous paragraph in because I can just as well say if
we make it too hard for users to get right, they will point fingers
at us ...

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

They could, but the way they are, they don't. Remember, at this
point I was discussing what can be done by the user using existing
make features. My conclusion was, it's possible (if $(addprefix)
etc. will correctly handle words with embedded spaces), but very
uncomfortable, and restrictive (no implicit rules). If we talk about
amending implicit rules, we can just as well talk about amending
other parts of make to make it more comfortable on the whole, e.g.
(a) with SHELL_QUOTE or (b).

> I also don't see
> why you need to explicitly $call your Q, why not just $(Q $<) ?

Because the latter is not valid call syntax for a user-defined
function, but rather a reference to a variable with a strange name
such as "Q foo.c".

> >   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?

That's actually my proposal (a), not only for $< and $@, but all
variables. But since the quoting depends on the shell, we must give
the user a way to customize it, even (and especially!) if it's
automatic. That's what SHELL_QUOTE would do.

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

You make it sound like I'm talking about some specific use cases.
But what I'm talking about is using these values in command lines.
That's the most general use case I can think of, since that's
basically what make is for. It's nice to do stuff internally in a
makefile, but ultimately you want to run some command. A solution
that doesn't consider this is not complete. (But again, see above,
there might be no need for us to agree here.)