Re: Quoting special characters

On Sun, 2014-02-23 at 14:12 -0500, David A. Wheeler wrote:
> It does seem to me that *new* make functions could greatly simplify things,
> and if they're new, there's no backwards-compatibility issue.
> E.G.:
> * functions that take strings and encode/decode them
>    in various ways (e.g., prepend backslashes for certain cases,
>    possibly surround with '...' or "...").  I think it *is* important to
>    support interpreters other than shell, but there's nothing wrong
>    with having functions that are specifically designed to support sh
>    (just be careful using them when python is your shell!).
> * Functions that return a variable value, but encoded in some way,
>    and take as a parameter the *name* of the variable.
>    There's already $(flavor variable), so variablename as parameter
>    is not unknown.  Again, a few common encodings could make things
>    easy by inserting the double-quotes and backslashes in the right places.

The real issue is not so much representing unusual characters inside of
recipes: there are already lots of options to do that (although they
could be easier to use, I admit).

The real problem is representing unusual characters in filenames in make
targets and prerequisites.  There is no reliable support for that right
now. 

The model I was proposing had an "encoding function"; it was actually a
new form of escaping (I had proposed $[...] and $`...`) but it could
just as easily (although more verbosely) be a real function, like
$(encode ...) or whatever.

And for decoding I was planning on just having that happen automatically
when the recipe string was constructed, but it's possible to provide a
real function to do it instead of or in addition to, if that seems
warranted.

> Perhaps the real problem is that people are trying to use single strings as arrays,
> made worse because the "space" character is being used as a
> *separator* between array entries, yet it's also a legitimate value.
> 
> Another approach not listed so far is allowing \0 in make strings and having
> functions that use \0 as separators in filenames.  That'd be a big change
> in strings, but then encoding is otherwise simpler (in particular, filenames
> CANNOT include \0 in POSIX systems, it's the only byte where that is guaranteed).

Hm... that would definitely be a massive change.  Almost a rewrite I'd
say.  We'd need to think very carefully about this before we embarked on
such an adventure.

Most importantly we'd still need to preserve backward compatibility and
portability via POSIX, so we can't REQUIRE people to break up lists of
filenames with \0.