How terminal works. Part 1: Xterm, user input (2021) | Hacker News Reader

How terminal works. Part 1: Xterm, user input (2021)

kevroletin.github.io

261 pointssmartmic20 comments

The other three parts aren't linked in the article, but available if you go up a level. https://kevroletin.github.io/

I've enjoyed the 4th part, sessions and writing script most. The rest looks like severe security problems lurking underneath

How terminal works? Badly.

The terminal protocol is broken in fairly fundamental ways (see: How do I get an event for <shift> key up/down by itself? How do I distinguish Esc by itself from Esc combined with something else)

A lot of modern things have adopted the Kitty extensions in order to solve this: See: https://sw.kovidgoyal.net/kitty/keyboard-protocol/

Kitty is great. I started using it because I like cats. But I am learning more and more about how robust it is.

And yet because of the *nix OSs being widely available it has even displaced superior models e.g. the Windows character cell model [0] is arguably a better fit for modern terminals yet new development goes to compatibility with "cross platform" inband signaling and escape sequences.

[0]: https://learn.microsoft.com/en-us/windows/console/console-fu...

It isn't broken.

As far as standards go it is a fairly clean and easy to implement one. (That is the reason for its enduring popularity.)

Source: wrote a terminal emulator once. Turned out to be not that difficult. We just need to agree on an xterm-compatible subset of functionality and throw away the rest, which nobody ever uses anyways.

Your complaints are just aesthetic complaints, the terminal isn't supposed to be a universal GUI toolkit.

> How do I get an event for <shift> key up/down by itself? How do I distinguish Esc by itself from Esc combined with something els

How do I drive a screw with a hammer? Badly. It doesn't make hammer a bad tool though.

Terminals are a simple tool. The inputs and outputs are lines of text. If your application doesn't fit that model and needs keypress events then terminal is simply the wrong tool for the job.

Let's take MC, or any other TUI app. Esc is the common key to use to exit from menus, dialog boxes, various views, etc.

If the terminal is the wrong tool, then give example of the right tool.

GUI is

As I said, terminals are best suited for command line applications; lines of text in, lines of text out. Something that would work on classic ASR-33 or ADM-3A.

Dialog boxes, menus, and views are concepts that are more fitted to GUIs. And as such the right tool these days would be Wayland. For example, you get native keyboard scancode events and XKB keymaps, allowing far better input handling capabilities than any layering of hacks on top ANSI escape codes ever can.

The whole point of terminals is that they are simple, text based, and as such interoperable and standardized. ANSI escape code extensions are decidedly not text nor simple, and often very non-interoperable to varying degrees. As such they are pretty antithetical to the whole idea of terminals.

I am against this view. GUI invites bloat.

And overcomplicated terminal protocols do not invite bloat?

Not as much as a GUI, but yes.

When I ssh home, I would prefer a bloated TUI in ssh console and not do X forwarding or VNC. In fact, I prefer a TUI even when I'm at home.

Perhaps we need a better example? Detecting "esc" is simple: it is its own key code (ASCII 27.) Detecting "esc" and another key is more difficult because it is not a modifier, like shift or control, so you'll have to do it yourself.

I think the issue is that ESC is also a prefix for other keys. Which leads to the question: is this just an escape or is this a prefix of e.g. a cursor key? This can only be answered by timing.

Yes, let's take dozens of terminal emulator projects out of maintenance mode so app devs can individually and capriciously overload my shift and escape keys, because modern.

what if... we could scrolljack.... the terminal

rips bong

I used to search for a couple of lines of code in the getty.c program or its ancestors, which permitted ALL CAPS LOGIN because teletypes and early VDU terminals included models without a shift function. It made me ask myself how the password check was able to function (and how strong the crypt function was) if the case wasn't important.

They were removed from (at least) FreeBSD sometime in the 2.x series I believe.

I remember AIX doing that when you entered an upper-case login. Probably still does.

https://www.ibm.com/docs/en/aix/7.1?topic=s-stty-command#stt...

xcase Echoes uppercase characters on input, and displays uppercase characters on output with a preceding \ (backslash).

iuclc Maps uppercase alphabetic characters to lowercase.

olcuc Maps lowercase alphabetic characters to uppercase on output.

Solaris (Illumos) source code is consistent with this.

So for an upper-case only keyboard, uppercase letters are lowercase. To type an uppercase letter, precede it with a \. The tty layer handles the conversion so programs don't know or care what you're actually typing -- they just read (and write) normal upper and lower case characters.

(2021)

Reply on news.ycombinator.com