Re: config.status - robust sed substitutions

[Robert Anderson]

On Wed, 2003-02-26 at 15:43, Paul Eggert wrote:

> > 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.
> 
> It's not a question of complexity; it's a question of reliability and
> portability.

Ok, we agree on that.

> Here-documents are dangerous; we've learned this from
> experience.

There are 24 different here-documents in status.m4 to generate
config.status, so it seems like no compromise unless I'm doing something
which specifically triggers bugs or limitations in some here-document
implementations.  Perusing the autoconf docs, I'll take a closer look at
size limitations.

> If you don't like '|', how about tab?  It's reasonable to prohibit
> tabs in file names.

I'd agree, but remember that the RHS of these substitutions is not only
filenames.  There's also other text, as in $configure_input, for
example.

The choice of tab is an interesting one; I'd be more worried about the
portability of that than a here-document (possibly unfounded, I dunno). 
Not to mention the "huh?" factor in source readability.

However, note that _any_ new choice of delimiter will not only fail for
the case of the chosen character, but will also fail for the characters
'@' and '\' which are always metacharacters on the RHS of a sed
expression.  I've seen '@' in particular in pathnames out in the wild;
it's a good prefix to get files to sort to the top of an 'ls'.

With a preprocessing step, you can solve all three problems
simultaneously (arbitrary delimiter, '@', and '\').

Bob