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
