Last updated at 1:22 pm UTC on 9 September 2016
self deprecated: 'This class is now obsolete, use MultiByteFileStream instead.'.
^ (MultiByteFileStream new ascii) wantsLineEndConversion: true; yourself.
Since 2004, CrLfFileStream has been replaced by MultiByteFileStream which is part of the Multilingual packages. In recent version of Squeak, CrLfFileStream class>>new returns an instance of MultiByteFileStream.
Text is text, right? Well, the standards aren't completely caught up. Most systems use ASCII for 7-bit data, and Latin-1 for 8-bit data, which is a start. However, line-ending conventions are still different among different systems. Macs use a single carriage return (CR) at the end of each line; Unix boxes use a single line feed (LF); and Dos/Windows computers use a carriage return followed by a line feed pair. Other systems usually adopt one of these conventions, but clearly no one convention is going to win out any time soon. Squeak internally uses the Mac convention of a single CR, and by default it does the same thing for external files.
This behavior is problematic for people using Squeak on systems other than Macs. Files saved from Squeak frequently appear to be one long line, and files loaded into Squeak tend to have lots of invisible control characters stuck at the end of lines.
CrLfFileStream, a class written (I think) by Andreas Raab and thenceforth hacked by many others, aims to help this. If you set CrLfFileStream as your default file stream interface, then text files will get automatic translation between their on-disk format and the CR-based format that Squeak uses internally.
So, to finally get to the point, you enable CrLfFileStream by editing the
concreteStream method on the class side of FileStream; replace
CrLfFileStream as follows:
Please. Read carefully FAQ: Corrupted Source when Downloading about the concerns of doing so.