DietPi tools wrong menu width via ssh

davidmartos96 commented 2 years ago

Creating a bug report/issue

Required Information

DietPi version | cat /boot/dietpi/.version G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=7 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'
Distro version | bullseye 0
Kernel version | Linux DietPi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
SBC model | RPi 4 Model B (aarch64)

Additional Information (if applicable)

Software title | dietpi-config and similar tools
Was the software title installed freshly or updated/migrated? Fresh install
Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

Remotely connect to the dietpi host with ssh using a terminal. I've tried with gnome-terminal and with tilix
Run dietpi-config
Press the down key
The menu entries now appear with an offset

Expected behaviour

Menu UI should render the same as when connected to a screen + keyboard

I can reproduce the issue on gnome-terminal and on tilix. It behaves correctly in xterm.

Some screenshots

1st image:

Run dietpi-config via ssh

2nd image:

After moving through the menu. Take a look at number 5 or 7. It has an extra "s" at the end. This is very noticeable when interacting with toggle-like entries ([*] Firefox)

Joulinar commented 2 years ago

I guess it is related to the terminal you are using. Personally I have no issues using Putty.

davidmartos96 commented 2 years ago

@Joulinar Yes, that is what I thought when I saw that it worked on xterm. It would be great if someone could reproduce it in a Linux terminal like gnome-terminal or tilix. Maybe it behaves weirdly in KDE as well.

Ast3risk-ops commented 2 years ago

This has happened when I resize an ssh window

Ast3risk-ops commented 2 years ago

although to a much larger extent

Ast3risk-ops commented 2 years ago

although to a much larger extent

as in the menu completely deforms

Ast3risk-ops commented 2 years ago

but that's probs just the menu as this happens with any whiptail-style menu on any terminal and any pc for me, even locally.

MichaIng commented 2 years ago

Ran some tests on VMs:

With gnome-terminal locally, DietPi menus look fine.
Within gnome-terminal connecting via dbclient (Dropbear) to another VM and starting DietPi menus within the SSH session looks fine as well.

While above were tested via gnome-terminal as standalone X session, I tried the same from within an LXDE session, to be able to resize the terminal window. When reducing the terminal width so that content does not fit in one line anymore, a line break is added so that content appears at the left side of the terminal, once a related line is marked (in menus): whiptail

This is however the same on any console type, SSH, local, from Windows and Linux client. The above screenshot was done via PuTTY from Windows. Also it is fixed as fast as a menu item is selected, i.e. a new whiptail window. It is a whiptail internal limitation that it cannot adjust its size dynamically, already since the exact size is given when starting the command. And it is pretty normal for a lot of GUI and console applications what they do not react dynamically to resized terminal windows.

And it is not the issue OP faces.

I further tried it with OpenSSH, with tilix, and to rule it out connecting the other way round from a Buster system to Bullseye (above Bullseye to Buster), same results, unable to replicate.

So I think we'd need the exact client system, SSH client, desktop environment, host OS etc, as well as DietPi SSH server, to try replicating with the exact same setup. It seems to be however a very specific issue and definitely out of our control, but a limitation of either the terminal emulator and/or whiptail itself.

@davidmartos96 What does echo $TERM tell you on the client terminal? It's xterm-256color in all cases here, hence I'm asking. Probably it is relevant for how the terminal presents the whiptail menu. With dialog e.g. TERM=xterm causes quite some issues.

davidmartos96 commented 2 years ago

@MichaIng Yes, I have xterm-256color as well.

MichaIng commented 2 years ago

Okay, then

I think we'd need the exact client system, SSH client, desktop environment, host OS etc, as well as DietPi SSH server, to try replicating with the exact same setup.

Ast3risk-ops commented 2 years ago

Hmm, I only have this issue when resizing menus locally or over ssh (I use openSSH for Linux)

Ast3risk-ops commented 2 years ago

Reload the menu, and it fixes

davidmartos96 commented 2 years ago

@Ast3risk-ops The issue I'm seeing is not when resizing the terminal. It occurs with a fixed size when using the arrow keyboards to navigate.

@MichaIng

Host

Linux fedora 5.19.10-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Sep 20 15:15:53 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

About Gnome Terminal

Version 3.44.1 for GNOME 42 Using VTE version 0.68.0 +BIDI +GNUTLS +ICU +SYSTEMD

SSH server

sshd -h OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n 15 Mar 2022

MichaIng commented 2 years ago

@Ast3risk-ops Yes, this matches my testing. But I do not see this as real issue at all, as said, when resizing the terminal/console it is totally expected that console UI applications need to be refreshed. Watching terminal sizes continuously and updating output when it changes would be quite a large overhead, especially for console applications which are usually meant to run lightweight. So let's ignore this one. I'd still try to replicate the different issue of OP when I find time to setup such Fedora system.

Ast3risk-ops commented 2 years ago

Okay, I use arch with the KDE konsole with hack nerd fonts and openSSH

MichaIng commented 1 year ago

@davidmartos96 The issue still persists with latest Fedora? Did you take the workstation x86_64 image? https://getfedora.org/de/workstation/download/

Ast3risk-ops commented 1 year ago

omg this is so old I stopped using DietPi but menus like this still always work for me so long as the window is wide enough for the menu

davidmartos96 commented 1 year ago

@MichaIng It appears to be working fine on VTE based terminals now. Tested on gnome-terminal. Fedora 37

I tested it a bit more and making the "Ambiguous-width character" to Narrow (the default) makes it work, and Wide reproduces the issue. Switching between those before made no difference.

I believe this could be closed now.

MichaIng commented 1 year ago

Ah great. Obviously whiptail makes use of ambiguous-width characters. I guess TAB is meant by this. I just wonder what "wide" means here since 8 spaces seems to be common on Linux consoles:

root@micha:~# echo -e '\ttest'
        test

and I never heard of TAB being more than 8 spaces. But probably it also depends on the terminal type, is communicated somehow via terminfo>$TERM and does not match to what gnome-terminal makes of TAB when setting it to "wide".

However, marking this as closed then.

MichaIng / DietPi