http://bugzilla.opensuse.org/show_bug.cgi?id=1054448
http://bugzilla.opensuse.org/show_bug.cgi?id=1054448#c109
--- Comment #109 from Dr. Werner Fink
[1]Otherwise it would be never possible to develop new features for XTerm supported by the TERMINFO entry xterm or xterm-256color
This isn't solved for xterm itself either, assuming that users might ssh across systems. The whole approach with the TERM variable referring to a local file, and then only this variable getting forwarded across ssh is a broken concept. IMO it's way beyond the scope of this bugreport to design, let alone implement and adopt something better.
ncurses 6.1 has a new 32bit format for e.g. xterm-256color and if konsole can not read this do not using libtinfo then this is not a bug of ncurses. If a user or the system setup uses xterm-256color even if it is known that a remote system can not handle this as xterm-256color is not known then this is also not a bug for ncurses (In reply to Wolfgang Bauer from comment #108)
(In reply to Tad Bilby from comment #107)
It looks like the xterm-256color terminfo file is the issue. $ infocmp infocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm-256color # zypper in terminfo No update candidate for 'terminfo-6.1-1.1.x86_64'. The highest available version is already installed $:/usr/share/terminfo/x> file xterm-256color xterm-256color: Compiled 32-bit terminfo entry "xterm-256color" $:/usr/share/terminfo/x> file xterm xterm: Compiled terminfo entry "xterm"
That seems to be normal.
Does konsole read any information from an terminfo entry specified by the TERM variable? If this is done (xterm does it) how this is done? If onw code in konsole or the QT/KDE libraries does this, then the question rises if this code can handle 32bit terminfo entries? The libtinfo 6.1 can handle this extend format -- You are receiving this mail because: You are on the CC list for the bug.