How to set $TERM variable different from your base OS inside a toolbox container on silverblue

Hi, I’m using Fedora Silverblue 36. I use Kitty as my terminal and the $TERM environment variable is set to xterm-kitty. When I enter a toolbox container and try to open a file with nano I get the following error:

Error opening terminal: xterm-kitty.

But vi works fine.

Is there a way I can use a different value for $TERM such that nano works too? Also what should this value be (I remember seeing the toolbox container defaulting to an ansi type terminal)?

The nano editor is graphical (I suspect it uses curses). The vi editor is purely text based (although vim seems somewhat graphical). I would suspect the difference is the cause of being unable to use nano.

Personally I think it seems rather short-sighted if you are unable to use or learn to use the vi editor since that has been the default go-to editor for console use for >50 years on almost all unix style systems. It is simple, reliable, works well, and has for a long time. As well, it is the only editor that has consistently remained usable and available while all others have come and gone regularly over the same time span.

Try to install
sudo dnf install fontconfig in the toolbox it selves.

I did try to reproduce your error and when I opened nano in kitty it complained about missing fontconfig. Installing this package solved the problem.

1 Like

Nano is on all never distribution installed per default. Why the heck should ppl learn vi when they feel uncomfortable with it.
In my case, i tried it several times while using Linux. I really missed always the infobar on the bottom with all the shortcuts listed to see what i have to do.
Just my personal meaning :wink:

1 Like

Did you install kitty in your toolbox?

Yup, this was the problem. Sorry for such an obvious error on my part. I keep forgetting that I have to separately install programs inside the toolbox even if I have them outside and that only the home folder is shared.

Btw, is there anyway to use separate dotfiles inside a particular toolbox?

1 Like

Many application let you set the own path to the config files (is that what you mean with .files ?) At least this apps you install just in the Toolbox.

I’ve found this hack-ish way to only run certain config when inside a toolbox container (fish shell syntax):

if test (string split "=" (cat /etc/os-release | grep "VARIANT_ID"))[2] = "container" 
    # container config goes here
end

[quote=“Jeff V, post:2, topic:76036, full:true, username:computersavvy”]
The nano editor is graphical (I suspect it uses curses). The vi editor is purely text based (although vim seems somewhat graphical). I would suspect the difference is the cause of being unable to use nano.

Both nano and vim are using curses, which means they are full screen text based editors.
There is also a graphical version of vim called gvim from the vim-X11 package. WIth gvim you get all the things expected from graphical applications, like pull-down menus, copy-paste using the mouse, and so on.

Yes to nano, no to vim.
According to oreilly book on vi and vim, both are strictly text based though vim is enhanced. Neither vi nor vim appear to use curses.

Running rpm --query --requires vim-minimal and rpm --query --requires nano shows that nano depends on libncursesw but vim doesn’t. So, I guess nano is graphical but vim isn’t.

Let us check, shall we

Blockquote[root]: rpm -q --requires vim-minimal
/usr/bin/sh
config(vim-minimal) = 2:8.2.5172-1.fc36
libacl.so.1()(64bit)
libacl.so.1(ACL_1.0)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.33)(64bit)
libc.so.6(GLIBC_2.34)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libselinux.so.1()(64bit)
libselinux.so.1(LIBSELINUX_1.0)(64bit)
libtinfo.so.6()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rtld(GNU_HASH)
vim-data = 2:8.2.5172-1.fc36
[root]: rpm -q --whatprovides ‘libtinfo.so.6()(64bit)’
ncurses-libs-6.2-9.20210508.fc36.x86_64

Thus, vim-minimal requires libtinfo.so which is provided by ncurses-libs.

I might be wrong here but it seems like vim only uses ncurses for dealing with terminfo files assuming that’s what libtinfo is for. Also, vim works in non-graphical terminals, thus, it at least has a fallback mechanism in case there’s no graphical terminal.

That is what ncurses is for. Ncurses makes it possible to create full screen programs in a non-graphical environment, and it has existed since before graphical environment was even invented.

For vim, all terminals are non-graphical terminals, whether using gnome-terminal, connected via telnet, or using a real terminal connected to a rs232 port. For exanple, if you have an old TeleVidio model 925, you set TERM=tvi925 and you can run vim and it works. If you have an old Dec vt102, you set TERM=vt102 and you can run vim. That is all possible thanks to ncurses and the terminfo files.

The only fallback in vim is that if TERM is not set it will default to TERM=ansi, which is defined by /usr/share/terminfo/a/ansi.

All this talk of vim and ncurses is way off-topic for setting $TERM. Lets end this part.