bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32494: t incorrectly branching


From: Eric Blake
Subject: bug#32494: t incorrectly branching
Date: Tue, 21 Aug 2018 10:52:52 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

tag 32494 notabug
thanks

On 08/21/2018 05:36 AM, Ruben Maes wrote:
printf 'Hello\n' | sed '
        s/Hello/Hello to you/
        s/foobar//
        t end
        s/Hello/Goodbye/
        :end'

Since t should only look at whether the *last* substitution changed the pattern 
space,

That's not how POSIX describes it:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
"[2addr]t [label]
Test. Branch to the : command verb bearing the label if any substitutions have been made since the most recent reading of an input line or execution of a t. If label is not specified, branch to the end of the script."

'info sed' words it a bit differently:

't LABEL'
     Branch to LABEL only if there has been a successful 's'ubstitution
     since the last input line was read or conditional branch was taken.
     The LABEL may be omitted, in which case the next cycle is started.

which seems to emphasize that the previous 't' must have been successfully taken before the condition gets reset (but if the last conditional 't' was not taken, then there has not been a successful match, so I don't know if the difference can be observed in practice).

it is my understanding that this should print:
        Goodbye to you
But sed prints instead:
        Hello to you

sed is behaving correctly; it is your understanding that was off. It is not "branch if last substitution succeeded", but "branch if ANY substitution has succeeded since the last input or 't'".

One possible fix to your script, then, is to bound any substitution that you want to test in isolation with an earlier 't', perhaps looking something like:

t reset
: reset
s/...//
t end

such that whether or not 't reset' fires, execution resumes at s/// in question with the condition cleared.

As such, I'm closing this as not a bug, but feel free to add more comments on the topic.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]