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

Eli Zaretskii <[email protected]> Sun, 13 Apr 2014 19:04:07 +0300
Newsgroups gmane.comp.gnu.make.devel
Message-ID <[email protected]>
> From: Paul Smith <[email protected]>
> Cc: [email protected]
> Date: Sun, 13 Apr 2014 10:58:13 -0400
> 
> On Sun, 2014-04-13 at 08:26 +0300, Eli Zaretskii wrote:
> > > When expanding $(BAR) in the recipe, make cannot determine that it
> > > should remove the backslash inside '$(FOO)' but not the one in
> > > '(foo\ bar)', and if it removes the latter the script will have a syntax
> > > error.  And there are a TON of scripts like this out there (any
> > > automake-generated makefile has numerous examples).
> > 
> > Aren't these very problems solved every day in Unix shells, Lisp, and
> > even in Make itself?  You just double any literal backslash on
> > encoding, and that's it.  What am I missing?
> 
> Backward-compatibility.  If this problem had been considered and
> addressed back when makefile syntax was being created, like it was for
> the shell etc., then we wouldn't be having this conversation.  It
> wasn't, so there are hundreds of thousands of makefiles out there that
> contain unescaped backslashes in variable values.

What would those makefiles use backslashes for?  Anything other than
escaping characters special to Posix shells?

> That's really the entire advantage of the other quoting method: it uses
> entirely new syntax, rather than overlapping with existing syntax, so
> it's possible to know exactly what the user intends without ambiguity.

Then perhaps we should use that instead.