The author's insistence on calling CR+LF "new line" only serves to confuse.
LF is line feed, thus new line. The CR is to readjust the write head back to the starting position.
The author's insistence on calling CR+LF "new line" only serves to confuse.
LF is line feed, thus new line. The CR is to readjust the write head back to the starting position.
LF is line feed, thus next line.
The CR
is to
readjust the write head
back to the
starting position.
A line feed alone is not a new line because some or most of the line is already used up. The B '*n' and C '\n' introduced the notion of new line, which outputs both a next line (LF) and back to the starting position (CR).Not for me. I get the dimensions but hell if I can remember it.
But mnemonic 'ReturN' (for the Windows style \r\n) helps (well, a bit) here:
\r: carrier Return
\n: liNe feedThe caveat is that advancing the paper vertically is relatively fast, but backing up the carriage[1] horizontally can take some time, so on a dumb and slow printer LF CR abc might end up printing abc in the wrong place while the carriage is still moving backwards, while on a smart but slow printer it will just be slower than CR LF abc. I suspect the dumb part is the origin of the CR NUL convention in Net-ASCII[2]; at least both termcap (dC capability) and terminfo (padding machinery) can describe, and curses handles, the possibility that the terminal requires a delay between issuing a CR and printing new characters at the beginning of the line.
[1] It’s a carriage, as in a moving thing that contains useful stuff (cf 3D printers), not a carrier, as in a bare unmodulated signal (cf modems).
[2] https://tools.ietf.org/html/rfc20, which probably takes the prize as the lowest-numbered RFC you could still encounter as an up-to-date reference.
Say that to USS Theodore Roosevelt!
:-)