On 2007-09-07, Eyolf strem <[EMAIL PROTECTED]> wrote:
> Where and how should I set the TERM variable?
The terminal itself should set this. It puts this variable in the
environment of any subprocesses it spawns so that the application
and/or the curses library used by the application knows, by means
of the terminfo database, what capabilities the terminal has and
what character sequences to send to the terminal to invoke each
capability.
> I guess there are five possible levels here: environment/shell,
> Xterm, Screen, ncurses, and application. My distro's wiki
> (Archlinux) says that it's a bad idea to set the TERM variable
> in .bashrc, but that applications should be able to figure it
> out for themselves.
Right. By putting TERM in your .bashrc you are overriding the
terminal's setting and assuming that you are always using only one
terminal type.
> So, which of these possible values of TERM do I put where?
> xterm
> xterm-256color
> screen-256color
> screen-256color-s
> screen-256color-bce
> screen-256color-bce-s
>
> Should it be the same everywhere I set it?
It depends. Ideally, you should use the value whose terminfo
database entry most accurately describes the capabilities of the
terminal you are actually using. When using screen, however, the
application is communicating with your terminal through screen, so
while screen should sit transparently between your terminal and the
application, screen does have to know something about the character
sequences being used to control the terminal.
Also, there are some applications that are hard-coded to recognize
certain terminal names. They may know what to do with "xterm" but
not "xterm-256color".
> Or does e.g. screen translate screen-256color to xterm-256color or vice
> versa? Or override xterm's choice (xterm-256color) with its own?
I believe that unless you tell it to do otherwise, screen sets
TERM to "screen". You can tell screen to behave differently. Refer
to my earlier reply and the screen man page.
> What exactly does that setting do anyway? Tell applications what to load
> from the terminfo database? about how to translate input (keypresses) to
> output?
It depends on the application. It basically tells the curses
library what terminfo database entry to use, so the application
just calls curses/terminfo functions to control the terminal
and the library takes care of the details, but applications may
choose to make other decisions based on the value of TERM or to
access some terminal capabilities directly.
> How do I make changes to the terminfo database?
Using infocmp and tic.
> Are they dangerous?
Yes, tic can be, if you are running as root or otherwise have
permission to change the files in the terminfo database.
> Can i corrupt anything? Will experimenting cause damage?
Yes. Maybe.
> How do I revert?
By default, the curses/terminfo library uses the system terminfo
database, e.g., /usr/share/lib/terminfo. Setting and exporting the
variable TERMINFO in your environment to another directory will
cause curses/terminfo to look there first for terminfo files. This
can give you a safe place to experiment with changes to terminal
definitions without messing up the system database. For example, I
have in my ~/.profile,
TERMINFO=$HOME/lib/terminfo
> How much does this have to do with curses?
Everything. Applications often use a curses library to interface
with the terminal they're running in. That library uses the
terminfo database to figure out what character sequences to send to
the terminal in order to execute a particular curses function.
Things that can go wrong include:
- The TERM value is incorrect for the terminal being used.
- The terminfo database entry for TERM is missing, incomplete or
otherwise doesn't contain accurate information for the terminal
being used.
- The curses library used by the application is old, broken or
otherwise doesn't allow the application access to all of the
terminfo capabilities. (The HP-UX 10.20 curses library, for
example, didn't recognize colors.)
- The application uses its own idea of a terminal's capabilities
instead of or in addition to the terminfo database.
HTH,
Gary
