Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> 3) echo 'abc' | sed 's1a\(b\)c1A\1C1g'
>> a) A1C
>> GNU
>> b) AbC
>> AIX, Darwin, FreeBSD, HP-UX, IRIX, NetBSD, OpenBSD, Solaris, Tru64
>
> Hmm, so on the RHS on the other hand the string is passed as-is. It
> is interesting that for digits, GNU sed is the only one to follow
> Paul's interpretation ("\x produces literal character x") of
> SUSv3. :-)
I see what you're saying about the part I quoted being too strong.
But there's another part of the standard that suggests that AIX,
Darwin, etc., are conforming here, and that GNU is not conforming.
The standard also says:
The special meaning of '&' in this context [i.e., in the
replacement string] can be suppressed by preceding it by a
backslash. The characters "\n", where n is a digit, shall be
replaced by the text matched by the corresponding backreference
expression. The special meaning of "\n" where n is a digit in this
context, can be suppressed by preceding it by a backslash.
So, in 's&foo&\&&', the backslash suppresses the special meaning of
'&'. But in 's1a\(b\)c1A\1C1g', the '\1' retains its special meaning
because it is not preceded by a backslash. Admittedly this language
is not ironclad, but I think the intent is clear.
Anyway, regardless of the standards-lawyerese, it does appear that GNU
sed is incompatible with traditional sed in its behavior with the rhs;
I don't see the advantage of the incompatibility.
