Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ames!pacbell!pb2esac!pttesac!jlbrand
From: jlbrand@pttesac.UUCP (Jack Brand)
Newsgroups: comp.unix.wizards
Subject: Possible bug in sed(1) ?
Keywords: sed
Message-ID: <1567@pttesac.UUCP>
Date: 26 Feb 90 18:09:33 GMT
Organization: Pacific*Bell ESAC, San Francisco, Ca.
Lines: 54


sed(1) gurus,

I need help confirming whether I have found a bug in sed(1) or if
I am misinterpreting the manual.  It has to do with the 't' (test)
command.

Consider the following:

	sed -n "
	s/aaa/bbb/p
	n
	s/xxx/yyy/
	t success
	q
	: success

	[ rest of sed(1) commands ... ]

	"

Assume the first substitution succeeds.  A new line of input is
then read into the pattern space with the 'n' command.  Assume
the next substitution fails.  Now, according to the manual pages
for sed(1):

	t label   Test.  Branch to the : command bearing the label
		  if any substitutions have been made since the most
	   	  reading of an input line or execution of a 't'.  If
		  label is empty, branch to the end of the script.

This is not true.  The transfer to label "success" WILL take place,
even though no substitution has been made "since the most recent
reading of an input line."  sed(1) is "remembering" the successful
substitution of "bbb" for "aaa" earlier.

In the code it's easy to see why this is happening.  The integer
"sflag" gets set to 1 when a substitution happens.  This is what
gets checked by the 't' command to determine whether to transfer
to the label.  "sflag" gets set back to 0 after each 't' (true
to the manual) but NOT after the reading of an input line with
'n' or 'N'.  Adding the lines in to accomplish this seems to work;
is this what should be done?  Has anyone run into this?

For the record, a 'what /bin/sed' reveals:

/bin/sed:
	/bin/sed.sl 1.1 3.0 01/09/88 35043 iw

Thanks in advance for any light you can shed.

Jack Brand
...att!pacbell!pttesac!jlbrand
(415) 545-8332