Re: Quoting special characters

On Sun, 23 Feb 2014 19:36:43 +0200, Eli Zaretskii <[email protected]> wrote:
...
> Again, you are mixing here 3 different issues, each one of which needs
> to be discussed separately.  Only the first one, namely, how to
> express these strings in a Makefile, has a clear and present danger of
> breaking Makefiles, so I suggest to discuss it first.  Then we can
> discuss how to expand those strings in commands.  And finally, we
> should talk about internal representation, since that is Make's
> internal business and cannot possibly cause any trouble, except coding
> and debugging.

I'm coming late to the party, and I'm having a little trouble separating
the various proposals.  So my apologies if my comments are out-of-scope.
But it appears that people are trying to improve how Make deals with
various "awkward" characters (spaces and backslashes in filenames, etc.).

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.

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

I don't know if these comments help, but I'm glad people are discussing the issue.

--- David A. Wheeler