Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
fish: Could not set up terminal #36146
After logging into my host via SSH, I get the following output despite
Subsequent invocations of fish (
Steps to reproduce
Use the following configuration:
Then, connect to the machine using SSH from
As far as I understand this issue, it appears because fish initializes the terminal first, then loads init scripts with TERMINFO* env vars before initializing the terminal. Note that this warning is inconsequential, and that your terminal is fully functional. Otherwise you would see the warning twice, and your terminal would be partially broken.
As before, you can fix this issue by symlinking ~/.terminfo to
It so appears that /etc/terminfo is not in the default lookup path of termcap... I should investigate that, or maybe just read my previous comments about that in #19785.
Cool, thanks for the help! I realized just after I posted that it was being reinitialized with the correct TERMINFO_DIRS. And if I ssh'd in tmux, it would work (tmux sets the $TERM=screen), so I knew it was reading something, I just wasn't sure what.
But if I ssh'd into a Ubuntu box, I don't get the warnings - so maybe it's something we can fix in nixos? I can have a look.
Setting TERMINFO_DIRS, that's the way we use to fix it. But fish being very interactive by nature, it initializes the terminal before reading event the most elementary config files. Usually, the shell is responsible for initializing the env vars, so we have a chicken and egg problem here. We need fish to parse and export TERMINFO_DIRS, but fish needs TERMINFO_DIRS to be configured before starting. All the shells handle this by delaying term setup until env vars are read. Fish did it for some time then this problem appeared. Bisection could find the culprit.
If we cannot / do not want to fix this upstream in fish, we can also
#!/nix/store/...-sh/bin/sh exec /nix/store/...-fish/bin/fish "$@"
Well, no, that is not enough. We need to detect if this is a login shell... But nonetheless, I do not think we want to wrap fish in another shell. Patchin could be a way to go. The current statu-quo is already the result from a patch I upstreamed to fish.
As for 1., I guess this tells it all: https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00032.html