Re: config.status - robust sed substitutions

[Robert Anderson]

On Wed, 2003-02-26 at 14:52, Paul Eggert wrote:
> "Robert Anderson" <address@hidden> writes:
> 
> > substvar=$( echo @var@ | sed -e "s,@var@,`_quote_for_sed $var`," )
> 
> Unfortunately this won't work for implementations of 'echo' that treat
> backslash specially.

Hmm.  I'm not sure which invocation of echo you're seeing a problem
with.  The one within _quote_for_sed was a problem; that was fixed with
a here document.

For the line you've left here, I don't see a problem.  @var@ is @var@
and can be nothing else; it's not a variable.

  POSIX 1003.1-2001 requires such behavior, and it
> is common.  I've heard that this requirement will be changed soon, but
> nevertheless we need to port to hosts that implement it.
> 
> Also, it won't work if @var@ is -n, on implementations where "echo -n"
> echoes without a trailing newline.

Hmm.  If you mean if $var is '-n', then, well, I don't think that's
right either.  That's why I used a here document - to remove the
possibility that metacharacters in $var could be evaluated in getting
them from $var to the stdin of sed.

> One workaround is to use printf if available, and fall back on echo if
> printf is not available.  Another possibility is to use expr, though
> this will require a loop.

I think a here document will do.

> But these will be portability hassles in their own right.  Perhaps
> it'd be simpler just to pick some other delimiter like '|' and live
> with its limitations.

_quote_for_sed()
{
    sed -e 's/[\&,]/\\&/g'<<_ACEOF
$1
_ACEOF
}

I don't think this (^^^) is of sufficient complexity to make it worth
living with the uncertainties of choosing another character and hoping
it doesn't cause problems.

I'll work on the actual patch and test suite case this evening, maybe
that will make things clearer and easier to evaluate for suitability.

Bob