[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