[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Output quoting (was: Re: Possible solution for special characters in
From: |
Eli Zaretskii |
Subject: |
Re: Output quoting (was: Re: Possible solution for special characters in makefile paths) |
Date: |
Sun, 13 Apr 2014 19:04:07 +0300 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> 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.
Re: Output quoting (was: Re: Possible solution for special characters in makefile paths), Frank Heckenbach, 2014/04/10
Re: Output quoting (was: Re: Possible solution for special characters in makefile paths), Eli Zaretskii, 2014/04/10