Error opening terminal: xterm-ghostty

[jforman]

SSH'ing via ghostty from OSX 16.2 to OpenBSD 7.6 and running multitail returns the error message:

$ multitail -I /var/log/daemon -I /var/log/messages -I /var/log/maillog -I /var/log/authlog
Error opening terminal: xterm-ghostty.

The shell on the OpenBSD machine is ksh.

I'm not a terminal expert, but happy to help debug here to figure out what I've got configured/misconfigured.

[mitchellh]

https://ghostty.org/docs/help/terminfo

[dnut]

I went with a different approach than anything suggested on that page. I added this to my ghostty config:

command = TERM=xterm-256color /usr/bin/bash

I understand that ghostty is doing the right thing by using its own terminfo. Nonetheless, from the user's perspective, this issue feels like a ghostty problem. I'd rather address this once in ghostty's config, rather than trying to fix all the other things that are broken by it. I'm sure there are benefits of using xterm-ghostty, but I have not observed any issues from switching to xterm-256color.

[mitchellh]

I'm sure there are benefits of using xterm-ghostty, but I have not observed any issues from switching to xterm-256color.

Yes, programs such as neovim (and others) will no longer use the latest available features, resulting in lower frame rates, tearing, and less functionality (i.e. no styled underlines -- a feature often useful for programmers). There are more.

Note you're unlikely to notice problems because terminal apps are some of the best in general at gracefully degrading since terminals are so inconsistent. Everything will keep working, but many things will be slightly worse in various ways. You may notice, you may not, but things are worse.

If it doesn't affect you, that's fine. But this is something that we can't set as a default, and must simply wait for the ecosystem to catch up.

[jforman]

Thanks Mitchell, time to brush up on my termcaps. Congrats on the release.

[alex-jitbit]

"Zero config"

[dgl]

Often I SSH to systems for quick debugging reasons, whereas systems I regularly use I can easily set up terminfo. So there's a known list of systems where I will have the ghostty terminfo. Therefore rather than follow the SSH config suggestion in https://ghostty.org/docs/help/terminfo it is possible to invert it:

Match Final Exec "echo $TERM | grep -q xterm-ghostty" Host !my-dev-host,!other-host-I-use-often,*
  SetEnv TERM=xterm-256color

That way you can update this when you copy the terminfo (and maybe shell integration) over but otherwise not think about this, until eventually the terminal definition is in the distributed database.

[mikluko]

There are historically reasons why this is hard. Instead of deriving joy from poking fun at a person's side project they do for fun in their free time, may I recommend spending 15 minutes googling "Terminfo" and reading the challenge of getting this to just work anywhere. I did my best to document it well (with the help of the community) and we're also working on upstreaming it now so it is on systems by default.

First of all, thank you for the tremendous work you’ve done. For my use cases, at v1.0, Ghostty has effectively became my primary terminal.

One thing that could be better is the promise. I mean, it could be beneficial to set realistic expectations instead of making clickbait-style claims about zero config Ghostty is obviously not capable to live up to at the moment.

[rhodes-b]

First of all, thank you for the tremendous work you’ve done. For my use cases, at v1.0, Ghostty has effectively became my primary terminal.

One thing that could be better is the promise. I mean, it could be beneficial to set realistic expectations instead of making clickbait-style claims about zero config Ghostty is obviously not capable to live up to at the moment.

Terminfo has nothing to do with configuration its merely a historical method that exists that makes it so many programs that people enjoy even work. Like suggested please read on the process as you would learn its not related to config, it is not possible to simply have terminfo installed everywhere when this project just became available, especially on stable release distributions which many people use. You can take any concerns about why you think you need to modify your config to #2363. Many people including myself have 5 or less lines in their config (mine being a theme, rebind splits, and gtk-single-instance=true to always force it) so yeah it definitely is zero config for many people

[mitchellh]

