[TacticalCoder]

> There is no such character as NL ...

More specifically the Unicode control character U+000a is, in the Unicode standard, named both LF and NL (and that comes from ASCII but in ASCII I think 0x0a was only called LF).

It literally has both names in Unicode: but LINEFEED is written in uppercase while newline is written in lowercase (not kidding you). You can all see for yourself that U+000a has both names (and eol too):

https://www.unicode.org/charts/PDF/U0000.pdf

> and the article does not at all address that fact that the "ENTER" key on every keyboard sends a CR and not a LF.

what a key on a keyboard sends doesn't matter though. What matters is what gets written to files / what is sent over the wire.

    ... $  cat > /tmp/anonymousiam<ENTER>
    <ENTER>
    <CTRL-C>

    ... $  hexdump /tmp/anonymousiam
    00000000  000a

When I hit ENTER at my Linux terminal above, it's LINEFEED that gets written to the file. Under Windows I take it the same still gets CRLF written to the file as in the Microsoft OSes of yore (?).

> Things work fine the way they are.

I agree

[anonymousiam]

Try the cat example again with your tty in raw mode instead of cooked mode.

(stty raw)

Note that your job control characters will no longer function, so you will need to kill the cat command from a different terminal, then type: stty sane (or stty cooked) to restore your terminal to "normal" operation.

You will then see the 0d hex carriage return characters in the /tmp/anonymousiam file, and no 0a hex linefeed characters present.

[eqvinox]

What bytes your terminal sends to communicate keys pressed and what is used in a text file to communicate the end of a line are not the same thing. "\eE" (0x1b 0x45) can be a terminal newline too, after all. Or try pressing Alt+Enter.