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