41 points
by
@vinhnx
|
February 28th, 2026 at 3:48am
March 2nd, 2026 at 9:09pm
I've been programming for 20 years and apparently still don't understand what my terminal is doing. Recently I asked Claude Code to generate a small shell script. It came back full of escape codes and I just stared at it like a caveman looking at a smartphone. This article finally explains what's been happening right under my nose.
March 2nd, 2026 at 8:11pm
If you're going to do this also provide a way to disable it so parsers don't trip up on its escape-coded output.
March 3rd, 2026 at 1:41pm
This is cool. I am playing around with Bubble Tea in Go today.
March 3rd, 2026 at 2:02am
Everybody who matters is using Ghostty nowadays! Why bother having the God-damned common decency to call isatty(), let alone use terminfo to look up the actual escape codes used by the user's terminal as reported by $TERM?
@teddyh
March 2nd, 2026 at 9:39pm
No mention whatsoever of the $TERM environment variable. sigh
Outputting raw escape codes and hope that they work is not how you do it. This is not how any reasonable library (or bash, or git, etc.) does it. These programs and libraries start with the $TERM environment variable to find out what terminal the user is using, and then use something like termcap(5) or terminfo(5) to look up what capabilities that specific terminal has, and what actual escape codes to output to get that effect. In reality, though, most regular programs delegate all this to a library, like ncurses.
(And also make sure not to output any terminal codes at all if the standard output is not a terminal, as in isatty(3) or tty(1).)
This way, you can check for and use modern cool stuff like sixels, but not use them if some user is using something older like XTerm or the Windows Console.