[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Quoting special characters
From: |
David A. Wheeler |
Subject: |
Re: Quoting special characters |
Date: |
Sun, 23 Feb 2014 14:12:46 -0500 (EST) |
On Sun, 23 Feb 2014 19:36:43 +0200, Eli Zaretskii <address@hidden> 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
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), (continued)
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Frank Heckenbach, 2014/02/23
- Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths), Tim Murphy, 2014/02/24
- Re: Quoting special characters, Paul Eggert, 2014/02/22
- Re: Quoting special characters, Eli Zaretskii, 2014/02/22
- Re: Quoting special characters, David Boyce, 2014/02/22
- Re: Quoting special characters, Paul Smith, 2014/02/22
- Re: Quoting special characters, Eli Zaretskii, 2014/02/23
- Re: Quoting special characters,
David A. Wheeler <=
- Re: Quoting special characters, Paul Smith, 2014/02/23
- Re: Quoting special characters, Eli Zaretskii, 2014/02/23
- Re: Possible solution for special characters in makefile paths, Frank Heckenbach, 2014/02/22
- Re: Possible solution for special characters in makefile paths, Paul Smith, 2014/02/22
Internal representations (was: Re: Possible solution for special characters in makefile paths), Paul Smith, 2014/02/22