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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Sun, 23 Feb 2014 16:09:58 -0500
> 
> > But again, let's first find the best way of expressing such strings in
> > a Makefile, and get to their expansion after that.  These are two
> > separate issues.
> 
> It would be nice if that were true, but IMHO it's not really the case.
> In fact these issues are only partially separable, because some methods
> of expression in the makefile imply massive problems if we want to have
> a particular expansion.

They are not entirely separable, but they can surely be addressed
separately, one after the other.  That is what I meant.

If we try to resolve all the issues together, we risk going in
circles, confusing ourselves, and never converging to a solution.

Since the Makefile syntax has the most potential to break backward
compatibility, I suggest (again) to resolve that issue first.

>    FOO = foo\ bar
>    BAR = case '$@' in (a\ b) echo '$(FOO)' ;; esac
> 
>    $(FOO): ; $(BAR)
> 
> We have said that we would like the expansion of $(FOO) to be simply
> "foo bar", without a backslash.
> 
> So that would mean that the expansion of $(BAR) would have to remove the
> backslash in the case statement, too: make cannot know whether the
> variable is being expanded to be used as a filename, or for some other
> reason.  That gives this result:
> 
>   case 'foo bar' in (a b) echo 'foo bar' ;; esac
> 
> which is a syntax error.

Sorry, why is this a syntax error?

> This is what I was trying (badly) to get at before.  In this scenario
> every single instance of backslash-whitespace anywhere in a makefile
> must be modified to quote the backslash.  The above instance of BAR must
> be rewritten as:
> 
>    BAR = case '$@' in (a\\ b) echo '$(FOO)' ;; esac

Then why didn't the user write just that?

> Now, instances of backslash-whitespace are not rare at all; in fact
> I find them in every single automake-generated makefile including
> the one that is used to build GNU make itself:
> 
>   am__make_running_with_option = \
>     ...
>       case $$MAKEFLAGS in \
>         *\\[\ \   ]*) \
>     ...
> 
> Not only that, but this would be incompatible with all other versions of
> make out there, and further it would violate POSIX requirements.  A
> POSIX-conforming make, given the makefile:
> 
>    FOO = a\ b
>    all: ; @echo '$(FOO)'
> 
> MUST print "a\ b".  It CANNOT print "a b".

You are just collecting use cases we need to address.  Which is good,
but I still see no catastrophe in these seemingly complicated
requirements.  That naive expansion doesn't quite get it is not a sign
that we should give up.  Did you really think this will be easy?

> > > The fact is that colons ARE rare in filenames.
> > 
> > Not on Windows ;-)
> 
> Very true, and you'll note we don't ask everyone to escape the colons in
> their Windows drivespecs ;-)

Exactly.  Which means that with enough heuristics, a solution might
present itself in this case as well.

> There's no way $[ could possibly conflict with a command line: that's
> because make's "$" escaping is escaping done right and make's backslash
> escaping is escaping done badly.
> 
> In any make recipe today, $[ is a make variable reference.  Always.
> Even if the variable is not set, it's still a variable reference and it
> can never, ever refer to any command like "[" or whatever.  There can be
> no conflict with the command line.

If you are saying that $[string with spaces] is another candidate that
we should consider, I agree.  If you are saying something else, I'm
afraid I didn't get it yet.