Re: GNU sed manual describes t/T a little wrong?

---In [email protected], <dgoldman@...> wrote :
 [snip]
 
>The key cases are #7 and #8. In both cases, s substituted, so T did not >branch. According to the current GNU sed manual, branching is required to >reset the flag. But the flag was reset, so T branches next time it appears, >and t does not branch next time it appears. Merely running t or T, even if no >branch, is enough to reset the flag.
 
>I don't think this is a big deal. It seems rather obscure, something that had >never crossed my mind until Anders found it. I would always put t or T >immediately after the s command, so cases 7 and 8 would rarely or never >occur in practice. It seems like asking for trouble to have multiple t/T >commands scattered about. But who knows? Maybe this might come up in >some games that get programmed in complex sed scripts.

 

 First of all, thanks for compiling an exhaustive test set for depicting
 the behavior of "t"/"T" commands, which are very counterintuitive to
 say the least.
 

 I had stumbled at this very exact behavior of this feature of "sed" & used the
 following.
 If we have multiple s/// before the last s/// adjacent to the "t",  we can employ the tactic of placing a dummy label, like as,
 

 

 s/A/B/; # 1st sub
 s/C/D/; # 2nd sub
 s/E/F/; # 3rd sub
 

 tdummy
 :dummy
 s/old/new/; # final sub
 t
 d
 

 Then irrespective of the results of 1st to 3rd  subs, the final "t" would
 function on the basis of the last subs, i.e., s/old/new/
 

 Note that when "tdummy" will be taken => atleast one s/// from amongst
 1st to 3rd were successful. Then the flag is reset when sed arrives at
 s/old/new/ command, ensuring that the "t" command behavior is influenced
 by the result of s/old/new/  command.
 

 Alternatively, when "tdummy" is NOT taken => all s/// from amongst
 1st to 3rd were failures. Then sed control arrives at :dummy. And, when
 s/old/new/ is executed, the flag is still reset, so the "t" command behavior
 is influenced by the result of s/old/new/ command.
 

 -Rakesh



[Non-text portions of this message have been removed]