GNU bug report logs - #32494
t incorrectly branching

Previous Next

Full log

Message #12 received at 32494-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Ruben Maes <ruben <at> janmaes.com>, 32494-done <at> debbugs.gnu.org
Subject: Re: bug#32494: t incorrectly branching
Date: Tue, 21 Aug 2018 10:52:52 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.