Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you ever wanted to know about terminals

xn--rpa.cc

Post reply on HN
Print view View original

71–80 of 191 posts

Re: Everything you ever wanted to know about terminals

#71

Post by duskwuff »

kazinator wrote: post #65

Here is something I learned only several weeks ago. While working on Pipe Watch, I strayed into reading the standard. * The ESC [ command start sequence is actually a compromise for 7 bit systems. The [ character is not chosen by accident. It has an obvious positional relationship to ESC in the ASCII code which is why, informally, Ctrl-[ is the same as ESC. * If you have an 8-bit-clean channel to the terminal, only a…

> If you have an 8-bit-clean channel to the terminal, only a single character is required: the "upper escape" from the C1 control character set (0x80 to 0x9F).

I'd avoid using this. It conflicts badly with UTF-8's use of 0x80 through 0xBF as continuation characters.

Re: Everything you ever wanted to know about terminals

#72

Post by samatman »

kazinator wrote: post #65

Here is something I learned only several weeks ago. While working on Pipe Watch, I strayed into reading the standard. * The ESC [ command start sequence is actually a compromise for 7 bit systems. The [ character is not chosen by accident. It has an obvious positional relationship to ESC in the ASCII code which is why, informally, Ctrl-[ is the same as ESC. * If you have an 8-bit-clean channel to the terminal, only a…

I'd suggest filing this under forbidden knowledge, 0x9b is 0b10011011, making it a UTF-8 continuation byte.

Putting a terminal into C1 mode is a great way to have it do unpredictable and weird things unless printable input is constrained to the lower seven.

Re: Everything you ever wanted to know about terminals

#73

Post by samatman »

ntoskrnl wrote: post #14

I was working on terminal code recently and had a hell of a time finding anything approaching an authoritative spec or reference docs. The best I found was this: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html I'd recommend that over the wikipedia link in the article, since wikipedia seems to be missing some things.

I don't know about authoritative but this is at least iconic if not definitive http://rtfm.etla.org/xterm/ctlseq.html

Re: Everything you ever wanted to know about terminals

#74

Post by GekkePrutser »

jl6 wrote: post #23

The author seems to really not like ncurses. But why? Is there something wrong with it?

The only reason I found in the article was "because jesus f. christ" (near the end). Therefore I assume the author has religious objections against nurses. /s

In fact they mention various issues with their approach that nurses would fix automatically and without the user having to configure stuff in the app:

> sadly, true color isn't supported on many terminals, urxvt tragically included. for this reason, your program should never rely on it, and abstract these settings away to be configured by the user.

Apparently they don't care about the great terminal-independence ncurses offers because these ANSI sequences will only work fully on terminal emulators. And as they mention even those differ in supported features. Ncurses was created precisely to abstract these differences. It's not just good for "obscure dumb terminals from 1983". It would also be quite a pain having to deal with terminal resize events etc when building a TUI. And no, doing a full screen rewrite for each minor update does not make for smooth TUIs. Yes modern hardware is fast but sometimes you're on a slow SSH connection.

Personally I still use real terminals too at times (I own a real VT520 and love it) and apps that are totally ignoring termcap/terminfo are super annoying. But I know this is niche.

PS: Also from the article:

> also, i have effectively zero pull in the tech community and am also kind of a controversial character who is liable to give projects a bad reputation, which i don't normally care about

Gee, I wonder why...

Re: Everything you ever wanted to know about terminals

#75

Post by bowmessage »

rustyminnow wrote: post #56
bowmessage wrote: post #41

Earlier quoted context omitted.

Maybe pipe output of every command into a script that invokes $PAGER when the output is long enough?

less has a flag for that: (the gnu version does at least) -F or --quit-if-one-screen Causes less to automatically exit if the entire file can be displayed on the first screen. So one could just pipe everything through `less -F`. If a different $PAGER is preferred, well that'll be a little more involved. (Also handy: add in `-X` to leave the contents on the screen when you exit less)

Neat! Thanks for the tips.

Re: Everything you ever wanted to know about terminals

#76

Post by duskwuff »

kazinator wrote: post #48
whartung wrote: post #19

You can't have "everything you wanted to know about terminals" with absolutely no mention of terminfo and (previously) termcap. You don't necessarily need ncurses to have a portable smart terminal experience, but you do need terminfo. ncurses magic relies on the lore stored in terminfo, which contains all of the obscure escape sequences and other information about the disparate world of terminals. They're maintained…

There is no need for the complexity of terminfo or termcap, because we have an ECMA/ANSI/ISO standard for terminal control. We have had it since before terminfo. ECMA-48 dates back to 1976. People have had 46 years to upgrade to standard-conforming terminals. Terminfo is not a de jure standard, only de facto . It is not in POSIX. POSIX specifies a tput command with exactly three operations: clear, init and reset. Rig…

The ECMA family of terminal standards (ECMA-35/43/48) is less definitive than you might think. See https://news.ycombinator.com/item?id=31417563 for some details.

Re: Everything you ever wanted to know about terminals

#77

Post by kevin_thibedeau »

ntoskrnl wrote: post #14

I was working on terminal code recently and had a hell of a time finding anything approaching an authoritative spec or reference docs. The best I found was this: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html I'd recommend that over the wikipedia link in the article, since wikipedia seems to be missing some things.

I'd add https://vt100.net/docs/vt100-ug/chapter3.html as it has details invisible-island doesn't go over as good as good a resource as it is. The other chapters are informative too.

The VT510 manual is also useful since it was designed to be used with a PC keyboard so it covers newer escape codes that aren't on older DEC terminals https://vt100.net/docs/vt510-rm/chapter8

Re: Everything you ever wanted to know about terminals

#78

Post by duskwuff »

Beltalowda wrote: post #35
MontyCarloHall wrote: post #22

Earlier quoted context omitted.

The solution is prohibiting characters that can easily be confused (across all writing systems), not banning Punycode altogether.

Or just allow only using a single script. A domain in all Cyrillic: great! Mixing Latin & Cyrillic: nono. In practice, browsers already check for this and display the "raw" punycode if they detect mixed script usage, but I wish such domains would not be registrable at all. These checks are somewhat complex and difficult, and easy to get wrong.

> Or just allow only using a single script.

This would still let some homographs through. In particular, Cyrillic has a lot of characters which are confusingly similar to, or even indistinguishable from, Latin characters (e.g. "авсекморѕтѵху").

Re: Everything you ever wanted to know about terminals

#79

Post by autoexec »

billti wrote: post #55
timw4mail wrote: post #7

I could take this a lot more seriously if capital letters were properly used.

I was actually thinking the opposite. I got quite a way through the article before I realized "Hang on - None of the paragraphs and sentences start with uppercase letters!" As a father trying to teach two small children to read and write, I've begun to think it's kind of annoying and unnecessary to have two different forms. It's easy enough to teach when they are just bigger glyphs, e.g. O -> o, C -> c, S -> s, etc.…

Uppercase letters are nice for emphasis. If we got away with having a set of both I'd vote for keeping the uppercase ones since they are easier to write. Mostly just simple straight lines. Especially useful when you're carving letters into something.

Re: Everything you ever wanted to know about terminals

#80

Post by GekkePrutser »

duskwuff wrote: post #69
jjoonathan wrote: post #12

I was aware of the ANSI escape sequences and even used them directly in scripts on occasion, but I still used ncurses "where it mattered" because I didn't know about compatibility. I didn't want to risk Windows or a random flavor of linux I'd never heard of or a group of anti-VT100 enthusiasts getting upset because I didn't use an agreed upon compatibility layer. From the tone of this piece I gather that the ANSI esc…

> From the tone of this piece I gather that the ANSI escape codes are actually standard enough to target. Correct. Hardware terminals are extinct in the wild, and essentially all software terminals (including the Windows terminal!) now support a reasonable subset of "extended VT100" terminal control sequences. Some of the weirder features of the VT100 (like double-high/double-wide text or VT52 compatibility mode) are…

The different features omitted and added are precisely one of the reasons you'd still want to be using an abstraction library. Otherwise you end up having to stick with the lowest common denominator, or having the user figure out how to enable each terminal feature in every app individually. These libraries were invented with good reason.

Even now there's big differences between terminal emulators. Especially when you take modern features like images into account, there's like 6 different ways of doing it as some terminals have invented their own (kitty for one) and there's more standard ones like sixels which come originally from the Dec VT340 series. Though they were ridiculously slow on that hardware so it didn't take off until much later.

Post reply on HN