See also http://austingroupbugs.net/view.php?id=262 and http://austingroupbugs.net/view.php?id=264.
* doc/autoconf.texi (Limitations of Usual Tools) <sed>: Mention limitations of sed -e. Signed-off-by: Eric Blake <[email protected]> --- > > +In practice, however, it is portable to pass fragments to separate > > +...@option{-e} options that each represent full @command{sed} commands, > > +even if that is not specified by Posix: > The distinction between the case that fails in practice and the case > that works in practice is not clear. In the previous mail you said > that the criterion was whether some of the scripts end in a trailing > backslash. It would help to say this in the text. > > Also, you talk about "full @command{sed} commands" but then the example > has a '}' which is not a full sed command. Can you find a clearer wording? Your request for clearer wording brought back a memory I had about an Austin group meeting a couple of years ago that decided that addresses should be allowed inside { } sequences - it was an unfortunate wording choice between "function" (such as s///) and "editing command" (such as /addr/s///). But although that Austin Group decision was made in 2008, it did not make it into POSIX 2008 (see the links above, including a bug report I filed tonight to rectify that situation). At any rate, I'm pushing this, which I think addresses your concerns. ChangeLog | 7 +++++++ doc/autoconf.texi | 14 ++++++++------ 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 024a835..b0cf95e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-06-22 Ralf Wildenhues <[email protected]> + and Eric Blake <[email protected]> + + Document a mostly-portable sed trick. + * doc/autoconf.texi (Limitations of Usual Tools) <sed>: Mention + limitations of sed -e. + 2010-06-22 Bruno Haible <[email protected]> Document how to use literal newlines in makefile rules. diff --git a/doc/autoconf.texi b/doc/autoconf.texi index d112dc7..5727ded 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -18257,7 +18257,8 @@ Limitations of Usual Tools option to be a syntactically complete script. GNU @command{sed} allows to pass multiple script fragments, each as argument of a separate @option{-e} option, that are then combined, with newlines between the -fragments, and a future Posix revision may allow this as well. For +fragments, and a future Posix revision may allow this as well. This +approach is not portable with script fragments ending in backslash; for example, the @command{sed} programs on Solaris 10, HP-UX 11, and AIX don't allow splitting in this case: @@ -18270,9 +18271,9 @@ Limitations of Usual Tools @end example @noindent -In practice, however, it is portable to pass fragments to separate -...@option{-e} options that each represent full @command{sed} commands, -even if that is not specified by Posix: +In practice, however, this technique of joining fragments +through @option{-e} works for multiple @command{sed} functions within +...@samp{@{} and @sa...@}}, even if that is not specified by Posix: @example @c The quote around the closing brace silences interactive zsh. @@ -18280,11 +18281,12 @@ Limitations of Usual Tools b @end example -Commands inside @{ @} brackets are further restricted. Posix says that +Commands inside @{ @} brackets are further restricted. Posix 2008 says that they cannot be preceded by addresses, @samp{!}, or @samp{;}, and that each command must be followed immediately by a newline, without any intervening blanks or semicolons. The closing bracket must be alone on -a line, other than white space preceding or following it. +a line, other than white space preceding or following it. However, a +future version of Posix may standardize the use of addresses within braces. Contrary to yet another urban legend, you may portably use @samp{&} in the replacement part of the @code{s} command to mean ``what was -- 1.7.0.1
