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

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

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59803: sed(1) conditional branch command confuses subsequent line addressing
Date: Mon, 01 Dec 2025 03:50:15 +0700

     Date:        Sun, 30 Nov 2025 13:30:01 +0000 (UTC)
     From:        "RVP via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20251130133001.A2FE91A923A%mollari.NetBSD.org@localhost>
 
   |  > 	By my reckoning, lines 4 and 5 ought still to have been printed,
   |  > 	but they were not.
   |  >
   |  
   |  Yes, it seems that way to me too. This affects `b' too:
 
 No, Michael (mlelstv@) and Valery (uwe@) are right, if the first address
 in a dual address command doesn't actually match the pattern space, then
 the command following a dual address is not executed.
 
 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.
 
 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.
 
 The proposed change makes numeric addresses behave differently than
 patterns, but there is no justification anywhere for that distinction.
 
 It might seem odd, but it really isn't.
 
 kre