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

[Paul Smith]

On Tue, 2014-03-11 at 19:32 +0200, Eli Zaretskii wrote:
> > I don't see any Pandora's box here: these variables will be specifically
> > reserved for make internally and make will know that their values will
> > be encoded, and all other values will not be encoded.
> 
> Environment variables are visible to any program that calls getenv.
> Their being reserved for Make doesn't mean some script out there won't
> look at them.

What does it matter if some script looks at them?  There are lots of
things in a typical user's environment today which they can see, but
should not touch (without breaking something), and don't need to
understand.

However, this doesn't matter much to me.

> > > > Encoded characters would not be considered to match the un-encoded
> > > > characters for the purposes of $(subst ...) etc.  So for example, given
> > > > this makefile:
> > > > 
> > > >    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 :".

> Why can't Make figure this out itself? why place the burden on the
> user?

Figure what out?  Can you give an algorithm or heuristic make could use
for this figuring-out?

> > And, I think this is extremely useful.  Consider for example whitespace;
> > there are clearly situations where you want to substitute _embedded_
> > whitespace in a filename but NOT substitute "normal" whitespace that
> > separates words (or, vice versa).
> 
> I don't see why we would need to provide such a feature.

I just gave an example of such a need.

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

> I think the price in complexity is significant.

What type of complexity are you referring to?  From an implementation
standpoint it's 100% free (which is what I mean by "a natural
consequence").  In fact, it would take a significant amount of effort to
AVOID this behavior.

> > However, I was wondering if we might want to make the interfaces a
> > little more abstract, and change the types going across the API from the
> > current "char*" to something like "gmk_string" or similar, then have
> > explicit functions to convert from a "gmk_string" into a "char*" (which
> > might involve decoding).  While that's appealing from a type-safety
> > point of view, it does mean that we'll need to provide a suite of
> > functions that can perform useful operations on a "gmk_string" type,
> > which would be annoying.
> 
> I think we indeed should do this.  I don't think this would be
> annoying, though.

By "annoying" I mean I predict it will become the next area where people
will be constantly asking for new functions to be added to the API
because the existing ones don't meet their needs.