@b0rk This isn't quite right in a few ways. LF is decimal...

@b0rk This isn't quite right in a few ways. LF is decimal 10, ascii 0x0a. It is 10 because it's the 10th letter of the alphabet, though. But it's not the same as pressing enter except in cooked tty modes, where the terminal driver converts the return key (^M, \r, ASCII 13 / 0x0d) to a newline (^J, LF, 10/0xa) which your program then sees as its input.

Like 8 July at 18:16 | Wall-to-wall | Open on pgh.social

9 comments

Julia Evans

@ben thanks

8 July at 18:20 | Open on social.jvns.ca

Ben Cox

@b0rk NP, sorry if that came off as "reply guy". I once spent a weekend curled up with stty.

8 July at 18:22 | Open on pgh.social

Julia Evans

@ben not at all, appreciate it -- edited the original post to link to your comment

8 July at 18:24 | Open on social.jvns.ca

Jeff Grigg

@b0rk @ben

Yes, it gets quite "hairy" with "cooked mode" and such.

The interface to ASCII terminals is based on teletypes, where the "Enter" key is "Carriage Return" (^M = 13). On output, to "go to the start of the next line," you need to send "Carriage Return" (^M) and "Line Feed" (^J).

And that's how "new lines" are stored in Windows (from MS-DOS, from CP/M), because CP/M was kind of crude and "dumb."

Unix files use '^J' for "new line." So it has to translate ("cooked mode") on I/O.

8 July at 19:53 | Open on mastodon.social

Ben Cox

@JeffGrigg @b0rk Yeah it's actually a pretty good way to get a good range of characters and consistency on input from a limited device like a tty or an early terminal.

What I had forgotten about (until someone, maybe @cks ? reminded me) is that the driver does similar transformations on output as well.

8 July at 19:58 | Open on pgh.social

Mark Eichin

@JeffGrigg
Tiny historical detail (which may be both obvious and not very relevant, I'll admit) missing here: the names are what those codes *do*, ie. Return the Carriage (or print head in fancy devices) to the first column, Feed the platen by one Line, etc. (Form Feed ^L ejecting a whole page kind of mutated to "clear"...)
@b0rk @ben

9 July at 1:26 | Open on mastodon.mit.edu

DHeadshot's Alt

@JeffGrigg
The ASCII standard specifies CRLF as a line ending: this is the rare occasion when Microsoft are following an (albeit outdated) standard when Unix-like systems aren't!
@b0rk @ben

9 July at 23:04 | Open on topspicy.social

Jeff Grigg

@ddlyh @b0rk @ben

Mainframes traditionally use fixed-width record sizes to represent "lines." (Or "cards" if you really think their way.)

Unix, C, C++ '\n'. (And '^D', not stored in the file, for end of file.)

CP/M, MS-DOS, Windows: '\r\n', the physical representation for most "terminals." (And '^Z', in the file, for "end of text in this file." With "junk" to fill the rest of the fixed-size block.)

Original Apple Mac: '\r' (or so I've read)

PICK OS: hex 'FE' character for line separator

10 July at 0:17 | Open on mastodon.social

Jeff Grigg

@ddlyh @b0rk @ben

The "logical" representation, stored in memory or disk, does not have to correspond exactly to the "physical" representation sent to the terminal/printer.

But in CP/M's case, it does simplify things: No translation; just dump text file contents to the console stream, "raw." The implementation of the "TYPE" command is "stream bytes until you hit '^Z' or end of file, and stop."

10 July at 0:20 | Open on mastodon.social