Re: New escape method proposal (was: Re: Possible solution for special characters in makefile paths)

[Paul Smith]

On Fri, 2014-03-14 at 10:35 +0200, Eli Zaretskii wrote:
> > > > > >    FOO = $[foo::bar]::baz
> > > > > > 
> > > > > >    X := $(subst   :,  -, $(FOO))
> > > > > >    Y := $(subst $[:], -, $(FOO))
> > > > > > 
> > > > > > $X will give "foo::bar--baz", and $Y will give "foo--bar::baz".
> > > > > 
> > > > > Can you explain why this is needed?  It sounds complicated and
> > > > > confusing.
> > > > 
> > > > It's a natural consequence of the encoding process, since by definition
> > > > ":" will not be the same as "encoded :".
> > >
> > > Users won't expect that, because, e.g., they have no such things when
> > > they manipulate file names in shell scripts.
> > 
> > I don't agree.  Shell scripts have straightforward ways to handle lists
> > of "words" containing whitespace and other special characters, and they
> > have many ways to manipulate these words individually ("replace each
> > space in the first word with an underscore, but not the second word").
> > Users will absolutely expect to be able to perform similar operations
> > using the make "subst", "filter", etc. functions.
> 
> Then let's provide that, but why do it by having 2 variants of each
> character?  That's a case of a leaky abstraction, IMO.

I disagree.

Maybe I can try to explain how I see this and that will help.

What I'm after conceptually with $[] quoting is creating new,
*different* "characters" for characters that are special to make.  These
are not the same characters as the user wants to appear in her recipe.
Make is using one character, $[ ], to represent a space that's part of a
word, and A COMPLETELY DIFFERENT character, " " or ASCII 32, to
represent a space that's a word delimiter.  Ditto with the other special
characters.

This is not just an internal encoding concept: it's visible in makefiles
and I think people writing makefiles should think about it exactly like
this.  I don't think it will be possible for make to just "do the right
thing" and keep makefile authors from having to understand this (if they
want to support filenames with special characters).

Any blurring of the lines between these two characters would lead to
more confusion than the alternative, IMO.