Text terminals

From Helpful
(Redirected from TERM)
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)
These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.

TERMinal type

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)

Terminals come from the mainframe days, cases where computers were heavy fancy things that you could put more than one user on. Terminal, as in a display and keyboard "at the end of a line". Hardware terminals. heavy plastic things.

Terminal now usually means terminal emulator, meaning you're using software to imitate that hardware, which includes most types of "relaying a display-and-keyboard session" on a computer, including:

remote logins (e.g. SSH, and historically things like telnet and rsh)
terminal hosters/proxies (e.g. screen, tmux, hurd)
local/remote graphical logins (xterm, rxvt, gnome-terminal, konsole, OSX terminal, etc.), and other specific terminal software (consider e.g. cygwin, windows telnet)

Any terminal worth anything has VT100 compatibility, as it became the de-facto basic set of features via its popularity.

Most things used now have more to add, but may do it in very specific ways.

Which means the terminal emulator and what it's talking to need to know about what the other speaks. Basically, they tell each other whether specific features (say, color, scrolling back, drawing) are supported, and how to use it with them.

In *nix, the client advertises most of its capabilities by setting a name in the TERM environment variable. A name maps to a set of features, so the commonly used names don't really mention what a terminal is, but what it supports (which also means you should only set a TERM you the terminal emulator actually supports). (on *nices this is handled via termcap).

Some TERMs:

  • vt100 for the most basic vt100
most things are capable of more
  • linux seems typical for text-mode shells
roughly "vt220 and colors"(verify)
  • xterm is a basic shell under X
roughly "vt220 and colors"(verify)

  • rxvt is a specific X shell with a few more capabilities than xterm
also used by similar graphical shells.
There are different sets for gnome-terminal, konsole, and others, though they may also just set xterm-256color or such. You rarely deal with these directly though.
  • screen is what each term in a screen gets. Seems to be fairly basic VT100, plus some extras?
You can configure screen to report itself as something else, e.g. xterm-color.
screen itself looks for a termcap entry called screen.$TERM

  • putty (basically VT102 plus a few spected features?)
  • vt100-putty (or putty-vt100?)
  • putty-256color
  • konsole

For many there are variations, like having/lacking colors.

There are many hardware-specific entries that you'll probably never set/use directly.

Look at your /etc/termcap

Some pragmatics:

  • If F1..F12, numpad keys, Backspace, Delete, Home, End, or such don't work (produce garbage), you probably need to tweak TERM
  • things should test for prefixes, because it's now common to do things like:
  • PuTTY defaults to xterm
If shelling to linux, you may be better off using linux (I had troubles with various keys that were fixed this way)
putty may work even better (verify)
  • if you tweak things in login scripts, TERM tests should often be 'starts with', not 'is', because variations tend to be -tacked-on

You can change program behaviour based on TERM values. For example:

case $TERM in
       PS1="[fancy term] \u on \h \$ "
       alias ls='ls --color=auto '
       PS1="[other term] \u on \h \$ "


  • applications may also look at TERM to choose what to do, in particular if they do colors or fancy drawing.

Some applications may work better when forced/restricted to behave according to a specific TERM. For example,

alias mc='TERM=xterm mc'

...which is also how I discovered (without logging out and in a bunch) that mc seems to work better with putty than linux.


terminal status / hardstatus

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)

The terminal status is is a region of text that is separate from the main shown terminal text.

It was intended to be a message from an active program, which is not normally shown and only accessible via specific commands (now typically handled via termcap)

It is a concept originating in hardware/serial terminals, and some (e.g. screen, tmux) call it hardstatus, apparently pointing to this origin,

Some call it a status line, pointing to that this is usually a line's worth (but, note, may be shorter).

You can often get GUI terminals to set the hardstatus in their title bar. (tmux/screen also indirectly use it in their status lines - see Screen_and_tmux#On_status_lines_and_titles)

See also