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

[Paul Smith]

On Thu, 2014-04-10 at 22:55 +0200, Frank Heckenbach wrote:
> Eli Zaretskii wrote:
> 
> > > I didn't say there was a contradiction. The only one, kind of, is
> > > that I think the quoting should be done automatically by default
> > > (e.g. by having SHELL_QUOTE set by default and used automatically).
> 
> If make would define this by default and apply it automatically when
> substituting a variable in a recipe,

I have two concerns about applying quoting automatically.

> %.x: %.y
>         process $< -o $@
> Which make internally would turn into:
>         process $(call SHELL_QUOTE,$<) -o $(call SHELL_QUOTE,$@)

This is a simple case, but above you say "apply it automatically when
substituting a variable in a recipe".  What if your variable contained
an entire script; consider my example from my response to Eli:

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

   $(FOO) : ; $(BAR)

When make goes to expand the variable reference $(BAR) does it run the
equivalent of $(call SHELL_QUOTE,$(BAR))?  That can't work.

Or does make automatically call SHELL_QUOTE only the automatic
variables, and you have to do all the others by hand?  So then in the
above example we'd have to write:

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

Is that the idea?


The second issue I have is not so clear and may not be an issue but I
worry about the effort needed to create constructed pathnames.  For
example what if your rule says:

   SHELL = myinterpreter
   SHELL_QUOTE = ...something...

   foo: ; foobar $(DIR)/$@

In this case if make automatically quoted each variable we'd get the
equivalent of:

   foo: ; foobar $(call SHELL_QUOTE,$(DIR))/$(call SHELL_QUOTE,$@)

My concern is that for some shells doing this may be either very
difficult or very inefficient, compared to running the quoting on a
single "word" like this:

   foo: ; foobar $(call SHELL_QUOTE,$(DIR)/$@)

if you see what I mean.  I admit I don't have concrete example of how
this could completely fail, but it could be complicated in something
like Perl, for example, where you can't just concatenate strings by
putting them next to each other; you have to use the "." operator.  So
then would you have to do something like this:

   foo: ; foobar $(DIR).'/'.$@

instead of this:

   foo: ; foobar '$(DIR)/$@'

?