On 8/6/26 21:30, G. Branden Robinson via busybox wrote:
[looping in busybox mailing list; Bruno found a sed portability problem]
Background:
https://savannah.gnu.org/bugs/?68601
Hi Bruno,
At 2026-08-06T18:07:55+0200, Bruno Haible wrote:
I wrote:
The reason is that the 'sed' program on this platform (from BusyBox)
ignores '-e' options when a '-f' option is present, regardless
whether the '-e' options come before or after the '-f' option.
Which apparently nobody noticed for 20 years.
Addendum: This is not the case in general, but is the case with this
particular '-f' script and these particular '-e' options.
I didn't experiment to determine the issue, but the following change in
wording from POSIX Issue 4 to Issue 8 might account for the discrepancy.
Issue 4:
−f script_file Add the editing commands in the file script_file
to the end of the script.
Issue 8:
−f script_file Add the editing commands in the file script_file
to the end of the script of editing commands.
I wonder what alternative script the Busybox developers have in mind.
I rewrote busybox sed almost from scratch back in 2003 (and then wrote
another one for toybox from scratch in 2014).
In toybox I didn't preserve -e and -f order because the option parsing
plumbing collates -e and -f into two lists before the command runs and
then sed_main() goes through the lists in a second pass, at which point
reconstructing what order interleaved sed -e -f -e happened in would
require extra work and I didn't bother to add code for it until somebody
complained. Hmmm, it looks like somebody finally did complain in 2022
and I bothered to do the work (in toybox) here
https://codeberg.org/landley/toybox/commit/891c5520f493
I very vaguely recall that busybox had similar option parsing weirdness
that made maintaining the order of different argument lists non-obvious,
but it's been a while. Presumably back in 2003 I also didn't bother to
unravel it then and instead waited for somebody to complain.
That said I handed off busybox maintainership 20 years ago and my last
commit to the project was 5 years ago (0068ce2fa0e3) and before that
2011 (39ec6a2ad5da). It took me this long to notice your message to the
list. :)
So to answer your question, "no there wasn't an alternative script in
mind", it was probably just that fighting against the pumbing to address
that corner case was more work (bigger code) than seemed worth it until
somebody showed up with a real world use case.
Rob
