[Bug 14541] sed: s-command with "semi-special" delimiters get wrong behaviour
bugzilla at busybox.net
bugzilla at busybox.net
Mon Jan 24 14:49:14 UTC 2022
https://bugs.busybox.net/show_bug.cgi?id=14541
--- Comment #2 from Christoph Anton Mitterer <calestyo at scientia.org> ---
Just for confirmation:
- Since the tests are only about s-commands, does your commit also fix the
context addresses?
- The test you added for \& handling was just about adding the missing test,
right? The behaviour itself already worked before?!
- I assume these functions were just for BRE, right?!
- Does that commit also "fix" (well POSIX is ambiguous, IMO, so its actually
more a "align with GNU sed") the following two:
a) \1 in replacement:
Consider:
s1\(x\)1\11
which, depending on what "literal" means, could be either effectively:
s/\(x\)/\1/
(BusyBox sed seems to do this:
$ printf '%s\n' 'oxo' | busybox sed 's1\(x\)1\11'
oxo
$ printf '%s\n' 'owo' | busybox sed 's1\(x\)1\11'
owo
)
or:
s/\(x\)/1/
(GNU sed seems to do this:
$ printf '%s\n' 'oxo' | sed 's1\(x\)1\11'
o1o
$ printf '%s\n' 'owo' | sed 's1\(x\)1\11'
owo
)
b) \1 in BRE (but not ERE, where \1 isn't defined for the RE part)
Consider:
s1\(xo\)\11X1
which, depending on what "literal" means, could be either effectively:
s/\(xo\)\1/X/
(BusyBox sed seems to do this:
$ printf '%s\n' 'xoxo' | busybox sed 's1\(xo\)\11X1'
X
$ printf '%s\n' 'xo1' | busybox sed 's1\(xo\)\11X1'
xo1
)
or:
s/\(xo\)1/X/
(GNU sed seems to do this:
$ printf '%s\n' 'xoxo' | sed 's1\(xo\)\11X1'
xoxo
$ printf '%s\n' 'xo1' | sed 's1\(xo\)\11X1'
X
)
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the busybox-cvs
mailing list