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

[Paul Smith]

On Sun, 2014-02-23 at 19:31 +0200, Eli Zaretskii wrote:
> > My understanding of your suggestion is that $@ would include whatever
> > quoting characters were used in the makefile; this quoting complies with
> > POSIX quoting rules for example.  If the interpreter being used as SHELL
> > does not understand POSIX quoting, then the user is up a creek.
> 
> No, that's not my suggestion.  I said the user must set up the quotes
> in the command line, not in the original variable.

OK, thanks for clarifying that.  I wasn't clear on this.  Let me ask
this: if I have the following makefile:

  FOO = foo\ bar

  $(FOO): ; @echo '"$@"' '"$(FOO)"' '"$(addsuffix .txt,$(FOO))"'

In your suggested implementation what is printed?  As far as I can see
it will be one of these three (assuming that $@ is "foo bar" as we've
discussed here):

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

?

> > That is a non-starter.  Pretty much ANY interpreter can be used with
> > make now.
> 
> The users of such shells are already offered less wisdom in Make than
> it offers for shells it understands.

I don't think that's true.  The only way I can think of that make treats
POSIX shells specially is that it can sometimes use the fast path while
non-POSIX shells always use the slow path.  But that difference is
completely invisible to the user; the user doesn't get any wisdom from
it except slightly faster builds.

I guess there is one other special feature in ONESHELL (ignoring special
chars at the beginning of interior command lines in the recipe), but
this is just a way to make it easy to switch ONESHELL on and off.

> > > > Now we come along with the next release of GNU make.  If you want
> > > "foo\" and "bar" you have to modify your
> > > > makefile:
> > > >   FOO = foo\\ bar
> > > > Right?
> > 
> > > It's one possibility, yes.
> > 
> > I'd like to hear another one.
> 
> Another one is FOO = "foo bar".

Well, in any event you're still forced to modify the makefile; that's
what I was getting at.

> That's not my interpretation of the current situation.  My
> interpretation is that we do have problems, but we ignore them because
> colons in file names are rare.

I think that's a very accurate assessment of the situation with colons.
However, I don't think saying that we've managed to live with the
problems with colons so it's OK to extend those same problems to
whitespace, is necessarily the right answer.

The fact is that colons ARE rare in filenames.  Whitespace, though, is
not.

> > If we start adding new special characters that are now escaped by
> > backslashes and previously were not, then by definition that changes the
> > behavior of any makefile that contains a backslash in that context.
> 
> No one argues that behavior will not be changed.  I thought we were
> discussing how best to implement this so that it is (a) convenient for
> users and (b) breaks as few Makefiles as possible (in that order).

I might quibble about the order, given my scars from previous
compatibility breaks :-), but definitely these are the top priorities
and ideally we'd find a solution where the conflict between them is not
too great.

> > The difference between this and $[ is that (a) backslashes are much more
> > common than someone using "[" as a make variable, and (b) assigning to
> > [ can be detected by make and a warning or error generated, so users
> > know that there is a backward compat problem.  Adding new backslash
> > quoting leads to silent changes in behavior.
> 
> There's a program called [.exe on my disk, did you consider that?

There's a program called "[" on my disk, too... :-).  But I don't see
how that conflicts with the make variable $[... ?