[Error]: When I press up arrow in container for command history, the command text gets mangled

[sonulohani]

Describe the bug When I press up arrow in container for command history, the command text gets mangled

To Reproduce Run few command and then press up arrow. Please look at the screenshot attached

• Are you using podman or docker?
   Docker. But I see this issue with podman as well.
  

• Which version or podman or docker?
   Docker version 20.10.17, build 100c701
  

• Which version of distrobox?
   distrobox version: 1.3.2
  

• Which Host distro? 
   Ubuntu 20.04.5
  

• Which guest distro?
   Ubuntu 22.10, but I see issue with 22.04.1 as well.
  

[89luca89]

Hi @sonulohani

can you please add all the information requested in the bug report issue template?

• Are you using podman or docker?
• Which version or podman or docker?
• Which version of distrobox?
• Which Host distro?
• Which guest distro?

Also I see you're using some sort of custom prompt? Which is it so I can try and see if I can reproduce?

[sonulohani]

@89luca89 Added, In my host I am using starship prompt which is what derived in the guest.

[89luca89]

Also I see you're using some sort of custom prompt? Which is it so I can try and see if I can reproduce?

This is also important

With the same setup (docker, 20.04 host, 22.04 guest) I cannot reproduce the issue

[PgBiel]

I actually have had similar issues and intended to open an issue about this sometime - it's possible to fix, but perhaps there is a way for distrobox to fix those little issues automatically

Basically, sometimes containers have those little visual glitches (I use ZSH), and, for me, it always turned out to be one of two things: (take a look at them both)

1. The container doesn't know about the terminal being used. When I use Alacritty instead of Konsole, for example, some containers display very weird visual bugs due to $TERM being something that the container doesn't support (such as alacritty itself). Sometimes it works out of the box, sometimes it breaks. (Related PR in toolbox: https://github.com/containers/toolbox/pull/544)

In that specific case, it might be handy to install the appropriate terminal's terminfo in the container (such as https://github.com/alacritty/alacritty/blob/master/extra/alacritty.info). In general, maybe a function to automatically detect the $TERM being used and install the terminfo file from the host system into the container (if available) could be a way to automatically fix this. Alternatively, setting TERM=xterm-256color by default on containers seems to work usually (I'm yet to find a counterexample for this).