I can empathize and understand the argument that this feels like configuration. I respectively disagree. There is another discussion (I plan to accept pending some thought) to add a helper to automatically send the terminfo with SSH. I think that's a worthwhile improvement.

Making that "zero config" and automatic though would I think be a mistake for the big reason that I don't think mucking around with SSH by default is a good idea. I would never want to risk 'insecuring' someone's secure connection. For this same reason, our sudo shell integration that automatically makes terminfo work with sudo calls requires configuration (shell-integration-features = sudo), because modifying sudo by default is super sus. (The sudo integration exists today and was shipped with Ghostty 1.0)

Zero config is a philosophical ideal, but it doesn't mean we unconditionally risk security or stability on that path, on top of the other issues noted here.

[ungerik]

Sorry, but from a user's perspective, a terminal that doesn't work with SSH out of the box is broken

[voltagex]

I think shipping an alias for the ssh | tic command might help here, also this has been my number one pain point with ghostty so far.

[dgl]

Depending how adventurous you are I did put a PoC of a way that this could be done automatically on #4156

[voltagex]

An argument could be made for setting TERM=xterm-256color and leaving the configuration to people who want the additional ghostty features.

[mitchellh]

No this is not valid, because we don’t support everything that that terminfo advertises either. We’re doing the right thing here it just takes time
To propagate.

[voltagex]

Fair enough.

[cbrunnkvist]

I too have been typing TERM=xterm some-cmd during my testing as the pragmatical workaround of choice when e.g. ssh-hopping across systems, and just need to get things to work, but I'll switch to the ssh-config Match Exec route now once I found that workaround.

I wonder how large the discrepancy is though, it seems smaller than like 80/20 of xterm capabilities supported vs. not-supported? Anyway, out of a mix of nostalgia & curiosity, here's what a contemporary AI had to say about the two files...

[epicwhale]

I was wondering my ssh connection to a remote server was doing all kinds of bizarre looking keyboard entries when pressing backspace or spacebar and then figured I need to copy over terminfo infocmp -x | ssh YOUR-SERVER -- tic -x -

I was wondering if a simpler approach is to do something like what kitty does? i.e type ghosty ssh instead of ssh to connect to a remote server, and it 'just works'? https://sw.kovidgoyal.net/kitty/kittens/ssh/

[Phanquan]

second this, the solution above is not working in my case... so back to iterm atm

[pjwalstrom]

I did the infocmp -x | ssh YOUR-SERVER -- tic -x - on my Raspberry Pi running Pi-hole. Seems to be working fine, but I still get the occasional tput: unknown terminal "xterm-ghostty". Any suggestion?

$ uname -a
Linux raspberrypi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
$ pihole -up
tput: unknown terminal "xterm-ghostty"

[jazzboME]

I don't know if this is your situation, but for my system running raspbian, running infocmp -x | ssh YOUR-SERVER -- tic -x - only installed the terminfo in my user homedir (i.e. $HOME/.terminfo)

If I was running commands as another user, such as via sudo, I was still having issues, so I needed to copy the terminfo entry for that user, or what I ultimately did, create an entry in /usr/share/terminfo.

I'm guessing that pihole would need privileged access so I wonder if the terminal isn't known to root.

[pjwalstrom]

Thank you, creating an entry in /usr/share/terminfo/x solved it

sudo ln -s $HOME/.terminfo/x/xterm-ghostty /usr/share/terminfo/x/xterm-ghostty

[kartikvashistha]

As the official documentation rightfully states, setting the term value explicitly to xterm-256color for a or all hosts is the way to go if you are on openssh version >= 8.7. This is what I have been using for some time personally to get around the various term implementation quirks when ssh'ing.

Here's how my ~/.ssh/config looks like:

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

Note: I have observed that this setting might affect connections to a sftp server. If you encounter the same, to resolve this, it could be worth setting either the default term value as xterm or overriding the sftp host's term config with xterm if xterm-256color is set as the default term for all hosts.