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

[Frank Heckenbach]

Paul Smith wrote:

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

And if you don't mind making your command-lines absolutely
unreadable. It might be a minor concern, but if we do something like
this by default, and make runs (and echoes) a simple compile command
like this, though technically correct, people might think we're
crazy. ;)

\c\c \-\W\a\l\l -o \f\o\o.o \f\o\o.c

> But usually we just escape the ones that are special :-).

Which adds more dependency on the type of shell (which characters
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.

Indeed, without regex (or some other form of character-set)
replacements, this gets heavy.

But these are all details. In any case, it is possible to escape any
given string to POSIX sh.

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

That's the idea. (I hadn't thought about target-specific variables,
but it's another pro.)

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

Probably not, but it's actually somewhat more efficient than having
the user do all the quoting manually (cf. my other mail).