[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New escape method proposal (was: Re: Possible solution for special c
From: |
Eli Zaretskii |
Subject: |
Re: New escape method proposal (was: Re: Possible solution for special characters in makefile paths) |
Date: |
Fri, 14 Mar 2014 10:35:00 +0200 |
> From: Paul Smith <address@hidden>
> Cc: address@hidden
> 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.
Backslash quoting (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/03/10