Charles,
Ah, I see the problem.
In version 2: The idea behind CrLfFileStream is to hide (or make uniform) the various line end convensions. So, no matter what line end convension your file uses (MAC = CR, UNIX = LF and WINDOWS=CRLF) you will see a carriage return. If you really want the literal bytes of the file there is little reason to use CrLfFileStream. The following code works (notice that in Smalltalk you normally send ascii to a stream if you want any special processing (like lf->cr conversion to be done):
stream := CrLfFileStream oldFileNamed: '/home/shaffer/technologies.csv'. stream ascii. "Tell CrLfFileStream to look for the EOL convension and convert lf->cr if needed" lines := 0. [stream atEnd] whileFalse: [Transcript show: stream nextLine; cr. lines := lines + 1]. stream close. Transcript show: lines printString , ' line processed.'
In version 1: You are using #nextLine which looks for a carriage return but your file has line feeds (look at the implementation of it in PositionableStream). The solution interpreting the bytes literally would be to use
stream upTo: Character lf
Here's a sample:
stream := FileStream oldFileNamed: '/home/shaffer/technologies.csv'. lines := 0. [stream atEnd] whileFalse: [Transcript show: (stream upTo: Character lf); cr. lines := lines + 1]. stream close. Transcript show: lines printString , ' line processed.'
Now, your question might be "Which is better?". The utility in CrLfFileStream comes when you might get files with either convention. That is, when you want the same code to be able to process CR, LF and CRLF line-terminated files. If you have no need for the flexibility then I'd stick with the second version (the one which uses FileStream).
I hope that helps...
David