Toolbox: Terminal Incompatibility with Alacritty from Arch Linux Installation

[mertalpt]

I am running an Arch Linux installation with the Alacritty terminal emulator. I installed the toolbox package through pacman, the default Arch package manager.

toolbox itself works fine, I was able to create a container based on fedora-toolbox:30 image. I was also able to enter the container successfully. However, I have issues running some commands inside the container.

Commands such as 'cd', 'ls', 'echo' or 'exit' work fine. But, commands such as 'clear', 'top' result in the message:

'alacritty': unknown terminal type.

and the command is not executed. Also tab, arrow keys and backspace do not work properly within the container. Tab seems to have no effect, while backspace acts like tab.

I also installed the gnome-terminal for a test. It worked fine without issue. But I would rather use the terminal emulator of my preference.

[HarryMichal]

Hey @mertalpt! I only used Alacritty once and that's about 2 years ago, so I have zero idea of what could be happening here. My personal guess aims at a possible problem with environmental variables.

@debarshiray and @tpopela on the other hand could.

[tpopela]

Hi @mertalpt @HarryMichal .. I'm running Toolbox on Alacritty (manually built from trunk at https://github.com/alacritty/alacritty/commit/f0775b3c89e92b92b74d5c9138a9770af80f589f). No problems here. Most time using tmux, but no problems even with using Alacritty without tmux.

[mertalpt]

'echo $TERM' returns 'alacritty'. Any idea what information I can provide to help identify the issue?

Edit: Exitting via 'exit' or Ctrl+D does not kill the container either. I have to manually grep the process and kill it each time.

[tpopela]

@mertalpt If I force the TERM=alacritty (I use xterm-256color) then I see the same problems as you.

[HarryMichal]

Edit: Exitting via 'exit' or Ctrl+D does not kill the container either. I have to manually grep the process and kill it each time.

This is an expected behaviour. Toolbox containers keep running after you exit them. You can stop them with podman stop <name-of-container>.

[HarryMichal]

@mertalpt, you can try to change the TERM variable to something else (e.g., xterm-256color, linux,..) and see if it "fixes" the issue for now. Still, we need to make this work out of the box.

[HarryMichal]

I just took a look at the package definitions of Alacritty in Arch Linux and Fedora (pschyska/alacritty copr) and I may see the cause. Notice the lines 37 and 38 in the .spec file of the copr repository, the terminfo directory is being populated with data for Alacritty. I do not see that step to be done in Arch Linux's package definition. I don't know the reason for it (I actually see this terminfo thing for the first time) but it should probably be adjusted.

Still, even if ^ is fixed, Toolbox needs to be adjusted, too. On Fedora, the terminfo stuff is saved under /usr/share/terminfo. Containers usually have their own terminal info. I guess we could try to do some bind-mount magic here.

[mertalpt]

@HarryMichal Changing the TERM variable to 'xterm-256color' worked. I have not tried with others. I have no further problems, thank you.

Edit: Am I supposed to close the issue now that it is solved for me or is that on collaborators seeing that there are adjustments to be made to toolbox?

[mertalpt]

After some reading I managed to hack together a workaround. I searched for all instances of terminfo directory starting from the root file system. Among the results were /usr/share/terminfo from my system, /home/mertalpt/.local/share/containers/storage/overlay/90d9aeda29c691f01d9c2e29cecd47facbc77768696219a9c8d61f273581f3df/diff/usr/share/terminfo from the base image used for toolbox containers and various hits from flatpak runtimes.

I copied the alacritty file from my /usr/share/terminfo/a into {image_name}/diff/usr/share/terminfo/a and I was able to use toolbox from Alacritty with TERM=alacritty without problem.

I investigated the terminfo directories of various runtimes and images I have found. terminfo from Flatpak runtimes were almost as populated as my own /usr/share/terminfo, while terminfo from toolbox base image was considerably empty. For comparison, there are 322 entries in the Flatpak terminfo/a directories, 326 entries in my terminfo/a and 4 entries in toolbox image's terminfo/a. Alacritty creates 3 terminfo files which helps explain the difference between the first two. All but my own terminfo lacked the Alacritty entries.

@HarryMichal For your earlier comment on package definitions, despite the difference you noted in definitions the given data exists in my terminfo without intervention on my end.

