Iain Hibbert wrote:
> On Sun, 5 Feb 2006, Roland Illig wrote:
> 
> 
>>In general, use the :Q operator. But pay attention if the variable appears in
>>'single quotes', "double quotes" or `backticks`. There are subtle differences
>>in the way the shell interprets those strings, and I'm not sure yet how to do
>>it right. One popular example where pkglint could issue a warning but
>>suppresses it are sed(1) replacements:
>>
>>SUBST_SED.foo+=       -e 's,@PREFIX@,${PREFIX},g'
> 
> 
> btw in the package I was twiddling, I used something akin to
> 
> SUBST_SED.foo+=		s,@PREFIX@,${PREFIX},g
> 
> as I determined that in this case (a single editing command) the -e is not
> needed, which makes the quotes not needed either.
> 
[...]
> 
> since the place where the command line is built is in fact in subst.mk,
> can this construct not be included there rather than in the package
> Makefile?

No, at that point it's too late. Imagine what would happen if ${PREFIX} 
contained some whitespace:

     PREFIX=     C:/Program Files/pkgsrc

Then, the code in subst.mk gets the following arguments. Here I have put 
them each in a line of its own for better visibility.

     ${SED}
     s,@PREFIX@,C:/Program
     Files/pkgsrc,g
     ./Makefile.in

It is obvious that there is something wrong, and at this point, it is 
not possible to know whether there had been one space between the 
"Program" and the "Files", or a tab, or maybe even five spaces. That's 
why escaping is needed in the definition of SUBST_SED.

The other thing, omitting the "-e" if there is only one expression, will 
lead to problems as soon as someone adds another line. It will then be 
necessary to change the current line unnecessarily.

Roland