From root@freefour.acs.rpi.edu  Wed Jul 15 21:07:24 1998
Received: from freefour.acs.rpi.edu (freefour.acs.rpi.edu [128.113.24.91])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08750
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Jul 1998 21:07:22 -0700 (PDT)
          (envelope-from root@freefour.acs.rpi.edu)
Received: (from root@localhost)
	by freefour.acs.rpi.edu (8.8.8/8.8.8) id AAA11643;
	Thu, 16 Jul 1998 00:07:26 -0400 (EDT)
	(envelope-from root)
Message-Id: <199807160407.AAA11643@freefour.acs.rpi.edu>
Date: Thu, 16 Jul 1998 00:07:26 -0400 (EDT)
From: FreeFour Root <root@freefour.acs.rpi.edu>
Reply-To: gad@eclipse.its.rpi.edu
To: FreeBSD-gnats-submit@freebsd.org
Cc: gad@eclipse.its.rpi.edu
Subject: possible fix for CRLF bug in 'more' command
X-Send-Pr-Version: 3.2

>Number:         7296
>Category:       bin
>Synopsis:       Long-standing bug in 'more' wrt CRLF.  I think I have a fix
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    hoek
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 15 21:10:00 PDT 1998
>Closed-Date:    Thu Apr 29 11:04:40 PDT 1999
>Last-Modified:  Thu Apr 29 11:05:13 PDT 1999
>Originator:     FreeFour &
>Release:        FreeBSD 3.0-980627-SNAP i386
>Organization:
RPI; Troy NY
>Environment:

	Presumably any version of freebsd which has a 'more' command...

>Description:

	If you use 'more' on files which have CRLF's in them, and if you
	do not specify '-u', then 'more' *will* make some errors in what
	it writes out to the terminal (you may not notice it, depending
	on what characters are getting repeated, but the output will be
	at least slightly incorrect).

>How-To-Repeat:

	Create a file with a lot of lines that have CRLF's in them.  Make
	it some recognizable pattern of characters.  'more' the file.

>Fix:
	
	In more/ch.c, remove the "bs_mode" processing.
	In more/output.c, add "bs_mode" processing, such that a '\r\0'
	combination will not output the '\r'.
	I do have modified versions of ch.c and output.c which do seem to
	solve this, and which don't seem to cause any problems when '-u'
	is specified, or for CR's followed by something other than LF.  
	This is my first attempt to send diff's along with a send-pr,
	let's see if I can do this right:

*** ch.c.orig	Sun Jun 14 12:03:38 1998
--- ch.c	Wed Jul 15 23:22:42 1998
***************
*** 101,107 ****
  static
  fch_get()
  {
- 	extern int bs_mode;
  	register struct buf *bp;
  	register int n, ch;
  	register char *p, *t;
--- 101,106 ----
***************
*** 180,214 ****
  	 * Set an EOI marker in the buffered data itself.  Then ensure the
  	 * data is "clean": there are no extra EOI chars in the data and
  	 * that the "meta" bit (the 0200 bit) is reset in each char;
- 	 * also translate \r\n sequences to \n if -u flag not set.
  	 */
  	if (n == 0) {
  		ch_fsize = pos;
  		bp->data[bp->datasize++] = EOI;
  	}
  
! 	if (bs_mode) {
! 		for (p = &bp->data[bp->datasize]; --n >= 0;) {
! 			*--p;
! 			if (*p == EOI)
! 				*p = 0200;
! 		}
! 	}
! 	else {
! 		for (t = p; --n >= 0; ++p) {
! 			ch = *p;
! 			if (ch == '\r' && n && p[1] == '\n') {
! 				++p;
! 				*t++ = '\n';
! 			}
! 			else
! 				*t++ = (ch == EOI) ? 0200 : ch;
! 		}
! 		if (p != t) {
! 			bp->datasize -= p - t;
! 			if (ispipe)
! 				last_piped_pos -= p - t;
! 		}
  	}
  
  found:
--- 179,194 ----
  	 * Set an EOI marker in the buffered data itself.  Then ensure the
  	 * data is "clean": there are no extra EOI chars in the data and
  	 * that the "meta" bit (the 0200 bit) is reset in each char;
  	 */
  	if (n == 0) {
  		ch_fsize = pos;
  		bp->data[bp->datasize++] = EOI;
  	}
  
! 	for (p = &bp->data[bp->datasize]; --n >= 0;) {
! 		*--p;
! 		if (*p == EOI)
! 			*p = 0200;
  	}
  
  found:
*** output.c.orig	Thu Feb 19 23:13:28 1998
--- output.c	Wed Jul 15 23:30:41 1998
***************
*** 47,52 ****
--- 47,53 ----
  
  int errmsgs;	/* Count of messages displayed by error() */
  
+ extern int bs_mode;
  extern int sigs;
  extern int sc_width, sc_height;
  extern int ul_width, ue_width;
***************
*** 115,120 ****
--- 116,132 ----
  		case '\b':
  			putbs();
  			column--;
+ 			break;
+ 		case '\r':
+ 			/* treat \r\n sequences like \n if -u flag not set. */
+ 			if (bs_mode || p[1] != '\0')
+ 			{
+ 				/* -u was set, or this CR is not a CRLF, so */
+ 				/* treat this CR like any other control_char */
+                                 putchr('^');
+                                 putchr(CARAT_CHAR(c));
+                                 column += 2;
+                         }
  			break;
  		default:
  			if (c == 0200 || CONTROL_CHAR(c))
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->hoek 
Responsible-Changed-By: hoek 
Responsible-Changed-When: Sat Jul 18 16:16:00 PDT 1998 
Responsible-Changed-Why:  
This patch is what needs to be done. 

Actually, output.c could use even more work.  :)  For example, 
it can't handle ``highlight me^H^H^H^H^H^H^H^H^H^H^H^Hhighlight me''. 
Volunteering?  ;) 
State-Changed-From-To: open->closed 
State-Changed-By: hoek 
State-Changed-When: Thu Apr 29 11:04:40 PDT 1999 
State-Changed-Why:  
Patch applied.  Sorry for taking so long on this. 

Marge to -stable pending. 
>Unformatted:
