I'm using sbcl 1.0.3 on Linux, to run the following on a file which contains
both carriage returns and newlines (dos style). Sometimes the
read-line stops at the newline, so the carriage return is included
in the returned string. Sometimes the read-line consumes the
carriage return so that the returned string contains neither carriage-return
nor newline. It does both of these behaviors at different times (in an
random order) on the same run through the file.
(with-open-file (stream "/home/mylogin/programming/textfile.txt"
(loop for line = (read-line stream nil)
while line do
(let* ((l (length line)))
(format t "~a~%" line)))
CMUCL does not do this -- it consistently reads both the carriage
return and the newline as the line delimiter, so the returned string
never contains a carriage return.
It is possible this has been fixed in more recent versions but I don't
know. Can anyone confirm this ?
sorry about that -- it is my mistake. Here's my best explanation of what
In my defense, my mistake was not knowing that emacs apparently
modifies a text file when it edits it. The given text
file contained both \n-only and \r\n line separator sequences. While
in, emacs converted all the \n to \r\n, so that even though I was
used the hexadecimal mode of emacs to view the file, all I saw was the \r\n
*after* emacs had done the conversion. So with emacs' hexl-mode,
it appeared that the file did *not* have any \n-only sequences. There
is a way to turn of this helpful behavior of emacs, which I don't know.
It was a bit of a problem because when I used emacs to save subsets of the
file, the errors seen by sbcl went away, leading me to think that it is a
effect that only happens on big files. The problem was that emacs was
fixing the \n to \r\n as I saved the subsets.
I have since verified, with perl, bvi, and hexer, that the original file
fact have some \n-only separators (and these are precisely the ones that
was behaving differently on). It would also explain why cmucl also had
the same weird behavior.
I believe there's nothing wrong with sbcl in this regard; nothing to fix :-)
again, my apologies.