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

[Paul Smith]

On Wed, 2014-04-09 at 18:18 +0300, Eli Zaretskii wrote:
> > From: Paul Smith <address@hidden>
> > Date: Wed, 09 Apr 2014 09:41:21 -0400
> > 
> > The interpreters are where things get hairy.  The problems are many.
> > First, there's the fact that we don't know how to quote properly for any
> > random interpreter: they all have different rules.  They even have
> > different characters which are considered "special" and in need of
> > quoting!
> 
> We've been there during past discussions.  My opinion is: decode the
> string, and let the user quote it if needed.

We had decided before that if we use backslash quoting then decoding by
removing backslashes from the string is not a viable option.

That's because when decoding a string which is encoded merely by
backslashes, make can't tell which backslashes should be removed and
which should be kept, and removing backslashes in some contexts will
cause massive breakage.

Remember the examples from before:

   FOO = foo\ bar
   BAR = case '$(FOO)' in (foo\ bar) echo $@;; esac

   $(FOO) : ; $(BAR)

When expanding $(BAR) in the recipe, make cannot determine that it
should remove the backslash inside '$(FOO)' but not the one in
'(foo\ bar)', and if it removes the latter the script will have a syntax
error.  And there are a TON of scripts like this out there (any
automake-generated makefile has numerous examples).

If we say we're going to remove all backslashes (or even just all
backslashes that quote characters special to make) as part of our
"decode" step then we're telling users they cannot use backslashes in
their recipes: they must choose a different quoting method, because make
will be messing with any backslashes that appear in recipes.