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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Sat, 22 Feb 2014 19:24:32 -0500
> 
> On Sat, 2014-02-22 at 20:35 +0200, Eli Zaretskii wrote:
> > > 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?
> 
> 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.

> In my suggestion the value of $@ would not include any quoting at all.

Likewise in mine.

> > > 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.
> 
> 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 see a problem here,
certainly not a new one.

> Not only that, but it's perfectly valid to use more than one
> interpreter in the SAME makefile, by using target-specific variables:
> 
>   do-python: SHELL = /usr/bin/python
>   do-python: .SHELLFLAGS = -c
>   do-python: ; x = [ "$@" ]; print str(x)
> 
>   do-perl: SHELL = /usr/bin/perl
>   do-perl: .SHELLFLAGS = -e
>   do-perl: ; ; @x = ( "$@" ); print "@x\n";
> 
> works fine.  If we modify these targets to contain whitespace quoted
> with a backslash, then we have problems:

But that's not what I suggested!

> If the value of $@ contains the backslash as well as the space, then
> this is wrong in Python at least (and not easy to solve either).

We are mixing 3 different things here:

 . how these strings will be specified in a Makefile
 . how they will be held/represented in Make's memory
 . how they will be expanded in a command

No one said all 3 of these must use the same method.  They probably
cannot.

> > >   all: ; for a in $(patsubst %,'http:\\%',$(FOO)); do echo "$$a"; done
> > > 
> > > 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".

> > Why is that a problem?  Don't we have such a problem already with
> > files that include colons?
> 
> I don't understand the question.  How can a behavior which has
> previously existed in GNU make count as a backward-compatibility
> problem?  We don't have a problem with backslashed colons because that's
> how make currently works, of course.

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.

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

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