#terminfo — Public Fediverse posts

My Monteverdi platform TUI view uses the tcell go library and it recognizes Ghostty with no problem, but today I discovered that mtr complains it doesn't recognize xterm-ghostty.

I see there's some consternation about Ghostty using its own terminfo and I feel like going ... well sonny, back in my day we had to echo terminfo into the amber 80x20 terminal CRT character by character with a lit match just to get BACKSPACE to work!

Anyway, yelling at cloud gets me nowhere. To get mtr to work I aliased it with an env var:

mtr: aliased to sudo TERM=xterm-256color mtr

But I agree with @mitchellh on that crazy issue thread. It's a terminal emulator and that's the whole fucking point of terminfo in the first place.

#ghostty #terminfo #terminalnerd

Previous post is an absolutely top-notch rant on the state of #terminfo. I can't even boost it without a mildly verbose followup:

I've mostly managed to avoid learning how any of this stuff works, except for an old weird workaround for rxvt-running-tmux years ago, and more recently, copying terminfo entries for newer terminals around. (Mostly `foot`, and `foot-extra`. I refuse to learn why there are two entries for a single, modern terminal emulator.)

The terminal-based LLM coding tools (claude code, opencode, gemini, pi, etc) are a pretty interesting new development. In my experience, there's been a slow shift away from terminal-based tools for decades. Now, suddenly, these new tools are trying to jam lots of GUI-like features into terminal apps.

My impression is that the amount of time spent in terminal emulators is increasing for the first time in years. (I could of course be wrong, and maybe the time is spent inside VS Code extensions and web UIs instead.)

When working with fancy terminal emulators (foot, kitty, Ghostty, etc.) over SSH, you may encounter glitches because of missing terminfo on the remote machine.

To fix it, you need to transfer your terminfo.

You can use the infocmp command to do that: https://spiffyk.cz/notes/#general-ssh-terminfo

#terminal #cli #terminfo #ghostty #kitty #foot #ssh

In which #Ghostty #TerminalApp and #terminfo appear in comic form: Nope, never heard of it. See also https://ghostty.org/docs/help/terminfo
https://social.jvns.ca/@b0rk/115373147646620824

@kzimmermann

What does "control chars get printed" mean?

Because it could be two different things with two very different adjustments to make.

If it means control characters actually being printed as glyphs on the screen, taking it at face value, that's a /etc/wscons.conf and screen emulation settings thing; but if it is line editing not working then that's a TERM=netbsd6 and /etc/ttys affair.

#NetBSD #wscons #terminfo

There is a linux-16color terminal type in Dickey #terminfo. It has been there since 2009.

The #Linux KVT does not support more than the standard 8 colours, and some sleight of hand has been employed to get sort-of 16.

Unfortunately, the sleight of hand is broken.

If you've ever set TERM=linux-16colour and wondered at some strange scrolling and redraw artifacts, it is because the "op" capability doesn't undo the sleight of hand used by the setab/setaf capabilities.

#VirtualTerminals

@b0rk Not only have I had this situation, I also have the reverse on my OpenBSD box, where pressing backspace inside tmux sends a control+h (0x08), so to actually backspace I need to type control+backspace (0x7F)

It works fine outside tmux. Gotta get that sorted out at some point. #termcap #terminfo

@bean @chrisvest

Mishandling is a problem to this day. Many people know of ECMA-48. Fewer have read and fully understood ECMA-35, which explains the extensible and general structure of escape and control sequences.

#terminfo #TerminalEmulators

@bean

When it comes to minimum required common functionality, I've found that if one starts from scratch in the 21st century, the capabilities that one has to have in order to flag the useful differences among terminals and terminal emulators have almost no parallels in #terminfo at all.

http://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapabilities.xml#CAPABILITIES

@bean

