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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Tue, 11 Mar 2014 01:13:41 -0400
> 
> On Mon, 2014-03-10 at 19:15 +0200, Eli Zaretskii wrote:
> > > From: Paul Smith <address@hidden>
> > > Date: Sun, 09 Mar 2014 20:10:15 -0400
> > > 
> > > In addition, the following would automatically be encoded by make:
> > >       * The results of the $(wildcard ...) function
> > >       * Any goal targets provided on the make command line
> > 
> > "Encoded" or "quoted"?  It sounds like you use these two
> > interchangeably, which is slightly confusing, since the former refers
> > to internal storage (a subject which you suggested to leave aside).
> 
> I agree I may have been sloppy in some cases and I will try to be more
> careful about this.  However, in the above situation I think "encoded"
> is correct: what make stores will be encoded strings.

It is still better, IMO, to use "quoted" here, because conceptually,
that's what Make does: it quotes these strings automatically, and then
they are encoded by virtue of being quoted.

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

> Another option, of course, is to decode the values back into quoted form
> (that is, convert them back to $[foo bar] format) and put the quoted
> form into the environment.

That's what I think we should do.

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

I wouldn't describe this consequence as "natural".

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

> 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.  Users won't
expect that, because, e.g., they have no such things when they
manipulate file names in shell scripts.

I think the price in complexity is significant.

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