Text terminals

From Helpful
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, 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 and is probably a first version, 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:
xterm+88color
xterm-88color
xterm+256color
xterm-256color
putty-256color
screen-256color
  • 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
    putty*|screen*|xterm*|rxvt*)
       PS1="[fancy term] \u on \h \$ "
       alias ls='ls --color=auto '
       ;;
    *)
       PS1="[other term] \u on \h \$ "
       ;;
 esac

Notes:

  • 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.


Termcap

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

Termcap

  • names some terminal types, and defines the according capabilities
  • hooks some specific (per-terminal) escape sequence implementations onto specific commands

This allows remote terminals to be relatively device/implementation-independent

terminal status / hardstatus

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, 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 (how to access it is now often specified 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 at most a line's worth.


Terminal emulators can be set to show this somewhere, e.g.

GUI terminal emulators can be set to update the graphical window's title
putty can add it in an extra line (not part of the normal terminal)
screen can add it in an extra line (hardstatus alwayslastline[1])
see also e.g. https://www.gnu.org/software/termutils/manual/termcap-1.3/html_node/termcap_41.html


They will often use each term's hardline to store the window title, (the exact logic to this varies, and is often configurable) which is why sometimes things fight over what this shows/contains.



tmux/screen can also read each contained terminal's, and change what they set in their viewer's terminal based on that - see also Screen_and_tmux#On_status_lines_and_titles)


See also