ertius.org

I guess I don't understand terminfo

#sysadmin #terminfo #debian #ghostty #curses #ncurses

So, I've been quite happily using ghostty as my terminal lately. It's fast, it has a variety of nice dark themes so I can both get tiny dopamine hits from changing it but also have the consistency of it looking nice and dark. The one downside (aside from not having search) is that it's new, and thus it doesn't have widely dispersed terminfo. Fine, I thought, I can just copy it around myself. And I can, it's quite easy, ghostty even has a ssh override alias to do this. But that's a bit shite and I control all the machines I'm ssh'ing in to anyway, so why not fix it.

Some poking found me this which notes:

Ghostty's terminfo entry is available in ncurses 6.5-20241228 and above. As distros update their ncurses packages, Ghostty's terminfo entry will be available by default system-wide. This will take time to propagate.

while the PTS says:

Package: ncurses-term (6.5+20250216-2)

5 > 4, QED, hooray. But my test program, duf wasn't actually working. Instead of using a pleasing green to show my bountiful disk space, it's all grayscale. But why?

It eventually occurred to me to check if other programs were happier - btop, vim, batcat, all coloured, it's just duf that is not working. A lazy https://kagi.com/search?q=duf+terminfo => https://github.com/muesli/duf/issues/34 and

Unless TERM is set to set xterm-256color, duf outputs black and white information.

wtf. And indeed, if I set COLORTERM=yes it does work. I guess I hadn't noticed this since I had configured SSH to force TERM:

Host *.mine
    ...
    SetEnv TERM=xterm-256color

And I wouldn't notice locally, since ghostty itself sets COLORTERM=truecolor for shells running directly inside it.

OK, so that explains duf, but what about this:

# infocmp
infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-ghostty.

Well that's a bit odd. Doesn't Debian ship the terminfo now:

# echo $TERM
xterm-ghostty
# dpkg -L ncurses-term |grep -i ghost
/usr/share/terminfo/g/ghostty

As far as I know, there's no aliasing or anything in in terminfo - you just provide a file and it's looked up according to whatever TERM is set to. Digging in to the ncurses history, I find this, which is currently a useless link since the GitHub commit view can no longer show complicated commits, but the upshot is that it shows the terminfo data being added with just the name ghostty.

Some git archaeology find this from Sep 28, 2023 where the default value for TERM is changed from ghostty to xterm-ghostty to work around a vim bug.

And then finally while searching the ghostty bug tracker, I find this:

Sadly the outcome of this review is that the terminfo added to ncurses is named ghostty, not xterm-ghostty so that means that Ghostty's TERM variable will still be incompatible with distros even after the package is updated.

So, it's not even really a "bug", it's two independent groups (ghostty devs, ncurses dev) making incompatible decisions.

So, I've added a thing to my Ansible that does a symlink:

- name: Create terminfo directory for ghostty symlink
  ansible.builtin.file:
    path: /etc/terminfo/x
    state: directory
    owner: root
    group: root
    mode: "0755"

- name: Create xterm-ghostty symlink to system ghostty terminfo
  ansible.builtin.file:
    src: /usr/share/terminfo/g/ghostty
    dest: /etc/terminfo/x/xterm-ghostty
    state: link

I see yacoob did a similar thing.

I went with /etc/terminfo since it's in the search path by default (/usr/local/share/terminfo isn't) and shouldn't be squashed by future package updates that might fix this.

Overall, a bit of a bummer. Maybe the Debian maintainer will add a symlink as a workaround?