GNU bug report logs - #22427
Odd behaviour of sed with n/N and line ranges

Previous Next

Package: sed;

Reported by: Eric Blake <eblake <at> redhat.com>

Date: Thu, 21 Jan 2016 20:03:02 UTC

Severity: wishlist

Tags: moreinfo

Full log


View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 22427 <at> debbugs.gnu.org
Subject: bug#22427: Odd behaviour of sed with n/N and line ranges
Date: Fri, 22 Jan 2016 20:45:44 +0800
On Fri, Jan 22, 2016 at 4:02 AM, Eric Blake <eblake <at> redhat.com> wrote:
> This message came up on the POSIX list today, claiming GNU sed has a bug:
>
> On 01/21/2016 12:02 PM, Rob Landley wrote:
>> On Thu, Jan 21, 2016 at 4:38 AM, Geoff Clare <gwc <at> opengroup.org> wrote:
>>> I'm seeing this with versions of sed derived from System V:
>>>
>>> $ printf '%s\n' a b | sed -e n -e '2s/b/c/'
>>> a
>>> c
>>> $ printf '%s\n' a b | sed -e n -e '1,2s/b/c/'
>>> a
>>> b
>>
>> Having recently implemented toybox sed from the posix spec, that's
>> what my implementation is producing too.
>>
>> You have to match the first line of a range in order to activate the
>> range (numeric works same as /ascii/ that way). Since the above skips
>> past the first line, you never activate the range, so later lines
>> don't trigger the range contents either,
>>
>> The gnu behavior is wrong. Replace the 1 with /a/ and the logic may be
>> easier to follow
>>
>> (But hey, at least the gnu guys finally fixed "sed p - -" segfaulting
>> when it freed stdin the second time...)

Thanks to both of you.
I'll certainly take a look before the upcoming release.




This bug report was last modified 6 years and 251 days ago.

Previous Next


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