From scott@zorch.sf-bay.org Sun Mar 21 18:09:36 1999
Return-Path: <scott@zorch.sf-bay.org>
Received: from zorch.sf-bay.org (zorch.sf-bay.org [192.150.103.17])
	by hub.freebsd.org (Postfix) with ESMTP id DB15A1524D
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Mar 1999 18:09:35 -0800 (PST)
	(envelope-from scott@zorch.sf-bay.org)
Received: from zorch.sf-bay.org (uucp@localhost) by zorch.sf-bay.org (8.8.8/8.8.2) with UUCP id SAA03564 for FreeBSD-gnats-submit@freebsd.org; Sun, 21 Mar 1999 18:09:12 -0800 (PST)
Received: (from scott@localhost)
	by zork.sf-bay.org (8.8.8/8.8.8) id KAA04391;
	Mon, 22 Mar 1999 10:06:08 +0800 (CST)
	(envelope-from scott)
Message-Id: <199903220206.KAA04391@zork.sf-bay.org>
Date: Mon, 22 Mar 1999 10:06:08 +0800 (CST)
From: Scott Hazen Mueller <scott@zorch.sf-bay.org>
Reply-To: scott@zorch.sf-bay.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: bug in sed context address handling
X-Send-Pr-Version: 3.2

>Number:         10720
>Category:       bin
>Synopsis:       bug in sed context address handling
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 21 18:10:02 PST 1999
>Closed-Date:    Sun Mar 21 18:54:13 PST 1999
>Last-Modified:  Sun Mar 21 18:57:18 PST 1999
>Originator:     Scott Hazen Mueller
>Release:        FreeBSD 2.2.8-STABLE i386
>Organization:
Asia Online
>Environment:

	

>Description:

According to sed(1)

     A command line with two addresses selects the inclusive range from the
     first pattern space that matches the first address through the next pat-
     tern space that matches the second.  (If the second address is a number
     less than or equal to the line number first selected, only that line is
     selected.)  Starting at the first line following the selected range, sed
     starts looking again for the first address.

and an address is defined as

     An address is not required, but if specified must be a number (that
     counts input lines cumulatively across input files), a dollar (``$'')
     character that addresses the last line of input, or a context address
     (which consists of a regular expression preceded and followed by a delim-
     iter).

However, the sed behaves differently if the second address of the range is
the same as the first and the addresses were REs rather than numbers.  That
is, given this input:

<HTML>
<HEAD>
<TITLE>modbee.com | Merced hospital fills cultural prescription</TITLE>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TOPMARGIN=0 LINK=#003984 VLINK=#003984 ALINK=#FFFFFF>
<CENTER>

sed -n -e "3,3p" <input

outputs

<TITLE>modbee.com | Merced hospital fills cultural prescription</TITLE>

but

sed -n -e "/<TITLE>/, /<\/TITLE>/ p" <input

produces

<TITLE>modbee.com | Merced hospital fills cultural prescription</TITLE>
</HEAD>

<BODY BGCOLOR="#FFFFFF" TOPMARGIN=0 LINK=#003984 VLINK=#003984 ALINK=#FFFFFF>
<CENTER>

i.e. everything from the first match through EOF.

Note that sed works correctly if the second RE is on a different line.

>How-To-Repeat:

See above.

>Fix:
	
I don't have a fix.  I haven't tried a workaround yet, but it should be
possible to code a script that checks whether the REs are on the same line or
not and invoke the 1 address form if they are and the 2 address form if they
are not.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: steve 
State-Changed-When: Sun Mar 21 18:54:13 PST 1999 
State-Changed-Why:  
As Matthia Buelow notes, sed(1) is behaving correctly.  Originator will 
file a docs PR w/patch to reword the sed(1) manpage to be less confusing. 
>Unformatted:
