| Newsgroups |
gmane.editors.sed.user |
| Message-ID |
<[email protected]> |
>
> 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.
>
Yes, the tests I complied were exhaustive. Or maybe exhausting. :) And I
agree the commands are counterintuitive.
>
> 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,
>
>
Thanks for the information that this behavior actually does come up in
practice, something that a more advanced user might run into, and the
tactic you use to manage it.
And it's a reality check that you had previously stumbled on the same
issue, and come to the same conclusion. The point, as you explain, is
that even if tdummy is NOT taken, the flag is still reset. So the flag
is reset when t is "run", whether or not the branch is taken.
>
>
> 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
>
Daniel