defect terminal fonts used

[jojoax]

After building and testing @ my test cluster the useabiliity is broken due visual defective screen views:

System Arch Linux Rolling Release, Status from 2018-07-10 10:00h. Used via ssh remote terminal, KDE/konsole as xterminal.

[deleteriousEffect]

What kind of fonts packages are installed on your system? It's been a while since I used Arch, but they're pretty sparse by default right? Maybe there's some unicode-related package you need to install in your system.

[jojoax]

Standard, minimal on Console. Font by it self has to be irrelevant for such system near tool. Special Chars shold never used in Termial environments of productive sorroundings. If did so, =>> Result see Screen Shot, unusable.

In X11 environment we have Source Code Pro as terminal Font.

[lge]

I think it's not so much the font, as the locale. This looks very much like konsole being run in "C" locale, when it should be running in some UTF-8 capable locale. drbdtop (on the other end of the ssh session) may or may not see the same locale konsole is expecting, which makes this situation "hard" to even detect on the drbdtop side. If the environment drbdtop is running in and the terminal emulator disagree about the locale, that's not something that is fixable in drbdtop (unless you prefer to restrict all output to 7 bit ASCII; in 2018, I disagree).

I suggest that you get your setup UTF-8 clean. May help with a number of other "issues" as well. Edit /etc/locale.gen, ensure that your preferred .UTF-8 locale (e.g. en_US.UTF-8) is uncommented, execute locale-gen to generate the locales. Put LANG=en_US.UTF-8 into /etc/locale.conf. You may need to completely logout and login again. locale then should show you that locale.

If someone on a "working" system needs a "reproducer": LC_ALL=C konsole, then either use drbdtop directly, or ssh into some drbdbox and use drbdtop there. If someone feels the urge to create some "--ascii" switch for drbdtop, go ahead. I don't :-)

[raltnoeder]

Cannot reproduce, neither with any of the fonts I have installed nor with the locale. It could also be the setting of the TERM variable. If that does not match what the terminal emulator implements, then the output will be messed up (e.g., if I run with vt100 in a KDE Konsole, then I get incorrect output).

Unfortunately, terminal types, terminal control and terminal IO on any kind of Unix-like operating system is a total train wreck, due to the presence of half a million different terminal types that are all incompatible with each other, a lack of sane standards and the failure of the multitude of different terminal emulators to fully and correctly implement the feature set of the terminal types they claim to implement.

Anyhow, the utility has certain requirements, which includes a font that is able to render box drawing characters and a terminal that implements certain ANSI escape sequences.

[nicholas-cross-fujitsu]

I know this is closed but i have this same issue in a PuTTY session to CentOS8 streams.#

[veitw]

I have encountered this issue on CentOS 8, too, connecting via SSH from GNOME Terminal with LANG="de_DE.UTF-8" and TERM="xterm-256color".

This does not occur with TERM="xterm", so as a workaround I set up an alias in ~/.bashrc:

alias drbdtop="TERM=xterm drbdtop"

HtH // Veit