Note that this isn't always the issue though. In fact, I haven't faced this issue much anymore (I guess it depends on the container's OS). There is another issue which I have faced recently and is worthy of note, which also caused those visual glitches (and fixing this issue fixed the glitches for me).

2. The container has wrong locale / no UTF-8 locale generated. I noticed this with an Arch Linux container, and it happened even with Konsole and TERM=xterm-256color; it took me some debugging to notice that no non-ASCII characters worked (I tried to paste stuff like á or ç or whatever into the terminal in the container and it would just display something like <ffffff>). The solution was to generate locales for en_US.UTF-8 (following instructions in https://wiki.archlinux.org/title/locale#Generating_locales), which not only let me paste special characters, but also fixed all visual glitches I had. (I also made sure certain env vars were appropriately set, such as LC_CTYPE="en_US.UTF-8", LANG="en_US.UTF-8" etc. - but that wasn't enough at first, at least not without generating the locales.) Note that, for me, this also fixed an issue with some exported apps replacing UTF-8 characters by ? on all output.

For Debian-based containers, the solution for me was sudo apt install language-pack-en - it automatically generated the correct locales. There should be similar solutions for other container OSes as well.

So, I believe it might be interesting for distrobox to automatically generate (on container creation) the appropriate locales (based on the host's locale env vars maybe, but generate at least some UTF-8 locale). Maybe, at least, such issues and their solutions could eventually be exposed in the docs.

If I find anything else, I'll make sure to share - but that's what I could gather so far. @sonulohani make sure to check if your issue fits into one of the cases above.

[89luca89]

Thanks @PgBiel that was a really nice write up!

So for issue 1, TERM set to something not supported inside the container, is something that I find out of scope from distrobox for 2 reasons:

• you can install them if you need
• overwriting a variable to the user is generally not what we want to do

Warning the user should be ok.

For the second issue, the localce one, if you can give me some tests to check it, I'll gladly add the locales to the base installations if possible, at least for the default UTF-8 one

About @sonulohani issue, does any of the solutions @PgBiel wrote fix this for you?

[sonulohani]

After using kitty, I don't see this issue anymore. The issue was with gnome-terminal.

[PgBiel]

This suggests the problem was likely with the TERM business, but, regardless, @89luca89 I think a separate issue should be opened for the locale issues, as I can verify the problem is still there when I create new containers

I sadly don't know the best way to make a test for this, but I found this issue when using wf-msg in an Arch container, and it would print things (such as window names) with question marks instead of Unicode characters until I fixed the locale. If I find a way to obtain a minimal working example that does the same, I'll surely share.

(Sorry for the lack of reply, been pretty busy IRL lately lol.)

[sonulohani]

This suggests the problem was likely with the TERM business, but, regardless, @89luca89 I think a separate issue should be opened for the locale issues, as I can verify the problem is still there when I create new containers

I sadly don't know the best way to make a test for this, but I found this issue when using wf-msg in an Arch container, and it would print things (such as window names) with question marks instead of Unicode characters until I fixed the locale. If I find a way to obtain a minimal working example that does the same, I'll surely share.

(Sorry for the lack of reply, been pretty busy IRL lately lol.)

Actually using kitty also didnt solve the issue. Sorry that I closed the issue but seems like it didnt fix the issue either by installing the language package.

[PgBiel]

Actually using kitty also didnt solve the issue. Sorry that I closed the issue but seems like it didnt fix the issue either by installing the language package.

What is the value of TERM (from echo $TERM)? Is it xterm-256color? If not, does export TERM=xterm-256color fix it?

[89luca89]

I was thinking this, TERM could be the issue? It would be useful if you declare a new TERM inside the zshrc before oh-my-zsh sourcing?

[fedemp]

Ey, hello. I've recently commented on Reddit about a similar issue.

Desktop (please complete the following information):

• Are you using podman or docker? Podman on Silverblue 37
• Which version or podman or docker? Podman 4.3
• Which version of distrobox? Distrobox 1.4.1 from Fedora repos.

In my case, if I press ^P on a shell, previous command is not shown; current text remains. But if I press Enter, the previous command is executed and printed as expected.

I'm using two different terminals, but both based on VTE: gnome-terminal and blackbox (as Flatpak). Both identify as xterm-256color.

I've tried $TERMINFO=xterm-256color distrobox enter but issue persists. Inside any container, $TERMINFO is always undefined (by default, I mean) and $TERM is xterm-256color.

I've tried defining a locale with locale.conf and locale-gen inside an Arch container, but no changes occurred.

I've installed different terminals inside the container and most of them worked fine when launched from there. I used urxvt, alacritty and terminator, and all worked great. gnome-terminal was the exception cause even though I launched it from inside a container, the one installed in the host is the one running.

For reference, this is my original reddit thread: https://www.reddit.com/r/openSUSE/comments/yxvx8y/comment/iwsskea/ Please note that even though I first experienced this issue using OpenSUSE MicroOS and now I'm on Silverblue 37.

---

Edit:

I have installed in a Fedora container langpacks-en and locale changed from C.UTF-8 to en_US.UTF8 but still no progress.

Moreover, when I exit the container, An error ocurred is printed twice in two different lines.

[PgBiel]

@fedemp From my tests, indeed ^P seems to be visually broken inside containers; however, as a workaround, you can press ^P followed by a space and the command to be executed will show up.

[89luca89]

Folks, just to follow up on this:

Does all this problem persist if you set up a normal container and run your setups there?

podman run archlinux:latest bash

for example, then install zsh (with oh-my-zsh) and check there if these glitches persists

Thanks!

[fedemp]

@fedemp From my tests, indeed ^P seems to be visually broken inside containers; however, as a workaround, you can press ^P followed by a space and the command to be executed will show up.

Just for the record, this is not true for toolbox.

I've just tried running a container through podman as mentioned above and ^P is broken, but ArrowUp works fine with zsh and https://github.com/romkatv/powerlevel10k

[juhp]

Hmm I just tried with my distrobox centos stream 9 container (running bash) and when I press Ctrl+P repeatedly it alternates between no change and jumping back twice in the shell history.

Podman uses detach_keys="ctrl-p,ctrl-q" in its default configuration. I think toolbox disables that with --detach-keys "". That might help here?

See podman-run(1) and podman-exec(1) for details.

[fedemp]

@juhp You are right. I've created a containers.conf in ~/.config/containers/containers.conf

[engine]
detach_keys=""

and now ^P works.

[juhp]

Does someone want to open a PR to make distrobox use --detach-keys "" by default?

[89luca89]

Thanks for the finding @juhp :smile:

Will add it now :+1:

[89luca89]

Cool that works now, what about the glitches you folks were experiencing? There is also another issue #507 seems similar but about chars being left behind, not sure if are correlated

[89luca89]

This was related to missing glibc locales, I've now fixed this by setting up at least en_US.UTF-8 by default At least this way it does not revert to C.POSIX which would let to these errors

I've tested it with various distros and after the commit, the glitch disappeared