Re: Quoting special characters (was: Re: Possible solution for special characters in makefile paths)

On Sat, 2014-02-22 at 22:18 +0100, Frank Heckenbach wrote:
> The problem is how to quote them for a command line. In bash (and I
> think any POSIX shell, but I'm not even sure of that), you can quote
> an arbitrary string, but not in a uniform way. There are several
> ways to do that, the simplest one (AFAIK) is to put '' around the
> string and handle ' within the string specially (close the ', quote
> the actual ' with a \, start a new ' quote for the rest of the
> string, because \ does not escape within ''; therefore the
> Q='$(subst ','\'',$(1))' in my previous mail).

Actually, for POSIX sh the simplest thing to do in general is just add a
backslash before any special character.  In fact in shell if you don't
mind doubling the size of your string you can just backslash-escape
EVERY character and be sure you're getting exactly the right thing.  But
usually we just escape the ones that are special :-).

However for writing a make function, using backslashes is a more complex
solution (requires multiple nested subst functions, one for each special
character) and single-quotes is easier.

> Yet, as I said, I'd like to see a solution to this problem. So even
> if it's not possible in a fully automatic way, the next best thing
> is to require as little user intervention as possible. This might be
> achieved with a special variable, let's call it SHELL_QUOTE, which
> has a similar status as SHELL and is applied when expanding a
> variable into a command line -- separately for each word of it(!),
> and of course also for automatic variables such as $@, $< or $^.
> 
> Unfortunately, SHELL_QUOTE couldn't be set by default because it
> would break commands with manual quoting

I was thinking about this, but I was just thinking of having a hardcoded
behavior that would be applied whenever you were using a POSIX-y shell
but could be enabled or disabled or something.

At first glance I was not sure about your suggestion, but on further
thought it does have a lot to like about it: for example by using a
variable it can have the same scope as SHELL and be set in a
target-specific variable for a given rule, etc.  It's certainly more
flexible.  I do wonder about performance but I guess construction of a
command line to run a recipe is not a performance-critical part of the
code.

Something to keep in mind, for sure.