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

[Paul Smith]

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.

In my suggestion the value of $@ would not include any quoting at all.
It would be identical, character for character, with the target name
(the real name of the file on the disk for example).  It would be up to
the user writing the recipe to quote it properly for whatever
interpreter they were using.

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

  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";

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

> > Today you write this:
> > 
> >   FOO = foo\ bar
> > 
> > Now if you want to use this as a list of targets:
> > 
> >   .PHONY: all $(FOO)
> >   all: ; $(FOO)
> >   $(FOO): ; @echo '$@'
> > 
> > Running "make 'foo\'" is perfectly valid.  And maybe you want to massage
> > these into URLs (having backslashes in URLs is pretty common, even
> > today):
> > 
> >   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.

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

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.

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.