What is the rationale behind the $TERM variable defaulting to type xterm?
Michael-Sanders said:What is the rationale behind the $TERM variable defaulting to type xterm?
SirDice said:It doesn't. If you log in on the console you'll see that TERM is set to cons25.
Now, most graphical terminals like x11/xterm default to xterm.
The TERM variable defines what capabilities the connected terminal has. This ranges from basic information like the width and height to what codes to send to use underlines, bold, italics.
See terminfo(5) for more detailed descriptions.
kpa said:The console terminal emulator on 9.0 is xterm capable and TERM defaults to xterm. I think it was changed to simplify utility programs like dialog(1) that previously required hacking to get them to work on both xterm and cons25
kpa said:The console terminal emulator on 9.0 is xterm capable and TERM defaults to xterm. I think it was changed to simplify utility programs like dialog(1) that previously required hacking to get them to work on both xterm and cons25
Michael-Sanders said:I'm guessing the FreeBSD developers would know why the change was made to xterm.
itcotbtoemik said:That is, to use "xterm" as a default $TERM. You can find the answer to that by googling for mention of "TEKEN_UTF8" and "TEKEN_XTERM" (starting in 2009). For instance this (one of the earliest mentions)
http://lists.freebsd.org/pipermail/svn-src-all/2009-January/003710.html
gives as a reason the intention of allowing cons25 and xterm to coexist. Initially the motivation was to provide UTF-8 support in the console. There were other comments along the way citing improved standards (given that xterm has become the standard), though I don't recall exactly where to look to provide a useful source.
UNIXgod said:hmm. I'm assuming I can see UTF-8 characters within a screen/irssi session without x running. That would be a nice thing. (Time to upgrade!)
The kernel will use a table
to remap all Unicode characters to CP437 (the default VGA font), so it's
practically useless.