entering text in the terminal is complicated https://jvns.ca/blog/2024/07/08/readline/
Entering text in the terminal is complicated

Entering text in the terminal is complicated

Julia Evans

someone in the replies elsewhere pointed out that Ctrl+J = 10 in the ASCII table = LF ("line feed") = Enter (because J is the 10th letter of the alphabet)

so Ctrl+J is the same as pressing enter

which I don't have any practical use for but is kind of cool

(edit: some corrections in this reply: https://pgh.social/@ben/112752235264922484)

Ben Cox (@[email protected])

@[email protected] 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.

pgh.social
also someone elsewhere left a comment like "I CAN’T BELIEVE IT TOOK HER 15 YEARS TO LEARN BASIC READLINE COMMANDS". those comments are very silly and I'm going to keep writing “it took me 15 years to learn this basic thing" forever because I think it's important for people to know that it's normal to take a long time to learn “basic" things

@b0rk haha yeah I have been doing this a lot longer than 15 years and this is the first time I have really _thought_ about how terminals work

one thing I don't get is: If ^W isn't handled by readline (or friends), what *is* doing it? How do backspace and word-backspace work?

How... does character entry work at all??

@njvack @b0rk I think this dates back to the days of slow remote serial terminals, or even teletypes? If you put some really basic line editing into the terminal itself and only send the entered text when pressing "enter", the experience feels a lot more responsive - and every program doesn't need to independently write its own implementation of backspace.

But yeah, very interesting legacy thing at this point, even tho many tools still rely on the behaviour.

I think in Linux it's implemented in the kernel's pty layer rather than separately in each terminal app?

@njvack @b0rk I only just realized why the mode where the terminal does line editing is called "cooked" mode. It's in contrast to the mode where apps get all the key presses one by one without preprocessing - "raw" mode.

@kepstin @b0rk I do know that a lot of this dates back to teletypes and the like. "/dev/tty0" is referring to a teletype, and a pty is a pseudo-teletype, and "vt100" was a "DEC Video Terminal 100" system.

I suspect you could, today, hook a modern linux system up to a teletype over a serial line and have it work correctly with relatively little effort

Then you wouldn't have a "terminal emulator program" — you would have a literal terminal

hmm

@njvack @b0rk oh, I agree that would probably work! I don't know anyone with a teletype, but I do know that one of my friends uses a pre-ANSI (not vt100 compatible) monochrome IBM terminal connected to their Linux box with only minor issues. Issues are mostly apps that don't use terminfo or termcap and assume an ANSI terminal is in use - they often print escape codes the terminal doesn't understand. Using "screen" as a translator is the easiest workaround.

@kepstin @b0rk hmmmmm looks like you can get a DECWriter for as little as $600 plus shipping

I could spend a lot of money and learn to use `ed`

I cannot think of a worse idea, and yet