[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: History command confused by different line endings
From: |
Bob Kline |
Subject: |
Re: History command confused by different line endings |
Date: |
Tue, 29 Jan 2002 14:43:58 -0500 (EST) |
On Tue, 29 Jan 2002, Larry Jones wrote:
> Bob Kline writes:
> >
> > When the history file has lines with mixed line-endings (some \r\n, some
> > \n, presumably resulting from the use of different versions of cvs), the
> > history command is unable to match O and F records reliably. This
> > happens because the history file is opened in binary mode, and the
> > read_hrecs() function is testing explicitly for '\n' as the record
> > terminator. This results in the software thinking that the '\r'
> > preceding the '\n' is part of the data for the last field in the record
> > (hr->mod).
>
> If the history file is opened in binary mode, using different
> verisons of CVS wouldn't make any difference -- the line terminator
> would always be \n. I think
Looking at the source for the history_write() function I can see that
this is true, as long as cvs is the only software which writes to the
file. I can only assume, then, that someone opened the file in an
editor which "fixed" the line endings when the file was written back to
disk, because when I went snooping to find out why the history command
sometimes thought that a module was checked out when it wasn't, I
discovered that some of the lines had CR+LF endings.
We could take the approach that this shouldn't ever happen. Or we could
apply the patch anyway to make the software a little more robust.
Absent the claim that '\r' is a legitimate data character for the last
argument (module or filename) field, the patch is benign, as far as I
can tell.
--
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com