${LOCALBASE} is evaluated by make, before it gets to the shell. Quoting 
doesn't apply. In fact, the shell probably wouldn't know what to do with 
${LOCALBASE}.

     % cat Makefile
     LOCALBASE=/usr/pkg
     all:
             echo 'Result is ${LOCALBASE}';
             echo 'Result is '$${LOCALBASE}' broken';
             echo 'Unbalanced quote does not affect make
             echo 'But kills the shell;
     % make
     echo 'Result is /usr/pkg';
     Result is /usr/pkg
     echo 'Result is '${LOCALBASE}' broken';
     Result is  broken
     echo 'Unbalanced quote does not affect make
     Unbalanced quote does not affect make
     echo 'But kills the shell;
     Syntax error: Unterminated quoted string
     *** Error code 2

In the third example, make strips the quote before calling exec(3), 
apparently an imperfect attempt to emulate sh(1)'s quoting. Putting a 
shell meta-character (such as a semi-colon) in the line forces it 
through sh(1), which responds with the syntax error.

So are people using the 'xyz'${LOCALBASE}'abc' construct because of a 
misunderstanding, for some make(1) portability reason, or ???

Mike


Jonathan Perkin wrote:
> * On 2003-09-13 at 09:34 BST, Michael South wrote:
> 
> 
>>What's the reason for this?
>>
>>./audio/wmmp3/Makefile: ${SED} -e 's:/usr/local:'${LOCALBASE}':g' \
>>
>>The apparently nested single-quotes were freaky, until I figured out 
>>that the shell was interpreting it as three concatenated strings:
> 
> 
> Single quotes quote verbatim, so without the "nested" quotes you'd
> end up with a literal ``${LOCALBASE}'' rather than what the shell
> evaluates the variable to, e.g:
> 
>   $ FOO=bar
>   $ echo ${FOO}
>   bar
>   $ echo '${FOO}'
>   ${FOO}
> 


-- 
Michael South
msouth@msouth.org