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 10:34:26 +0700

     Date:        Mon,  1 Dec 2025 02:30:02 +0000 (UTC)
     From:        "elo%sdf.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20251201023002.138681A923A%mollari.NetBSD.org@localhost>
 
   |  My persistent confusion about sed's expected behaviour lies in the
   |  implication that it keeps state
 
 It does.
 
   |  when the third line of input is substituted, of course the address
   |  range of the final 'p' command will have no effect; the entire line
   |  is skipped by the preceding 't'. That behaviour is manifestly correct,
   |  and is not what I meant to question.
 
 We're aware of that.
 
   |  What I'm failing to grasp is
   |  how it is that, when the fourth and subsequent lines of input are
   |  read, and do not result in substitutions, and the branch is not taken,
   |  the '3,$' address range is not then satisfied.
 
 Because address ranges don't work that way.   As you suspected above,
 they have state, they are turned on when the first address is encountered,
 and turned off again when the second address is encountered.   There is
 no actual concept of "from here to there" just start when you see this,
 and stop when you see that.   (Then go back to looking for the start to
 happen again.)
 
 That's necessary, to make things work in the general case when the
 addresses are patterns, not line numbers - line numbers are just a
 degenerate case, which can be thought of as matching a counter which
 is counting lines, against the pattern which is specified, it either
 matches, or does not.
 
   |  How did the fact that a
   |  substitution occurred in a previous cycle influence later cycles? The
   |  nature of that mechanism is what continues to elude me.
 
 The "this dual address command has been enabled" switch was never turned on.
 That only happens when the first (of the two) address matches (and it
 only turns off when the second does.)
 
 kre