$term

Michael-Sanders said:
What is the rationale behind the $TERM variable defaulting to type xterm?
Click to expand...

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.
 
Yes, in fact it does here with a stock/pristine installation of release 9.0 (from the USB image). At the console, $TERM defaults to 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.
Click to expand...

This is FreeBSD, whose users would not have terminfo unless they have installed the ncurses port. (ncurses in base pretends only to be termcap). If they have the ncurses port, then an even better place to see that while "most...", that is not a good default, since there are differences. Use "infocmp xterm gnome" to see the problems with the usual "most...". ncurses has also entries for: putty, konsole, mlterm and of course rxvt.
 
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
Click to expand...

Perhaps not dialog (which works fine in either terminal). Also xterm-capable is a relative term - I'm reasonably certain that xterm has a lot of features not in the 9.0 console emulator - though for someone using termcap, much of that would not be apparent (since the termcap is smaller than the terminfo).
 
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
Click to expand...

More likely it was changed because of the prevalence of scripts which assume that TERM is "xterm". However, those have always been a problem rather than a solution. For more insight, see http://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
 
a bourne conditional statement can be used against the shells behavior depending on what $TERM is set to.

One example I can think of off the top of my head is using a fancy zsh prompt when running a gui and having a simple one when not running X.
 
Not a bad idea actually:

$ [ -z $DISPLAY ] && echo console || echo x11

I'm guessing the FreeBSD developers would know why the change was made to xterm.
 
Michael-Sanders said:
I'm guessing the FreeBSD developers would know why the change was made to xterm.
Click to expand...

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.
 
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.
Click to expand...

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!)
 
Everything aside, it's only a default. One can of course always edit shell initialisation files such as ~/.(t)cshrc, ~/.profile etc. and/or files in /etc/skel/ to change $TERM from xterm into something else.

Apparently, xterm is considered a sensible default. I assume this decision hasn't been taken overnight.

Fonz
 
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!)
Click to expand...

That would be, but taking a look at FreeBSD 9.0 (using vttest and tack), it seems that this message's comment about CP437 still applies: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009351.html:

The kernel will use a table
to remap all Unicode characters to CP437 (the default VGA font), so it's
practically useless.
Click to expand...

It has these features for compatibility with xterm: color (including back color erase), some of the function-keys, part of the mouse behavior.

But it lacks support for line-drawing characters, as well as the shifted (and other modifiers) for function- and cursor-keys, and does not implement the alternate screen feature. Blinking text is implemented as a color.
 
You must log in or register to reply here.
Back
Top