rehashing the discussion here:
<http://thread.gmane.org/gmane.comp.gcc.devel/108348/focus=108368>

* Eric Blake wrote on Mon, Aug 31, 2009 at 01:36:07PM CEST:
> True.  I guess I'll find time to visit this patch, if no one beats me to it.

Lemme try to beat you to it.  It seems that that a sweep over the
documentation to remove ',' as sed 's' separator was not necessary,
since we used constant regular expression strings mostly (as opposed
to expanded shell variables containing files names or so).

So I think this should document things appropriately.  Any further
comments before I apply (tomorrow or so) and add Dave to THANKS
(which email address should I use)?

Thanks,
Ralf

    Document sed limitation with escaped metacharacters.
    
    * doc/autoconf.texi (Limitations of Usual Tools) <sed>: Use `%'
    rather than `/' in an example `s' command.  Document
    inconsistent treatment of escaped metacharacters.
    * THANKS: Update.
    Report by Dave Korn, with additional input from Paolo Bonzini
    and Eric Blake.

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 2ab40c9..786e263 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17534,7 +17534,11 @@ Limitations of Usual Tools
 @prindex @command{sed}
 Patterns should not include the separator (unless escaped), even as part
 of a character class.  In conformance with Posix, the Cray
-...@command{sed} rejects @samp{s/[^/]*$//}: use @samp{s,[^/]*$,,}.
+...@command{sed} rejects @samp{s/[^/]*$//}: use @samp{s%[^/]*$%%}.
+Even escaped, patterns should not include separators that are also used
+as @command{sed} metacharacters.  For example, GNU sed 4.0.9 rejects
+...@samp{s,x...@{1\,\...@},,}, while sed 4.1 strips the backslash before the 
comma
+before evaluating the basic regular expression.
 
 Avoid empty patterns within parentheses (i.e., @samp{\(\)}).  Posix does
 not require support for empty patterns, and Unicos 9 @command{sed} rejects


Reply via email to