Re: busybox sed not POSIX-conforming?

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