Subject: Re: bin/28492 (more(1) doesn't handle NUL data blocks well)
To: None <tron@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,>
From: Bob Kemp <bsd@allegory.demon.co.uk>
List: netbsd-bugs
Date: 09/30/2006 09:55:02
The following reply was made to PR bin/28492; it has been noted by GNATS.
From: Bob Kemp <bsd@allegory.demon.co.uk>
To: gnats-bugs@NetBSD.org
Cc: tron@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
mrg@eterna.com.au
Subject: Re: bin/28492 (more(1) doesn't handle NUL data blocks well)
Date: Wed, 27 Sep 2006 20:11:52 +0100
On Tue, Sep 26, 2006 at 06:35:02AM +0000, David Laight wrote:
> The following reply was made to PR bin/28492; it has been noted by GNATS.
>
> From: David Laight <david@l8s.co.uk>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: bin/28492 (more(1) doesn't handle NUL data blocks well)
> Date: Tue, 26 Sep 2006 07:28:08 +0100
>
> Could this be caused by less trying to buffer a single 'line' of the file
> into memory? and failing to find a <lf> character...
Yes, I think you're right.
I tried
ksh -c "print -n a" > zxc
cat zxc >> zxc
^C
to generate a large file of 'a's. More behaves similarly in that it chews
up loads of memory but it is interruptible using ^C. With /dev/zero it
doesn't seem to be.
$ ps l
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1000 29579 550 999 -5 0 1223572 277064 biowait D+ ttyp0 0:12.46 more zxc
BTW, can anyone else reproduce this bug?
If it's only me, then I'm happy enough to close it.
As I wrote in the original report, it was just FYI.
Bob