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

> From: Paul Smith <[email protected]>
> Cc: [email protected]
> Date: Tue, 11 Mar 2014 19:41:31 -0400
> 
> 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.

I understand your point, but bitter experience has taught me that
users have a weird tendency of breaking our best (or worst ;-)
expectations in what they do with the opportunities our software
leaves for them as low-hanging fruit.  So I think we should not open
that door.

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

That it needs to search both un-encoded and encoded versions of the
character.

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

I believe I just did.

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

I meant complexity from the user POV.

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

The number of such functions is bound by the C library functions that
deal with C strings, I think.  So they aren't too many.