Re: bin/59803: sed(1) conditional branch command confuses subsequent line addressing

["RVP via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59803; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Robert Elz <kre%netbsd.org@localhost>
Subject: Re: bin/59803: sed(1) conditional branch command confuses subsequent
 line addressing
Date: Mon, 1 Dec 2025 00:10:12 +0000 (UTC)

 On Sun, 30 Nov 2025, Robert Elz via gnats wrote:
 
 > POSIX is perhaps slightly clearer than the man page uwe@ quoted.
 >
 > 	An editing command with two addresses shall select the
 > 	inclusive range from the first pattern space that matches
 > 	the first address through the next pattern space that matches
 > 	the second.
 >
 > That is fairly clear, the pattern space must actually match the
 > first address for the range to be started - it doesn't matter why
 > it doesn't match, if it doesn't actually happen, it doesn't.
 >
 
 Right, ...
 
 > It is easier to visualise this if you use actual matching patterns,
 > rather than line numbers, that if if the input were
 >
 > 	1b
 > 	2b
 > 	3a
 > 	4b
 > 	5b
 >
 > and the sed script were
 >
 > 	=
 > 	s,a,substitution succeeded,p
 > 	t
 >
 > 	/^3/,$p
 >
 > which is (aside from the lines printed having an extra leading
 > character) the same thing, approximately.   But with this, if
 > sed never actually matches the leading '3' in the pattern space
 > how can it tell which lines that 'p' (the final one) is intended
 > to apply to?   The (successful) 't' means that dual address
 > command is never executed in the line that contains the leading
 > '3' (as that's the line that also contains the 'a'), so there's
 > no way sed can know that the range has started, and if it doesn't
 > know that, it hasn't.
 >
 
 but, there's a major difference between these two: even in a stream, sed can
 _always_ retrieve the current line number (even with `sed -i '' file.txt').
 Whereas of course, when the pattern is gone, it's gone and you can't determine
 the applicable range. So, with line numbers, you can act on the rest of the
 range.
 
 > The proposed change makes numeric addresses behave differently than
 > patterns, but there is no justification anywhere for that distinction.
 >
 
 Yes, deliberately so, for the reasons above :) Anyway, either way is fine
 with me (I have a preference for the GNU behaviour, though). I tried all this
 out (along with a: printf '%s\n' a b c d e f | sed '1,3d; 3,5d') on a few
 OSes just now:
 
 FreeBSD-14.3, OpenBSD-7.7 and OpenIndiana (Hipster 2025.10) behave like NetBSD
 (all these seem to have the same parentage). 9front 2025/10/11 (Plan 9) also
 acts the same way, even though the code-base is very different.
 
 Tribblix has GNU sed. Busybox sed follows the GNU sed behaviour.
 
 -RVP