One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you intend to do is to make your output fancy only when the output is a terminal, surely you should just send everything to stdout and use isatty to decide whether to also send those terminal control codes. But if what you want to build is a whole TUI like vim or the author's example app, you should send all the control to /dev/tty. This way if needed you can extend your app to be able to be a useful part of a pipe, as bytes sent to /dev/tty will not be redirected but will always be handled by the terminal. To prove that this can be useful, fzf, a fuzzy matcher, uses a TUI to let users input the pattern and pick among the matches, and prints the result to stdout. Sadly, however, it uses stderr to control the terminal instead of /dev/tty; this makes its ability to print error messages somewhat limited and its behavior unexpected when stderr is redirected. Also imagine that you can use vim in a pipe, instead of sed or awk, to see the effect of your edits live. Also, try `vi > /dev/null`. I'd say the behavior is a bug. IIRC ncurses makes use of /dev/tty and by default makes the app made with it redirectable, and this is a reason we should use it in the 21st century, among others. What's sad to me is that so far all the Rust terminal libs I've seen ignore /dev/tty, so it's impossible to use them to build something that both have a good TUI and can be used in pipes.
Everything you ever wanted to know about terminals
111–120 of 191 posts
Re: Everything you ever wanted to know about terminals
#112Off-topic, but it would be nice if HN could properly parse the Punycode encoding of internationalized domain names, so rather than the URL appearing as xn--rpa.cc, it appeared properly as ʞ.cc
Unicode domain names are a security threat, due to homographs.
As far as I know, most browsers only display the Unicode character on a whitelisted set of TLDs that have rules to prevent homographs.
.cc isn't part of this list and I only see the punycode.
Re: Everything you ever wanted to know about terminals
#113Every time I read this I disagree pretty hard. curses is not that pretty, but it exists to save us from the insanity that is direct terminal codes. I had an employer once who early on had invested heavily in wyse terminals, and here we were wanting to access these programs with terminal emulators, do you know how many good open source wyse terminal emulators there are? well it is pretty close to zero.
Almost every day the mandatory prayer "I wish they had used curses"
Re: Everything you ever wanted to know about terminals
#114A while ago I was trying to find a way to make my terminal scroll back up after a command executed, so that if the output was long I could read it from the top without having to scroll up manually. There are ways to get yours shell to print something after the command executes, so I just needed to find an ansi escape sequence that would scroll up. Unfortunately I didn't see any sequences that do this. Anyone have any…
https://sw.kovidgoyal.net/kitty/shell-integration does that and many other things for you out of the box.
Re: Everything you ever wanted to know about terminals
#115off topic but I would love a version of this with a more "plain" colors/ punctuation/formatting. finding it very hard to read / navigate anyway the content looks good so will try to find time to sit down and read this "essay" soon
Some actual visual examples would've been nice, too. There is just text that describes what it would look like but, as we all know, one picture is worth a thousand words.
All the code is there. Even a multiframe GIF or video capture wouldn't do their code (and blog post/rant) complete justice.
The final example is both a total treat and a beast. I encourage anyone with any interest to chuck the code into GCC and behold the interactive experience for themself.
Re: Everything you ever wanted to know about terminals
#116Earlier quoted context omitted.
https://www.ecma-international.org/publications-and-standard...
The relevant ECMA standards are full of crazy bullshit that, to the best of my knowledge, nobody has ever implemented in any hardware or software terminal, like control sequences to make lines of text run vertically (SPD), or to fully justify text (JFY), or to use a Fraktur font (SGR 20). They're also incomplete -- they go into very little detail explaining what various control sequences should do, especially in exce…
Hi I'm one of the people cited by the article. Fraktur is awesome. I implemented it in my terminal. https://github.com/jart/cosmopolitan/blob/c6bbca55e9f977e386... Now that unicode makes it easy, there's no excuse not to have fraktur!
Re: Everything you ever wanted to know about terminals
#117Here 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…
Yes but if you're using a modern UTF-8 terminal the C1 control code for CSI takes two bytes to encode. So I doubt it's very well supported.
Re: Everything you ever wanted to know about terminals
#118You 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…
^ This
Also not just ECMA. The standard was ratified by ANSI X3.64-1979, ISO/IEC 6429, and FIPS-86 in addition to ECMA-48. The whole civilized world wants these codes (e.g. \033[A for UP) to be a standard. Because it makes console development blissful when you can ignore all the accidental complexity of curses and terminfo when you can just assume the terminal behaves sanely and isn't the leftover byproduct of bygone commercial rivalries.
Re: Everything you ever wanted to know about terminals
#119One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you…
This is my first time hearing of this functionality.
How does it work with buffered stdout? For example, if you wanted to colour a single word?
Re: Everything you ever wanted to know about terminals
#120Yeah this is very very far from "everything". Among many things it doesn't speak of ptys. And terminfo, pty, ctty, process groups, and the rendering width of a utf-8 string, and, and and… > i might be one of a handful of people left on earth who actually has the knowledge to Uh, no. Anyone on BBSes in the 90s is very aware of ANSI, thank you. And we've not died off yet. And honestly it's really not that hard at all.…
> Uh, no. Anyone on BBSes in the 90s is very aware of ANSI, thank you. And we've not died off yet.
You guys should be more vocal. When you have great knowledge like that, you can't just keep it to yourself as a fond memory. People wouldn't be saying what the OP said if more of the oldskool crowd was out there blogging and mentoring the younger generation.