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

[Paul Smith]

On Sun, 2014-03-02 at 11:38 -0500, Paul Smith wrote:
> On Thu, 2014-02-20 at 03:22 -0500, Paul Smith wrote:
> > Hi all.
> 
> Thanks for participating so far.

This thread is for discussing the alternative quoting proposal, put
forth by Eli.  This proposal would take the current handling of
backslashes to quote special characters (see my previous post on this
subject) and extend it.

Each special character that we'd like to quote would be prefixed with a
backslash in the makefile.  Backslashes would quote themselves.

In addition, the following would automatically be quoted by make, by
prefixing any special characters in them with backslashes as they are
internalized by make:
      * The results of the $(wildcard ...) function
      * Any goal targets provided on the make command line


All make internal functions and string manipulations that treat any
character in a special way would ignore any instance of that character
which was quoted by a backslash.  In all other ways, backslashes will be
treated like any other character: they won't be removed or modified.
This includes when the variable is expanded in a recipe context.

For example, if you have:

   FOO = foo\ bar

   $(FOO) : $(FOO).x; case $@ in ($(FOO)) echo $(@:%=%.txt) ;; esac

The places where the string "foo\ bar" is considered "special to make"
are in the target, prerequisite, and in the pattern substitution.  So,
the above defines a rule for the target "foo bar" which has one
prerequisite "foo bar.x", and where the recipe expands to this:

   case foo\ bar in (foo\ bar) echo foo\ bar.txt ;; esac

which is, to be sure, kind of nice.


When considering backward-compatibility, we would be changing the way
backslashes currently behave (see my previous email from last week about
this behavior): today when a make string is "expanded" in a makefile
context (as a target or prerequisite for example) any backslashes are
removed from the string at that time, and the value of $@ or $< or
whatever gives the backslash-removed string.  In the new environment
that would change and the backslashes would be preserved.


Advantages to this model:
     1. Uses a quoting method most users are already familiar with.
     2. Strings are already quoted properly for UNIX shell syntax when
        they are expanded, no need for recipes to add quoting for
        special characters.

Disadvantages to this model:
     A. Backward-compatibility issues: any place a backslash is used
        currently in a makefile target or prerequisite will likely need
        the recipe to be modified to ensure correct behavior.
     B. We'll need to do something about the quoting when dealing with
        alternative settings of SHELL, for interpreters which do not
        handle backslashes the same way the UNIX shell does.  This could
        be a tricky problem, because we don't know which backslashes are
        intended and which are there to quote special characters.
     C. Either all of make's internal code must be enhanced to ignore
        backslash escape sequences, or else we'll need to do encoding /
        decoding similar to what was described in the other proposal.
     D. Although not strictly necessary in this case, I expect we would
        need to provide some sort of help for the C and Guile API
        interfaces as well.