I imagine some sort of a post-hook script to copy /usr/share/terminfo into downloaded image's /diff/usr/share/terminfo would help solve the issue, although I lack broader knowledge to know if that would cause further issues. Still, one problem with that approach is what happens if someone installs something like Alacritty after the creation of a toolbox image? A solution is to check changes to user terminfo between each calls to toolbox-enter and update accordingly. Also, note that all of my terminfo directory is about 7.1M in size.

Another alternative to copying and comparing the entire user terminfo is to get the running terminal and compile it via tic into toolbox image's diff/usr/share/terminfo directory if not supported.

I might work on a solution later on if a preferred direction is advised. Please be patient and correct my mistakes if there are any, for this is my first time getting involved in an open source project. Thank you for your time.

[mgomes]

I can confirm using TERM=xterm-kitty also breaks things. Switching to TERM=xterm-256color resolves it. :+1:

[debarshiray]

What happens if you run:

$ podman run --rm -it --env=TERM=$TERM registry.fedoraproject.org/f31/fedora-toolbox:31 /bin/bash

[debarshiray]

It seems that this is a bit of a non-issue.

The default Toolbox images for Fedora already have the ncurses-base RPM which contains the terminfo entries for the most common terminals. This covers VTE, Konsole and xterm.

If someone chooses to use a more exotic terminal, which hopefully pulls in something like ncurses-term on the host for the corresponding terminfo entry, then I think it's fair to expect them to install the same entry inside the container. They'd have to do the same if they wanted to use a shell other than Bash.

You can make this somewhat smoother by building your own Fedora images locally with podman build based on the Dockerfiles provided by Toolbox, and adding the ncurses-term RPM on top.

The lesser known terminal could also try to attain compatibility with its better known cousins by implementing the same feature set. This is why VTE and xterm use the same xterm-256color entry.

Using (ie., toolbox enter and toolbox run) a Toolbox container is by far the most common operation that any user does. I feel hesitant to make everybody go through another set of potentially slow steps before using a container, only to accommodate a very niche use-case for a small subset of users.

[mertalpt]

What happens if you run:

$ podman run --rm -it --env=TERM=$TERM registry.fedoraproject.org/f31/fedora-toolbox:31 /bin/bash

After the image is pulled I get into bash but the same issue with missing terminfo entry persists.

@debarshiray While understandable I think this approach reduces out-of-the-box usability for non-standard users. If desired potentially slow steps can be hidden behind checking the existence of a single terminfo entry whose path is already known. If not, same check can be done to give an informative warning message. Currently, if an user does not already know the cause of such an issue they would have a hard time finding it.

[debarshiray]

What happens if you run:

$ podman run --rm -it --env=TERM=$TERM registry.fedoraproject.org/f31/fedora-toolbox:31 /bin/bash

After the image is pulled I get into bash but the same issue with missing terminfo entry persists.

Ok, that's what I expected. Thanks for trying it out.

While understandable I think this approach reduces out-of-the-box usability
for non-standard users. If desired potentially slow steps can be hidden behind
checking the existence of a single terminfo entry whose path is already
known. If not, same check can be done to give an informative warning message.
Currently, if an user does not already know the cause of such an issue they
would have a hard time finding it.

By potentially slow, I meant anything that requires a separate podman exec call. People already complain about sluggishness induced by an ever-burgeoning set of shell start-up scripts, so something that sets up a container environment to poke inside it is probably even worse.

I can think of two options that don't require a separate podman exec.

One is to hack something up using the actual command that gets invoked inside the container. See commit 47614b980c0a80ed6d1731de3a4d4a8a3f00472c for an example. However, adding more voodoo to that command line is likely not the best idea because it gets harder and harder to understand what's going on.

The second option is to do something with profile.d/toolbox.sh. In the part that gets run when inside a Toolbox container, we can add a check for the terminfo entry with a suitable error message.

[HarryMichal]

We could also do some magic in the container entry-point.

[debarshiray]

We could also do some magic in the container entry-point.

The way things stand at the moment, the user usually doesn't get to see the output from the container's entry-point. Not unless they do something like podman start --attach ..., and users who are already that far down the rabbit hole probably don't need any hints about missing terminfo entries. :)

[debarshiray]

The second option is to do something with profile.d/toolbox.sh.
In the part that gets run when inside a Toolbox container, we can
add a check for the terminfo entry with a suitable error message.

I have now implemented this in https://github.com/containers/toolbox/pull/544