convincing squeak to use LF instead of CR as the line separator...

Richard A. O'Keefe ok at atlas.otago.ac.nz
Tue May 29 23:48:58 UTC 2001


"Duane Maxwell" <dmaxwell at san.rr.com> wrote:
	In the case of CP/M, I believe the problem was that terminals of the era
	interpreted CR as "move cursor to column 1" and LF as "move cursor down one
	line, scroll if necessary". That, in turn, is because that's the way ASR-33
	teletypes did it - CR meant "return the carriage to column 1" and LF meant
	"feed one line of paper". The operating system did no translation of the
	output stream - the data went out raw to the serial port. Virtually all
	early CP/M-based computers used terminals because memory mapped video was
	very rare.
	
What terminals do and what operating systems do are only very loosely
coupled.  When I used Burroughs' CANDE environment on a Model 33 Teletype,
the Teletype wanted CR (+nuls) + LF (+nuls) to do the right things with the
paper and the print head, *but* what I actually typed to get this effect
was Ctrl-C (End of TeXt, right?  the obvious thing!), and what the operating
system stored was nothing at all (fixed length records).

Note that although many many terminals required padding characters (NUL or
DEL) to be sent, the ASCII specification actually forbids those codes
appearing in text files (there is some excuse for the C convention after all!),
so the decoupling between stored-data and characters-sent-to-the-terminal has
been obvious since the early 60s at least.

I wrote a terminal driver for a minicomputer (ok ok, by today's standards
a microcomputer) once.  Handling line editing and delay padding was hard
enough that the extra cost of mapping CR to CR+LF was hardly noticeable.

I note that EBCDIC has CR, LF, *and* a NL code.
So of course does "ASCII" these days, NEL (NEw Line) is '\205'.





More information about the Squeak-dev mailing list