Error opening terminal: xterm-256color

[humdinger]

This is hrev45438.

Opening a Terminal and starting "nano" works. Connecting to a Linux running MediaPlayer via ssh and starting "nano" there results in: "Error opening terminal: xterm-256color.".

Putting "export TERM=xterm" into /boot/common/etc/profile appears to fix the issue. At least "nano" now starts remotely.

[siarzhuk]

The remote (Linux) termcap/terminfo database is outdated and has no xterm-256color entry. The remote should be updated to fix the issue in the right way. :-\ Tweaking $TERM on the Haiku side is also possible and, hopefully, will have no visual issues because xterm-256color treated as xterm with 256 colors.

[bonefish]

TBH, I don't understand why we're setting TERM to "xterm-256color". Back in the day when I changed it from "beterm" or what it originally was to "xterm" I did that exactly to avoid those compatibility issues. The whole termcap system is broken by design and IMO we should just go the path of the least resistance and set TERM to "xterm". To my knowledge that's what pretty much every OS and distribution that matters does as well.

[siarzhuk]

Replying to bonefish:

TBH, I don't understand why we're setting TERM to "xterm-256color".

Because "xterm" has Co (color count) set to 8. So to let the newest versions of console apps (text editors for example) profit from our 256 colors support out of the box - I have switched to xterm-256color and fixed the Terminal BCE processing.

Back in the day when I changed it from "beterm" or what it originally was to "xterm" I did that exactly to avoid those compatibility issues.

Yes, from the same reason I have rejected any patches that have proposed to introduce the "haiku" terminal entry.

The whole termcap system is broken by design

Let me to not agree here - it is just outdated nowadays. libtermcap that we are using is looking like abandoned at the moment. But you are right that termcap format is restricted.

and IMO we should just go the path of the least resistance and set TERM to "xterm".

I suspect that console applications do not disappear for the nearest decade so we have to take care about them anyway. IMO, the only reasonable way to keep this sub-system up to date - is switching from termcap to terminfo that is more flexible and maintained as part of ncurses package. More ideas and arguments are here: ​http://www.freelists.org/post/haiku-development/What-to-do-with-termcap

To my knowledge that's what pretty much every OS and distribution that matters does as well.

Corresponding to Thomas E. Dickey: ​http://invisible-island.net/ncurses/ncurses.faq.html

"Additionally, Mac OS X 10.7 is reported to use xterm-256color as a default $TERM value."

So looks like I'm not alone who think this way.

[bonefish]

Replying to siarzhuk:

Replying to bonefish:

The whole termcap system is broken by design

Let me to not agree here - it is just outdated nowadays. libtermcap that we are using is looking like abandoned at the moment. But you are right that termcap format is restricted.

Let me rephrase: The whole client-side terminal description concept is broken by design. Theoretically one has to create a new terminal type whenever one wants to modify an existing one. That would render the terminal broken for all remote systems that haven't been updated yet. Adjusting the old terminal description has similar -- though not as severe -- issues. The obvious solution is to introduce an escape sequence for asking the terminal about its capabilities and change the terminal type one last time. If the sequence is well chosen, for a transition period one might even get away with keeping the old terminal type.

To my knowledge that's what pretty much every OS and distribution that matters does as well.

Corresponding to Thomas E. Dickey: ​http://invisible-island.net/ncurses/ncurses.faq.html

"Additionally, Mac OS X 10.7 is reported to use xterm-256color as a default $TERM value."

I stand corrected (though one could ask whether MacOS actually matters wrt. terminals ;-)).

So looks like I'm not alone who think this way.

No doubt, setting the correct terminal type would be the best solution, *if* every possible remote client supported that type as well. But obviously that is not the case, as the existence of this ticket proves. Since major Linux distributions apparently alias "xterm" to "xterm-256color" and set TERM to "xterm", I think it is safe enough to do and the most convenient option for users ATM. We could switch back to "xterm-256color" later when we feel support for it has improved sufficiently.

[siarzhuk]

Replying to bonefish:

To my knowledge that's what pretty much every OS and distribution that matters does as well.

Corresponding to Thomas E. Dickey: ​http://invisible-island.net/ncurses/ncurses.faq.html

"Additionally, Mac OS X 10.7 is reported to use xterm-256color as a default $TERM value."

I stand corrected (though one could ask whether MacOS actually matters wrt. terminals ;-)).

Not less than Haiku. ;-)

So looks like I'm not alone who think this way.

No doubt, setting the correct terminal type would be the best solution, *if* every possible remote client supported that type as well. But obviously that is not the case, as the existence of this ticket proves. Since major Linux distributions apparently alias "xterm" to "xterm-256color" and set TERM to "xterm", I think it is safe enough to do and the most convenient option for users ATM. We could switch back to "xterm-256color" later when we feel support for it has improved sufficiently.

IMO, we will be blamed anyway, either we will define TERM to "xterm" or to "xterm-256color". In the first case local vim users will be disappointed, in the second - lovers of ssh sessions to servers with outdated terminfo. As soon as we fix this issue by reverting to xterm - the next week come someone and complain about bleached xoria256 in vim. ;-)

There are also dirty way - hack the xterm entry and extend colors and color pairs entries to 256 and 32767 correspondent. ;-) But that breaks the hypothetical consistency with the "reference" xterm in the outside world, that anyway nobody care about.

BTW, that (modify TERM per session) looks like yet another feature for Terminal Profiles mentioned here: https://dev.haiku-os.org/ticket/5030#comment:8

[bonefish]

Replying to siarzhuk:

There are also dirty way - hack the xterm entry and extend colors and color pairs entries to 256 and 32767 correspondent. ;-) But that breaks the hypothetical consistency with the "reference" xterm in the outside world, that anyway nobody care about.

But does it break anything that matters? Apparently most (any exception?) Linux distributions use "TERM=xterm" and, assuming that virtually all console programs are actively maintained for Linux, I can't really believe that it does.

BTW, that (modify TERM per session) looks like yet another feature for Terminal Profiles mentioned here: https://dev.haiku-os.org/ticket/5030#comment:8

Since TERM must be set before starting the shell, that would require some UI to explicitly start a new session with a certain profile.

[siarzhuk]

That is the difference:

~/Desktop # infocmp -d xterm xterm-256color                                                                                                           [18:56]
comparing xterm to xterm-256color.
    comparing booleans.
        ccc: F:T.
    comparing numbers.
        colors: 8, 256.
        pairs: 64, 32767.
    comparing strings.
        initc: NULL, '\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\'.
        setab: '\E[4%p1%dm', '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m'.
        setaf: '\E[3%p1%dm', '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m'.
        setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
        setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.

can_change		ccc	cc	Terminal can re-define existing colour
orig_colors		oc	oc	Set all colour(-pair)s to the original ones
max_pairs		pairs	pa	Maximum number of colour-pairs on the screen
initialize_color	initc	IC	Set colour #1 to RGB #2, #3, #4
set_a_background	setab	AB	Set background colour to #1 using ANSI escape
set_a_foreground	setaf	AF	Set foreground colour to #1 using ANSI escape
set_background		setb	Sb	Set background colour to #1
set_foreground		setf	Sf	Set foreground colour to #1

I tried to hack colors and pairs in "xterm" and observe no visual differences. So we can try to do this and look what occure.

Yes, profiles implementation in Konsole, for example, uses additional UI elements.

[siarzhuk]

Proposed "xterm" workaround applied in hrev45500.