Of course, there is the O'Reilly book on #termcap and #terminfo, which does have that sort of documentation. But it hasn't been updated since 1992, thus tending to reinforce your point. (-:

@tpope “I want things to work by default instead of work for the twelve people who've studied them in detail and have limitless time to fiddle.”

I’m not sure if @jwz still believes his quip from 1998 (“#Linux is only free if your time has no value” https://www.jwz.org/doc/linux.html), but @bean’s #terminfo rant above seems to confirm it’s still true.

[edit: Of course I’ve now aroused the “well ackchyually” Linux apologist army. I doubt anyone tagged is interested.]

@_bapt_ @mpts @zirias

I did say "with the #terminfo database files".

unibilium uses those database files. I don't remember offhand the other fairly prominent example that I encountered years ago. It was go or rust or something. There are several direct to terminfo database libraries in C#, too. Mono uses one, for starters.

Not only does the world usually expect terminfo nowadays, it even often works directly to the database files, no libterminfo or (n)curses in the picture at all.

@zirias @_bapt_ @mpts

That's the thing that you're missing.

"full terminfo support" *is not* solely just providing the libraries, in the world that we live in, as there are things that do not need the libraries. It's actually not unreasonable to find independent implementations that *just* require the identical data files, which ironically are not part of the standard. Because the world can and does code to *them* not to (n)curses or even to libterminfo.

#FreeBSD #terminfo

@zirias @mpts

Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:

Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.

@zirias @_bapt_ @mpts

You said: "Using termcap/terminfo directly nowadays means using curses. All the libraries needed for that are provided by curses (and nothing else)."

That's wrong. There are things around that don't use (n)curses and access #terminfo directly. (n)curses isn't the one-and-only abstraction that everyone uses. The world needn't write to it, and cases come along again and again where providing (n)curses libraries isn't enough. One has to provide the exact same database.

@JdeBP @mpts I never said there was no software using #terminfo databases directly, I just don't follow your argument this was a problem on #FreeBSD. These files are provided from a port/package, just install it (when "porting", add a run-dependency) 🤷‍♂️

I certainly see the need why people come up with something like this. The "classic" implementations force you to add silly "singleton" stuff like this:
https://github.com/Zirias/dos2ansi/blob/c606482c1723273dfd1251acd0d466f69a0ae58e/src/bin/dos2ansi/ticolorwriter.c#L51
... which wasn't a problem here, but as soon as you'd go multithreaded, you'd have to properly lock-guard this, and even worse, say you'd want some service serving different clients with different terminals simultaneously, you'd have to spawn a child process for each and every client 🙄

@_bapt_ @JdeBP @mpts "binary compatible" is just an unusual wording regarding compatibility with some binary (data) files. It's normally used in the context of ABIs.

So, sure, this lib can (correctly?) parse and use binary #terminfo db files. I don't get how this should be an issue with having to install these from ports/packages for #FreeBSD? A port can simply add a dependency.

With base curses (including terminfo/termcap "standalone" libs) using terminfo by default as soon as it is installed, anyone can have terminfo everywhere on FreeBSD, it's just optional.

@_bapt_ @zirias @mpts

unibilium is definitely binary compatible with the #terminfo database files, as I said, otherwise it couldn't work.

@zirias @mpts

You haven't experienced nearly enough softwares. (-:

There have been alternatives to those, that are binary compatible with the #terminfo database files, but that are otherwise designed from scratch, for years now. As I said, #NeoVIM used one.

I have this vague memory that go goes its own way on this, too, but I might be mis-remembering. I've definitely seen over the years several ground-up implementations outwith C and C++ development.

#FreeBSD

@zirias @mpts

Wrong. There are libraries around that don't use (n)curses and access #terminfo directly. I remember this pain with NeoVIM and FreeBSD some years back. #NeoVIM used one of these non-curses libraries that provided direct access to terminfo.

(n)curses isn't the one-and-only abstraction that everyone uses.

@mpts @zirias

No. #FreeBSD provides only #termcap as standard right now. #terminfo is only available as a port.

It's possibly the only mainstream operating system where this is still the case. NetBSD and OpenBSD both provide terminfo. I haven't checked Illumos.

https://github.com/freebsd/freebsd-src/tree/main/share/termcap

@JdeBP @zirias #FreeBSD is using #terminfo instead of #termcap as of 2024.

@JdeBP AFAIK, base #curses in #FreeBSD 14 already uses #terminfo (instead of the bundled #termcap) *if* it is installed (as a package). But sure, having it directly in base and getting rid of termcap would be much nicer.

@zirias

I wonder how much more this has to happen before some momentum gains behind an effort to switch #FreeBSD to #terminfo. (I vaguely remember that there's an open issue that has been languishing for years.)

@dani Haha 😎

I'm running a (heavily configured) #fvwm3 here. This screenshot was just for demonstration that #dos2ansi and #showansi don't depend on any configuration, so this was a completely unconfigured X session in #Xephyr, which by default runs #twm.

You can even see the test mode in #xterm can only use 8 colors (because this is what the default xterm #terminfo entry announces), still the #xterm windows launched by #showansi have full color support, they explicitly set the terminal name to "xterm-256colors".

Never say something is finished 🙈

Browsing https://16colo.rs/ I found some #ansiart file that immediately had my attention because it crashed my #terminfo writer. Turns out attempting fallback to #termcap names makes no sense with terminfo ... although it shouldn't hurt either, but it did with "xterm-256color" on #FreeBSD for the "blink"/"mb" capability, "mb" returned something, but something "else" 🙄 ... so I fixed that.

This file was strange enough to use it for more testing, it had "blinking" characters (according to #SAUCE), although ignoring that and using bright colors instead looked much more sane, see two screenshots for comparison (oh wow, #xterm can actually blink? although not like #VGA would...)

Anyways, I found a lot more things to optimize and fix in both my "plain ANSI" and "terminfo" color writers!

So, there will be #dos2ansi v1.2 soon. Will probably add some small feature first, just "because" 😂

Here's a mystery on #FreeBSD using tput(1) in #xterm with $TERM set to xterm-256colors:

$ tput colors
80
$ tput Co
256

I think this *should* query the exact same property, once by its #terminfo name, once by the short #termcap name.

To add to the confusion, in the "dos2ansi" tool I currently write, I use tigetstr() and tigetnum() and prefer the terminfo names, but fall back to the termcap names. The response I get for "number of colors" there is 256, with the same configuration.

Anyone got any ideas which weird magic is going on here? 🤔