The "G" command in sed does not conform to proper sed usage; command does not output a newline as stated in the manpage, nor as stated in the official sed FAQ. This applies to ALL versions of FreeBSD (tested/verified on 2.2.8 and all 4.x revisions). This bug more than likely applies to OpenBSD and NetBSD as well. I'm hoping this bug can get squashed before 4.4-STABLE comes out... Fix: Approximately line 151 of src/usr.bin/sed/process.c: cspace(&PS, hs, hsl, 0); Change to: cspace(&PS, "\n", 1, 0); cspace(&PS, hs, hsl, 0); How-To-Repeat: $ printf "1\n2\n3\n" | sed '1,2H;2G' The output is: 1 2 1 2 3 But should be: 1 2 (blank line) 1 2 3
On 17-Aug-2001 Jeremy Chadwick wrote: | | This applies to ALL versions of FreeBSD (tested/verified on 2.2.8 and all 4.x | revisions). This bug more than likely applies to OpenBSD and NetBSD as well. FWIW, NetBSD and OpenBSD have the following change: http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/usr.bin/sed/process.c.diff?r1=1.24&r 2=1.25 is this related to the problem you're reporting? Mike -- Mike Heffner <mheffner@[acm.]vt.edu> Fredericksburg, VA <mikeh@FreeBSD.org>
That would be it. Looks like I have a modification to make to my own patch it seems. I didn't even consider checking out the NetBSD tree... Can we get this ported over before 4.4-STABLE? That'd be fantastic. Thanks Mike! On Thu, Aug 16, 2001 at 11:49:57PM -0400, mheffner@novacoxmail.com wrote: > > On 17-Aug-2001 Jeremy Chadwick wrote: > | > | This applies to ALL versions of FreeBSD (tested/verified on 2.2.8 and all 4.x > | revisions). This bug more than likely applies to OpenBSD and NetBSD as well. > > > FWIW, NetBSD and OpenBSD have the following change: > http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/usr.bin/sed/process.c.diff?r1=1.24&r > 2=1.25 > > is this related to the problem you're reporting? > > > Mike > > -- > Mike Heffner <mheffner@[acm.]vt.edu> > Fredericksburg, VA <mikeh@FreeBSD.org>
On 17-Aug-2001 Jeremy Chadwick wrote: | That would be it. Looks like I have a modification to make to | my own patch it seems. I didn't even consider checking out | the NetBSD tree... Hrm, after applying the patch and rebuilding sed I don't see any difference in the example you provided (ie. both print the 'wrong' output you posted). I know very little about sed, but is there a bug in the example you provided? Mike -- Mike Heffner <mheffner@[acm.]vt.edu> Fredericksburg, VA <mikeh@FreeBSD.org>
I eat my own words, as usual. The fix from the NetBSD source does **NOT** fix the problem I mentioned. It may fix another bug, but as I'm no expert at sed, I cannot say whether or not it's right or wrong. I believe the examples I provided in my bug report should be proper. The fix I mentioned also works appropriately, while the one provided by the NetBSD team does not. I've CC'd Eric Pement, author of the sed FAQ, on this matter. Eric, this should be fresh in your head, as a user at my workplace (best.com) just emailed you last week about this issue. :-) If you could provide some insight as to how this is supposed to function, I think we'd all appreciate it. I just don't want to induce too much more confusion.
Yes, I just noticed this as well. According to the documentation, the way it's *supposed* to work is as follows: $ cat > file one two three four five $ sed "1,2H;3G" file one two three one two four five $ However, the present sed implementation does the following: $ sed "1,2H;3G" file one two three one two four five Note the lack-of newline between "three" and "one". My previous example (re: printf | sed) works as well. :-) On Fri, Aug 17, 2001 at 12:43:42AM -0400, mheffner@novacoxmail.com wrote: > Hrm, after applying the patch and rebuilding sed I don't see any difference in > the example you provided (ie. both print the 'wrong' output you posted). I know > very little about sed, but is there a bug in the example you provided?
Responsible Changed From-To: freebsd-bugs->tjr I am working on this problem.
State Changed From-To: open->patched Fixed in -CURRENT, I will MFC it after 4 weeks.
State Changed From-To: patched->closed Change has been MFC'd earlier than I had perhaps wanted, but it has been MFC'd nonetheless.