LDP/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml

<!doctype linuxdoc system>
<article>
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.43 March 2013 

<!--
Change log
v1.43 Mar. 2013 Putty's pterm emulation.  Cleanup.  Shuford's website
 now defunct.  Looking for a new maintainer.  Wyse data missing from
 Internet.  Rewrote abstract.  Clarity in stty raw problem. Links to Wikipedia
v1.42 Jan. 2010  PuTTY serial terminal emulator, cutecom (dumb
 emulator), colors, links to wikipedia,  Boundless still selling
 terminals, small footprint terminals, link to art. on text browsers.
v1.41 Feb. 2008  Better clarity re emulation.  Illusion when
 reverse-video is reversed.  Problem with slow scrolling.  Wyse text
 terminals discontinued and Boundless went bankrupt.  Update on text web
 browsers.  gtkterm, X Window now has many terminal emulators.
 Symantec no longer selling Procomm.
v1.40 Dec. 2006 Picocom is like minicom.  Devfs obsolete so removed
 tts/1, etc.  Updated pseudo terminals.  More about telnet, ssh, and
 non-serial port interfaces.  IBM terminal emulation over telnet.
 Kermit for MS does terminal emulation.  Ports of minicom to Mac.
 Fixed/removed broken links.  "reset" is an alias for "tset"
v1.39 Aug. 2006 Typo your -> you're; Termcap Manual = Termcap Library; Fixed
 several broken links.  Found link to mapchan program.
v1.38 Feb. 2006 Fixed typos "the the"
v1.37 Feb. 2006 "file-transfer" cables, typo: VT012=>VT102, url to
 Text-Terminal source fixed, not revised every few months anymore,
 edited key cleaning
v1.36 Aug. 2004 Typo for "quit", etc.  Should be ^\
v1.35 Mar. 2004 Wyse 60 emulator
v1.34 Dec. 2003: All ~ (tildes) are now in text version (formatting problem with Linuxdoc)
v1.33 Nov. 2003: revised setserial section; using minicom with
directly connected terminals
v1.32: Sept. 2003: man page console_codes, name: serial
monitor/console, "init string" rewrite, netrik text browser, new url
for terminfo
v1.31 Jan. 2003: more on printer port, error char. appearance.
Removed all mention of obsolete /dev/cua, pin numbering, new
X-Terminal HOWTO, Hydra date is 1998 (not 1988), edited thin clients
v1.30 Sept. 2002: fixed typos, redid Windows Terminal Server (Linux client
possible)
v1.29 Mar. 2002: key-switch spring and bending "contact", getty: 
 Red Hat url, getty: source code -> executable code	
v1.28 Jan. 2002: Wyse "manuals" online, fixed a few broken links
v1.27 Nov. 2001: spell checked, more on stuck keys
v1.26 Nov. 2001: text browsers, fixed link to cca.org (was caa.org),
 about 20 typos fixed
v1.25 Oct. 2001: Linux Terminal Server Project, bad line in inittab
may cause respawning too rapidly, Evolution of the "terminal server"
had contents in title (my format error), eliminating overstrikes in
files
v1.24 Aug. 2001: Respawning too rapidly due to no such device, block mode
obsolete,troubleshooting: displays escape sequences, detective work
for repair
v1.23 July 2001: 10-cond. is not RJ45/48 ?, corrupted character attributes
v1.22 May 2001: Clarity: 8-bit, ASCII, national replacement characters,
 CP1252=MS-ANSI
v1.21 April 2001: More on mgetty, getty-login sequence, agetty parity
 problem, types of "terminal servers", parity set shows upper 128
 chars., Correction: PCTerm doesn't work with MS DOS, troubleshooting:
 no CD signal
v1.20 Feb. 2001: Revised: Is hardware flow control done by hardware ?,
 Bash bugs (with terminals), stuck key, PCTerm could work w/Linux
v1.19 Jan. 2001: more on stuck on line 25, more on DEC MMJ cabling,
 dual signal ground wires, programs use terminfo w/o ncurses
v1.18 Dec. 2000: mesg command, respawning error cause, chaos when 2
 processes open same terminal, rebooting
v1.17 Dec. 2000: Don't run getty from the command line,
 XDM-and-X-Terminal mini-HOWTO, substitutes for "local mode",
 character mapping with "mapchan"
v1.16 October 2000: Thin clients+; NC Howtos; Correction of bad typo
 "text terminals are fully obsolete".  Meant to say "not fully
 obsolete".  typo Unbounded => Boundless.  (3 updates this month)
v1.15 October 2000: Thin Clients; some broken url's changed or deleted
v1.14 October 2000: Suse distribution uses /etc/securetty (didn't
 formerly), url of terminfo source, Serial Terminal Linux, pseudo
 terminals, ctty (DOS)
v1.13 June 2000: killing getty permanently, reset bug+, man lilo
v1.12 May 2000: lilo.conf for serial console, reset -> setterm -reset
 (due to bug), scrolling region 25-line problem, sharing+,
 JavaStation-HOWTO.
v1.11 2 March 2000: New link to vtprint, links to char-sets +, typos
v1.10 22 Dec. 1999: Modem status interrupts work, Rubini said no.  
 DoubleVision.  Emulation software, Wyse 60
v1.09 28 November 1999: About 20 changes/clarifications suggested by 
 Rubini, serial-console+
v1.08 October 1999: parity login-loop, slow due to IRQ, removed 
 m4_define TorS, ncurses +
v1.07 August 1999: wyse urls +, terminfo locations +, bits/char prob.
 m4-includes for copyright, setserial (2.15), and stty.  raw mode
 during login, half-duplex set by mistake, only xmit parity, ttysnoop
 details
v1.06 June 1999: typos, more re serial-console, half-duplex, lower hardware
 costs ?
v1.05 May 1999: booting w/o monitor, chatting, dmesg doesn't show all messages
v1.04  April 1999: bit control codes, fixed "If no DTR then elim DTR to
 CTS wire", New Vers., echos ng, serial-console (+ baud patch).  DTR
 at terminal (not computer), full DTR/DSR flow control
v1.03 Jan.1999: screen package, fixed wysetterl link, terms have low
 load on PC, fixed credits, IGNOREEOF, "exit" for logout
v1.02 Nov. 1998: vttest, Don't use TERM for emulation, Mac-Terminal,
 fixed links
v1.01 Oct. 1998: Run levels 456 to 23 in Greg's getty entry. Typos.
 Fixed broken links.  Corrections. Minor changes.
v1.00 Sept. 1998: Major revision. Added Set-Up Options and Esc Sequence
 sections, etc.  Many minor changes.  Merged in info from Greg's
 Serial-HOWTO.
v0.05 June 1998: Elim. DSR from term. flow control.  CTS->RTS.
 Clarity. More on Term server.  Term not client-server.
v0.04 June 1998: Warn against making cables per Serial-HOWTO.  More on
 DTR flow control.  New terminology section.  Better clarity.
 Dial-in/out reversed.  PC as terminal server: Interrupts.   Ref. to
 Serial-Programming-HOWTO.  Login restrictions.  /etc/terminfo ->
 terminfo.src.  Stopped reviewing at Trouble-Shooting.
v0.03 11 May 1998: Added version #.  No version # on earlier ones.
 Added more other names for terminals.  A few typos & more apt words.
 Break signal is +12v (not -12v).  Removed calling smart terminals a
 niche market.
v0.02 May 1998: Interchanged definitions of mark and space.
v0.01 April 1998: Changed Hayes URL.  Changed info on hardware flow
 control to include old-fashioned RTS/CTS handshaking and DTR/DSR flow
 control.  Organizational changes.
v0.00 April 1998:  After reading it over on hikes in Griffith Park and
 correcting many mistakes, etc. I finally submitted it.
-->

<abstract>
This document was originally written for real text terminals which were
like monitors (with keyboards), but could only display text with a command
line interface (no pictures).  They were widely used to access mainframe
computers in the late 1970's and 1980's but use of them declined in the
1990's and they are seldom used anymore.  However much of this howto
also applies to command-line interfaces on Linux PC's which are in wide
use today.  It's not about the user programs one might run on the
command line, but about setting up, managing, and understanding the
interface itself Such as using  a monitor as a virtual (text-only)
console, using a text-window in a GUI such as xterm, connecting to a
remote computer over a network via ssh, telnet, etc., or even using
software on another PC to turn it into a serial-port text-terminal.  All
these 4 methods are known as "text-terminal emulation".

But unfortunately, the main emphasis in this howto is real text
terminals and the coverage of emulation is inadequate for the first 3
methods of emulation mentioned above.  The Keyboard-and-Console-HOWTO
filled much this gap but it was written for Linux 2.0 and now needs
rewriting (or merging into this Text-Terminal howto).  A new author is
needed that has time to do all this.

For the seldom used real text-terminals, it explains how they work, explains how
to install and configure them, and provides some info on how to repair
them.  This HOWTO also provides a brief overview of modern GUI
terminals.
</abstract>
<toc>

<sect> Introduction <label id="intro">

<p> For a quick attempt to install a text-terminal see <ref id="quick_install"
name="Quick Install">.

<sect1> Copyright, Trademarks, Disclaimer, & Credits
<sect2> Copyright
<p> Copyright 1998-2010 by David S. Lawyer.<url url="mailto:dave@lafn.org">
<!-- license.D begin -->

Please freely copy and distribute (sell or give away) this document
in any format.  Send any corrections and comments to the document
maintainer.  You may create a derivative work and distribute it
provided that you:

<enum>
<item> If it's not a translation: Email a copy of your derivative work
 (in a format LDP accepts) to the author(s) and maintainer (could be
 the same person).  If you don't get a response then email the LDP
 (Linux Documentation Project): submit@en.tldp.org.
<item>License the derivative work in the spirit of this license or use
  GPL.  Include a copyright notice and at least a pointer to the
  license used.
<item>Give due credit to previous authors and major contributors.
</enum>

If you're considering making a derived work other than a
translation, it's requested that you discuss your plans with the
current maintainer.

<sect2>Disclaimer
<p> While I haven't intentionally tried to mislead you, there are
likely a number of errors in this document.  Please let me know about
them.  Since this is free documentation, it should be obvious that I
cannot be held legally responsible for any errors.

<sect2>Trademarks.
<p> Any brand names (starts with a capital letter such as MS Windows)
should be assumed to be a trademark).  Such trademarks belong to their
respective owners. <!-- license.D end -->


<sect2> Credits
<p> 
Greg Hankin's  Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A
Terminal Connected To My PC?" was incorporated into v1.00 at various
places (with Greg's permission).  v1.09 of Text-Terminal-HOWTO had
about 25 changes (and error corrections) suggested by Alessandro
Rubini.  For v1.26 I fixed about 25 typos, etc. found by Alain
Cochard.  Jeremy Spykerman told me about using a keyboardless terminal
as a console for a monitorless PC (using ttysnoop).  Numerous other
people have made a suggestion or two or found a few typos.  Thanks.

<sect1> Future Plans: You Can Help
<p>The author is looking for someone to take over maintaining this
howto.  Since real text terminals are pretty much obsolete, there is not
a lot of work to do except that links sometimes disappear and
automatically finding devices such a dumb terminals on a serial port may
not work right.  One project is to rewrite this howto oriented towards
text-terminal emulation with the command line interface.  Another
project would be to start with the brief overview of GUI terminals in
this HOWTO and create a new and up-to-date HOWTO on thin clients or the
like.

Please let me know of any errors in facts, opinions, logic,
spelling, grammar, clarity, links, etc.  But first, if the date is
over a couple of years old, check to see that you have the latest version.
Please send me any info that you think belongs in this document.

In order to fully utilize all the features of a certain real terminal,
one needs the terminal manuals that came with the terminal when it was
new.  If you don't have a manual, this HOWTO may be of some help.  One
way to have solved this problem would be for terminal manufacturers to
put their manuals on the Internet but they never did.  Except that Wyse
made available some of their user manuals and someone scanned old VT-100
manuals.  

<sect1> New Versions of this HOWTO
<p> New versions of the Text-Terminal-HOWTO should be released every
couple of years.  To get the latest version go to an LDP mirror sites (see:
<url url="http://www.tldp.org/mirrors.html">).   To quickly check the date
of the latest version look at <url
url="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Text-Terminal-HOWTO.html"
name="Text-Terminal-HOWTO.html">.  The version your are currently
reading is: v1.43 March 2013 .  

For a full revision history going back to the first version in
1998 see the source file (in linuxdoc format):<url
url="http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml?view=markup" name="(cvs) Text-Terminal-HOWTO.sgml">

<itemize>
<item> v1.43 Mar. 2013 Putty's pterm emulation.  Cleanup.  Shuford's website
 now defunct.  Looking for a new maintainer.  Wyse data missing from
 Internet.  Rewrote abstract.  Clarity in stty raw problem. Links to Wikipedia.
<item>v1.42 Jan. 2010  PuTTY serial terminal emulator, cutecom (dumb
 emulator), colors, links to wikipedia,  Boundless still selling
 terminals, small footprint terminals, link to art. on text browsers.
</itemize>

<sect1> Related HOWTOs <label id="related_howtos">
<p> Go to the nearest mirror site (per above) to get HOWTOs.
<itemize>
<item> Serial-HOWTO has info on Multiport Serial Cards used for both
terminals and banks of modems.  It has general technical info on the
serial port including troubleshooting it.
<item> NCURSES-Programming-HOWTO
<item> MacTerminal mini-HOWTO
<item> Modem-HOWTO
<item> Serial-Programming-HOWTO
<item> NC mini-HOWTO
<item> NCD-X-Terminal mini-HOWTO
<item> XDM-and-X-Terminal mini-HOWTO
<item> Connecting-X-Terminals-to-Linux-Mini-HOWTO
<item> NCD-HOWTO
<item> Thinclient-HOWTO
<item> Xterminals-HOWTO 
<item> Xterm-Title-HOWTO (only for changing the title of a window)
</itemize>

<sect1> Terminology Used in this Document
<p> Configuration means the same as set-up.  While Linux commands take
options (using - or -- symbols), options in a broader sense include
various other types of choices.  Install in the broad sense includes
setting up (configuring) software and hardware.  A statement that I
suspect is true (but may not be) ends with 2 question marks: ??  If
you know for sure, let me know.

<sect1> What is a Terminal ?
<p> A terminal consists of a screen and keyboard that one uses to
communicate remotely with a computer (the host).  One uses it almost
like it was a personal computer but the terminal is remote from its
host computer that it communicates with (on the other side of the room
or even on the other side of the world).  Programs execute on the host
computer but the results display on the terminal screen.  Originally
terminals were stand-alone devices with no computational ability and
thus they were once much cheaper in cost than computers.  They had no
pictures or audio, but could only display text and were thus called
"text terminals".  Today, the cost of PC computers is so low that one
may use a PC like a text terminal by running a software program to
make it behave like an old text terminal.  You formerly found real
text terminals at libraries and schools.

<sect1>Real Text Terminals
<p> In the olden days of mainframes, from the mid 1970's to the mid
1980's, most communication with large computers was done by people
sitting in front of real text-terminals.  And in the 1970's, before
the advent of personal computers, it was the only way to interactively
communicate with any computer.  These real text-terminals were neither
computers nor emulated text-terminals.  They consisted only of a
screen, keyboard, and only enough memory to store a screenfull or so
of text (a few kilobytes).  Users typed in programs, ran programs,
wrote documents, issued printing commands, etc.  A cable connected the
terminal to the computer (often indirectly).  It was called a terminal
since it was located at the terminal end of this cable.  Some
text-terminals were called "graphic" but the resolution was poor, the
speed slow, and little software was available to support such
graphics.

Today, real terminals are becoming rarities for most all computer
users.  But there is still some specialized uses for them as
point-of-sale devices and for access to mainframes and servers where
graphics and pictures are not needed.  However, if a text terminal is
needed people will sometimes use a personal computer to emulate a
terminal.

Almost everyone who uses Linux also uses terminal emulation.  When you are
not using an X Window GUI at a Linux PC, you are likely using a text
interface (virtual terminal).  It's also called a "command line
interface".  In X Window one can also get a command line interface
using one or more terminal windows by using an x-terminal-emulator
with names such as xterm, gnome-terminal, or konsole (KDE).  All these
use software to emulate a real terminal.  However in these cases, one
doesn't need most of the information provided by this HOWTO since such
emulation is automatically set up for the user.  However if one
emulates a terminal using a software program and then connects that
emulated terminal to another computer via a serial port cable, then
this HOWTO should be more useful (provided your PC has a serial port
on it --almost all recent PCs made after 2009 didn't have them anymore).

A real text-terminal is different from a monitor or
x-terminal-emulator because the simple character images that get
displayed on the text-terminal are stored right inside the terminal in
it's memory.  For a monitor or x-terminal-emulator, the images  are
stored in the video card of the PC and/or in the PC's memory itself.
The text-terminal's keyboard plugs into the terminal and is part
of the terminal while a PC's keyboard plugs into the computer.

For a monitor, the video images are sent by a short cable running from
the video card to the monitor while for a text-terminal there is a
bi-directional flow of character bytes in a long cable between the
computer's serial port and the PC it's connected to.  Most text
terminals do not have mice.

In network client-server terminology, one might think that a real
terminal is the client and that the host computer is the server.  The
terminal has been called a "thin client" by some.  But it is not
actually a "client" nor is the host a "server".  The only "service"
the host provides is to receive every letter typed at the keyboard and
react to this just like a computer would if you typed at its own
keyboard.  The terminal is like a "window" into the computer just like
a monitor (and keyboard) are.  You may have already used virtual
terminals in Linux (by pressing Left Alt-F2, etc.).  A real terminal
is just like running such a virtual terminal but you run it on its own
terminal screen instead of having to share the monitor screen.  In
contrast to using a virtual terminal at the console (monitor), this
allows another person to sit at another real terminal and use the same
computer simultaneously with others.  Such multi-user interfaces are
not "clients" and a server..

<sect> Types of Terminals

<sect1> Dumb Terminals

<p> There are various conflicting definitions of "dumb terminal" but
as time goes by, more and more terminals are called dumb.  This
document mainly covers text terminals which display only text on the
screen.  It could have been titled "Dumb-Terminal-HOWTO".   But in
some magazines articles, any terminal, no matter how smart, including
ones which present a full graphical user interface (GUI), are called
dumb.  If all terminals are "dumb" then there is no point of prefixing
the word "dumb" to terminal (except as a sales pitch to sell computers
or the like instead of terminals).  Due to the ambiguous meaning of
"dumb terminal" it is not classified here as a type of terminal.

<sect1> Text Terminals

<p> For a text terminal, a 2-way flow of information between the
computer and the terminal takes place over the cable that connects
them together.  This flow is in bytes (such as ASCII) where each byte
is an integer that usually represents a printable character.  Bytes
typed at the keyboard go to the host computer and most bytes from the
computer are displayed on the terminal screen.  Special control bytes
(or sequences of bytes) from the computer tell the terminal where to
move the cursor to, what to erase, where to begin and end underlining
and/or blinking and/or bold, etc.  There are often hundreds of such
special coded commands and most real terminals can even change fonts.

The communication uses characters (letters) encoded using a code chart
for the character set being used.  Usually, the first 128 bytes out of
256 possible bytes use ASCII codes.  Terminals for Unix-like systems,
normally connect to computers via a cable running between the
asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer
and the terminal.  Prior to about 2004, most new PCs had serial ports,
but today (2009) almost no new PCs come with serial ports.  Sometimes
the connection is via modem or terminal server, etc.

Other names for "text terminal" are "general purpose terminal",
"general display terminal", "serial monitor", "serial console" (if
it's used like a console), "serial terminal", "dumb terminal",
"character-cell terminal", "character terminal", "ASCII/ANSI
terminal", "asynchronous terminal", "data terminal", "video terminal",
"video display terminal" (VDT), and "green terminal" (since many used
green displays).  These names (especially "dumb terminal") are
sometimes used to mean emulating a text terminal on a PC with a
command line interface such as Linux.  In olden days "video display
unit" (VDU) meant text terminal but strictly speaking, it excludes the
keyboard.

"Block mode" was used exclusively by old IBM mainframe terminals but
many modern terminals also have this capability (which is not used
much).  In block mode, the characters you type are temporarily
retained in the terminal memory (and may possibly be edited by a
built-in editor at the terminal).  Then when one presses the send key
(or the like) a block of characters (sometimes just a line of
characters) is sent to the computer all at once.  Block mode (as of
late 1998) is not supported by Linux.  See section <ref id="block"
name="Block Mode">.

<sect1> Graphic GUI Capabilities of Text Terminals 
<p> While emulated text terminals don't display images, many real text
terminals can display bit-mapped images, but not in color.
Unfortunately, the popular image formats used on the Internet are not
supported.  Thus the display of images is seldom used.  The protocols
for terminal graphics include: Tektronix Vector Graphics, ReGIS (DEC),
Sixel (DEC), and NAPLPS (North American Presentation Level Protocol
Syntax).

Even without bit-mapped images, ordinary text terminals can sort of
display images.  One may form  arrows <--- and draw boxes with |__|,
etc.  With special graphic character sets that have a lot of special
characters for line drawing, much more is possible.  But even without
a graphic character set, one may produce "ascii graphics" art.  The
term "graphics terminal" usually means a terminal that can display bit
mapped images.  However, this term is sometimes applied also to
text-only terminals since text is a limited form of graphics.

<sect2> Graphics GUI displays <label id="vector_graphics"> 
<p> There are two basic types of graphics displays: raster and vector
(rarely used).  Raster graphics (bit-mapped) puts dots on the screen
by horizontal scan lines drawn by an electron beam (or by activating
pixels or dots on a flat screen).  Vector graphic displays were
intended to be used for monochrome screens that don't have any dots.
They use smart electronics to draw lines and curves with an electron
beam that can continuously move in any direction (just like a pen or
pencil).  True vector graphics draws high quality lines without
noticeable zig-zags but is both rare and expensive.  For more details
see <url url="http://www.cca.org/vector/">.  Raster graphics is almost
universally used today for both PCs and text terminals.  For PCs,
images encoded in vector graphic format can't be drawn as continuous
lines due to the electronic limitations but they can be translated to
raster graphics format for display (with a resulting drop in image
quality).

<sect>  Thin Clients Terminals 

<sect1> Introduction 
<p> Since "thin clients" are not text terminals, this HOWTO only
provides a brief overview of them.  There are other HOWTOs that cover
them in more detail but (as of 2010) they are unfortunately not up to
date. See <ref id="related_howtos" name="Related HOWTOs, etc.">.  Thin
clients are thin (minimal) client computers that behave something like
terminals.  Since text terminals (except for very old ones) run an
embedded operating system, they are also like a computer.  In contrast
to text-terminals, thin clients all display a modern high-speed GUI.
They are dependent on more powerful computers (servers) for their
operation.  

For a true thin client terminal, the computing work and
disk storage will all be done on the server.  At the other extreme,
most of this work and storage is done at the thin client but some
things such as administration, still depend on the server.  Since such
a client is not really "thin" it may more correctly be called a "fat
client".

Instead of "thin client" they could have been simply called "graphic
terminals" but promoters of this technology wanted a catchy name to
get customers to believe that it was perhaps a totally different
technology.  This trend of renaming what is basically just graphic
terminals (with new features) continues unabated.  Some of these names
are "Virtual Desktop" and "Cloud Computing".

Thin clients may be created from an ordinary PC by using software or
may be a stand-alone piece of hardware.  But such stand-alone hardware
may often be just a conventional PC monitor plus a small box for the
computer part of the hardware.  Linux seems to favor the use of PCs as
clients.

Some claim that text-terminals are also a type of thin client but they
are not really since they don't conform to the client-server model.
However, connecting a terminal via telnet does invoke the
client-server model in the use of telnet as a means of transport of
data.  But the relation of the text-terminal to it's host is not one
of client-server.  The text-terminal is just another means of access
to the computer just like the monitor and its keyboard is to access a
PC.  One could apply this same reasoning to a thin client and say that
the client-server relationship is only for the transport of data.

Thus a thin client is like a terminal.  It has a GUI with a mouse that
makes it seem like you are using a computer.  You are, but that
computer may be far away and have many other people using it at the
same time you are.  Communication is over a high speed network
(wireless and/or cable) or even over the Internet.  Some thin clients
can, in addition, emulate a text terminal and have a serial port
connector for that purpose.  Recent ones also have USB interfaces as
well as ethernet.

There are various types of thin clients.  One type is the "Window
Terminal" which runs under MS servers (and software).  Another type is
the "network computer" which is supposed to be platform neutral.  This
implies they should work with both MS Windows and Linux but early
models may not be easy to use with Linux.  For Linux, the X Window
protocol is used.  See <ref id="linux_thin_clients" name="Thin clients
and NCs under Linux">

<sect1> MS Window terminals
<p>These are true terminals since all the computing work is done by a
server running Windows.  They are also called "Window-based Terminals"
(WBT).  These terminals (clients) are something like computers since
they often run an embedded operating system such as Linux or
Microsoft's CE, NT, or XP.  It's often stored in flash memory so that
it may be updated.   Also, ordinary PCs can be used as clients
(including, in some cases, Linux PCs) with the appropriate software,
Some clients can support X Window (from a Linux server) and some can
emulate text-terminals.  Many so called "network computers" can also
run X Window.  This will be discussed in the next section.

The server for these clients usually runs MS's Terminal Services (for
Windows 2000 servers).  Prior to this there was Windows NT Terminal
Server Edition (starting mid 1998 with codename "Hydra").  MS uses RDP
(Remote Desktop Protocol) which is based on the ITU T.120 protocol.
In addition, there is an optional ICA protocol (with added features)
which can inter-operate with RDP.

Prior to this there was a modified Windows NT 3.51 (1995) called
"WinFrame" by Citrix using the proprietary ICA protocol (Independent
Computing Architecture).  After MS came out with its own terminal
server, Citrix still remained on the scene.  It created MetaFrame
software (formerly pICAsso) as an add-on to MS's Terminal Server (or
Services) so that it could support ICA-based terminals and provide
other additional features.  Before MS got into the act, there were
other proprietary systems for terminals that could display the MS
Windows GUI but later on they all switched to support Microsoft's
system.

PCs running Linux can be turned into ICA based client terminals using
"free" (in price only) proprietary ICA client software from Citrix:
<url url= "http://support.citrix.com/article/CTX879408" name="Installing
the Linux Client">.  Unfortunately, MS requires that you purchase a
license to cover the clients, even if the clients all run Linux.  So
if you want to save money on software costs by using Linux, you'll
have to go all-Linux and use both Linux servers and clients using the
free X-Window protocol.

The above is sometimes called "network computing" since the terminals
and servers connect to each other over a network (such as the common
TCP/IP based network used by both Linux and MS).  Network computers
may be somewhat different as described below.

<sect1> Network computers (NC's) 
<p>See <url url="http://en.wikipedia.org/wiki/Network_Computer"
name="Network Computer - Wikipedia"> which claims that NC's are
defunct as a type of hardware, but that NC is used as a synonym for
"thin client".

These are neither true computers nor true terminals but are
something in-between.  One type of network computer (NC's) is a
computer with a CPU but no hard Disk.  The OS it needs to run is sent
to it over a network.  NCs are full-graphics and use the services of a
server computer.  They are a little different from terminals since
some (or most) of the programs they run may execute on their own CPU
chip.  Running a browser was supposed to be one of their primary
functions and thus Java code applets may be sent to them for
execution.  Many NCs support X Window so that one may use a Linux
server to support it.  Such a server may be called a "Linux Terminal
Server".  IBM called their NC a "NetStation" but now calls it
"NetVista".  They should work on Intranet type networks and NetVista
can run the Linux OS.

Wintel came out with a "NetPC" which, unlike the above, is almost a PC
computer.  However, it has no removable disks so users can't install
their own software or obtain copies of anything.

<sect1> Thin clients and NCs under Linux <label id="linux_thin_clients">

<p> There is a "Linux Terminal Server Project" (LTSP or ltsp) to use
Linux as a server for diskless thin clients.  They use X Window and by
default, applications run on the server.  But with additional effort,
one can set it up so that some or all applications run on the
"terminal".  See <url url="http://www.ltsp.org/">.  

"Terminal" in LTSP is actually a thin (or fat) client.  This project's
client can also run a telnet session and thus behave like a
text-terminal.  A software package named "lts" for the LTSP is
available in the major Linux distributions.

It's claimed that if one has only a few "terminals", they will work
without the ltsp software.  But if one has many "terminals", ltsp
software is needed.  So use ltsp if what you want to do is to use old
PCs, etc. as diskless thin clients.  It works OK on systems with over
100 thin-client workstations.

Linux provides NFS (Network File System) so that if ordinary computers
are connected to each other via a network, then a person on one
computer can run programs on another computer.  Such a program sends
messages over the network so that it appears just like a program was
being run by your local computer.   But such a program is actually
being run on another computer on the network.  It works also with X
Window so that one may see GUI images generated on another computer.

Linux also allows a computer to be diskless and boot over a network.
See the "Terminal Server Project" above which has special software for
this purpose.  Network-boot-HOWTO gives an overview.  Older documents
are Diskless-HOWTO and Diskless-root-NFS-HOWTO.  Thus using a diskless
computer which runs NFS enables you to run programs on another
computer (the server).  This is just like using a NC (Network
Computer).  It's not really a NC but it's emulating a type of NC.
It's also often called a "terminal" and in some sense it is.

Thus if you have an old PC with an ethernet card (NIC) you may be able
to use it as a NC.  One source of info on this is Thinclient-HOWTO.
Even if your old PC doesn't have a NIC, you could still use it to
emulate a text-terminal.  See <ref id="term_emulation" name="Terminal
Emulation">.

There are also a number of genuine Network Computers (NC) that will
work with a Linux server.  Today some NCs run the Linux OS inside the
NC.  Before Linux became popular, NCs didn't run the Linux OS but
required some other OS.  But even if the NC uses a non-linux OS, it's
often possible to make it work with a Linux Server.  The non-linux OS
is simply stored as files on the Linux Server.  Then when the NC
starts up it sends a message to the Linux Server asking for the
non-linux OS files.  This non-linux OS is thus sent to the NC over the
network and the NC boots.

The Linux Server runs the NFS and X Window both of which must be
supported by the NC.  This enables one to use the NC as if it were an
X Window terminal.

There are some Linux HOWTOs for certain brands of NCs:

<itemize>
<item> JavaStation-HOWTO (by Sun) 
<item> NC-HOWTO (IBM NetStation)
<item> NCD HOWTO (NCD-ThinSTAR)
<item> NCD-X-Terminal HOWTO 
<item> XDM-and-X-Terminal HOWTO
</itemize>

<sect1> Hardware hookups 
<p> There are 3 different types of hardware arrangements for thin
clients.  The first type just uses a PC computer as a thin client by
emulating a thin client.  It really isn't a thin client but it behaves
like one.  The second type (no longer made ?) looks just like a
text-terminal.  It just looks like a monitor, with a connector for a
keyboard and another connector for a network cable.  It's a dedicated
thin client and can't be used for anything else.  The third type looks
like a tiny computer.  It uses a standard PC monitor and keyboard both
of which plug into a small box which is a "thin" computer.  This box
provides an interface between the monitor/keyboard and the network.

<sect1> History and the future
<p> Promoters of NCs and related Window-Terminals projected that they
would soon replace millions of PCs.  In 1998 about .7 million thin
clients were sold worldwide with (about 27% of them being NCs).  In
1999 it dropped to .6 million but went up to .9 million in 2000 (vs.
1.3 million predicted).  In 2001 it reached 1.09 million with 1.4
million predicted for 2002.

Microsoft servers (as of 2003) still dominate the market, but the
clients may run Linux for which users still have to pay license fee
for each Linux client to Microsoft.  Thus free all-linux systems are
gaining ground.

A major reason why growth was not as rapid as predicted is that PCs
have come down in price in recent years so that they are often not
much more expensive than a thin client.  However, it's argued that
even though thin clients may cost the same as PCs, the maintenance and
administration costs are less.  Note that thin clients sometimes
replace text terminals instead of PCs.

<sect> Quick Text-Terminal Install <label id="quick_install">

<p> This is a quick procedure to install a terminal without going
through a <ref id="setup_" name="Setup"> procedure for both the
terminal and the host computer.  It probably will not work right if
the terminal happens to have been set up incompatible with the
computer.  If you don't understand some of it you'll need to consult
other parts of this document for more info.

To install a terminal, first look in <tt>/etc/termcap</tt> or
<tt>terminfo.src</tt> to find an entry for it (see <ref id="termcap2"
name="Terminfo and Termcap (detailed)">).  Figure out what serial port
you'll connect it to and what the tty designation is for that port
e.g. ttyS1, see <ref id="dev_names" name="Device Names">).  As the
root user, edit <tt>/etc/inittab</tt> and add a getty command next to
the other getty commands.  The format of the getty command depends on
which getty program you use.  <tt/agetty/ (called just <tt/getty/ in
the Debian distribution) is the easiest (no configuration file).  See
the "<tt/info/" or "<tt/man/ re <tt/getty/.  For getty parameters use
the terminfo (or termcap) name (such as vt100) for your terminal.
Type in a baud-rate that the terminal supports.  But if you set the
baud too high you may need to use (See<ref id="flow_control"
name="Flow Control">).

Then physically connect the main serial port of the terminal to the
chosen serial port of the computer with a file-transfer (null modem)
cable and turn on the terminal.  Don't expect most ready-made cables
to be wired correctly for hardware flow control.  Make sure the
baud-rate of the terminal is set the same as you gave to getty and
that its "data bits" is 8.  Then at the computer console type "init q"
to apply the changes you made to the inittab file.  You should now see
a login prompt at the terminal.  If you don't, tap the terminal's
return key.  If this doesn't work read more of this document and/or
see <ref id="trouble_shoot" name="Trouble-Shooting">.

<sect>Why Use a Terminal ?

<sect1> Intro to Why Use a Terminal 
<p>Many of these arguments apply also to GUI "thin-client" type of
terminal.  The case for such terminals is frequently being made today
and promoters are devising new slogans and names in an attempt to
market the modern terminal concept under another name.  For example "Cloud Computing".	

PC's are so powerful today that just one PC can often support
several persons using it at once, especially if they are doing
low-load tasks such as text editing, data entry, etc.  One way to do
this is to connect a number of terminals to a single PC (or other host
computer) by modems or direct cable connection.  To do this, it's
usually best to have a multi-user operating system such as Linux so
that each user at a terminal can use the computer independently.  This
has been called "time sharing" but it's not good terminology today
since "distributed" computing over a network is also a type of time
sharing.  It might be better described as "centralized" computing.
But the central computer may be connected to the rest of the world via
a network so that terminal users may send email, browse the Internet,
etc.  So it's not exactly "centralized" either.

Prior to about 2000, terminals were seldom used with PC's because the
popular operating systems used for them (Windows, DOS, and Mac) were
not multiuser until 1998 (available for MS Windows NT) and previously
could not support terminals very well.  Now that Linux, a multiuser
operating system, is freely available for PC's, the use of terminals
with PC's becomes more feasible.  While text terminals are not smart
enough to support the type of graphical user interface (GUI) that most
computer users today expect, thin client type terminals are.

<sect1> Lower Hardware Costs ?  
<p> When Computers (including PCs) were quite expensive, lower
hardware costs was a significant advantage of using terminals.  Today
with cheap PCs, the cost savings is problematical.  I wrote the next
three paragraphs years ago when PCs were more expensive.  They are still
valid today but of less significance:

If several people use the same computer as the same time, there is a
reduction in the amount of hardware needed for the same level of
service.  One type of savings is due to code sharing.  The application
files on hard disks are shared as well as shared libraries in memory
(even when people are running different programs provided they use
some of the same functions in their code).  Another type of savings is
due to reduction of peak load.  The hardware of a single PC may be
idle most of the time as people slowly type in information, think,
talk, or are away from their desks.  Having several people on the same
computer at once makes good use of much of this idle time which would
otherwise be wasted.

These savings are substantial.  One may roughly estimate (using
statistical theory) that for 9 persons (8 terminals & 1 console) the
shared PC only needs only about 3 times as much capacity (in memory,
disk storage, CPU power, etc.) as a single PC in order to provide the
same level of service per person.  Thus the computational hardware for
such a shared system should only cost about 1/3 as much per user.
However, the cost of the display hardware (CRT's, keyboards, video
electronics, etc.) is about the same for both cases.  The terminals
have the added cost of requiring additional physical cable connectors
(such as serial ports) at the host computer.

For a fair comparison with PC's, the terminals should have the same
capabilities as the PC monitors.  Unfortunately, color graphic
terminals for Linux (X Window) with high speed communication cost
about as much as a PC so in this case there not much (if any) savings
in hardware costs.  But for text terminals there will be some savings,
especially if the terminals are obtained used at low cost.

<sect1> Control of Software 
<p> For centralized computing, software (and the updates to software)
only need be installed and configured on one host computer instead of
several.  The person in charge of this computer may control and
configure the software which is installed on it.  This is advantageous
if the person controlling the host computer does an excellent job and
knows about the needs and preferences of the other users.  Users can
be restricted in playing games or surfing the Internet, etc.
Whether or not centralized control is desirable depends on the
situation.  It's in a sense depriving users of their "right" to
controls what they do with their computer including things that would
improve their efficiency at work and/or entertain them.

<sect1> Hardware Upgrades 
<p> With terminals, the computer hardware
upgrades take place on only one computer instead of many.  This saves
installation labor effort.  While the cost of the hardware for the
host computer upgrade will be more than that for a single PC (since
the host needs more computing power than a PC), the cost will be
significantly less than upgrading the hardware of a number of PC's
being used instead of terminals.

<sect1> Other Advantages of Terminals 
<p> <itemize>
<item> The elimination of noise from fans and disk drives (unless
you're using a PC to emulate a terminal).
<item> The users of the terminals can share data and files and send
e-mail to each other.  But they could also do this if the used PC on a
local network or via email over the internet.

</itemize>

<sect1> Major Disadvantages of Text Terminals 
<p><itemize>
<item>  For the case of text terminals there is no high-speed graphic
  display (or high resolution graphics) although they can often use
  graphic character sets to draw boxes, etc.  This lack limits the
  software that may be used on it.
<item> A detailed display of progress will sometimes greatly increase
  the time taken to do the job. For example, when copying a large
  number of files and displaying the name of each, the terminal may
  only be able to display the full path names of say 30 files per
  second so only 30 files per second will be copied.  But the computer
  hardware is capable of copying at a rate many times higher.  This
  can often be fixed by using options of application programs for a
  minimal display of progress.  See <ref id="slow_scroll"
  name="Problem with Slow Scrolling">
<item>Most new computers don't have serial ports anymore, making it
  difficult to use them to emulate text terminals that connect over a
  serial line.  One could perhaps connect by dialup using an analog
  modem, but with high speed cable or DSL modems, the analog modem is
  becoming obsolete.
</itemize>

<sect1> Major Disadvantages of All Terminals 
<p><itemize>
<item> If the host computer goes down, then no one can use the
  terminals either (unless there is a "standby" host computer to connect
  to).
<item>As compared to a laptop, it's not portable.  That is, you can't
easily take it around with you, unless you have some way of connecting
to your host computer where ever you go.
</itemize>

<sect1> Are Text Terminals Obsolete ?  
<p> Text terminals are technologically obsolete because for a slightly
higher cost of hardware, one can build a smarter terminal (with the
same quality of display).  This wasn't always the case since around
1980 memory cost thousands of dollars per megabyte.  Today with low
costs for memory and processors, one could turn a text terminal into a
GUI graphic terminal for only about a 10% or 20% increase in hardware
cost.

Since a PC can emulate a terminal, almost everyone using computers had
a terminal emulator available until PCs started removing the serial
port from new models during the 2000-2010 decade.  You might think
that now text terminals would be more in demand since emulating a
directly connected terminal is only feasible with newer PC's (with no
serial ports)  only if one purchases such ports.  But if one wants to
connect text terminals (including  emulated ones) to a PC via the
serial port they will be out of luck if the Linux PC doesn't have a
serial port.  Thus the disappearing serial port tends to make the text
terminal even more obsolete.

The reasons that text terminals are (or were) not fully obsolete are: 
<itemize>
<item> The resolution of characters on the screen was better on
 monochrome terminals than for cheaper PC monitors in text mode.
 But for high resolution monitors the character resolution is fine.
<item> Some people don't need full screen graphics.
<item> Since running a text-terminal (in contrast to a GUI-graphics
terminal) doesn't consume much of a modern PC's resources, a large
number of terminals may be efficiently run from one PC.
</itemize>

<sect> Overview of How Text Terminals Work (in Linux) <label id="overview">

<p>  See also section <ref id="HowTermsWorkDetail" name="Some Details
on How Terminals Work">

<sect1> Device Names  <label id="dev_names"> 
<p> Each terminal is connected to a serial port on the host computer
(often just a PC).  The ports have names/numbers.  The first few are:
ttyS0, ttyS1, ttyS2, etc.  

These are represented by special files found in the /dev (device)
directory.  ttyS0) corresponds to COM1 in DOS or Windows.  ttyS1) is
COM2, etc.  See <ref id="devices_" name="Terminal Special Files"> for
details on these and related "devices". 

<sect1> Login/Logout 
<p> When the host computer starts up it runs the program getty.  The
getty program runs the "login" program to log people in.  See <ref
id="getty_" name="Getty (used in /etc/inittab)">.  A "login:" prompt
appears on the screen.  People at the terminals and/or console log in
(after giving their passwords) and then have access to the computer.
When it's time to shut the terminal down, everyone must log off and
(and power off their terminal).  See <ref id="login_restr" name="Login
Restrictions"> regarding restricting logins (including allowing the
root user to log in at terminal).

<sect1> Half/Full Duplex <label id="half_duplex"> 
<p>  If one watches someone typing at a terminal, the letters one
types simultaneously appear on the screen.  A naive person might think
that what one types is being sent directly from the keyboard to the
screen with a copy going to the computer (half-duplex like, see next
paragraph).  What is usually going on is that what is typed at the
keyboard is directly sent only to the host computer which in turn
echoes back to the terminal each character it receives (called
full-duplex).  In some cases (such as passwords or terse editor
commands) the typed letters are intentionally not echoed back.

Full-duplex means that there are two (dual) one-way communication
links.  Full-duplex is the norm for terminals.  Half-duplex is half of
a duplex, meaning that there is only a single one-way communication
link.  This link must be shared by communications going in both
directions and only one direction may be used at a time.  In this case
the computer would not be able to echo the characters you type (and
send to it) so the terminal would need to also send each character you
type directly to the terminal screen.  Some terminals have a
half-duplex mode of operation which is seldom used.

<sect1> Terminal Memory 
<p> The image on a CRT tube will fade away almost instantly unless it
is frequently redrawn on the screen by a beam of electrons shot onto
the face of the tube.  Since text sent to a terminal needs to stay on
the screen, the image on the screen must be stored in the memory chips
of the terminal and the electron beam must repeatedly scan the screen
(say 60 times per second) to maintain the image.  See <ref
id="term_mem_detail" name="Terminal Memory Details"> for more details.

<sect1> Commands for the Terminal 
<p> The terminal is under the
control of the computer.  The computer not only sends the terminal
text to display on the screen but also sends the terminal commands
which are acted on.  These are <ref id="control_codes" name="Control
Codes"> (bytes) and <ref id="esc_seq" name="escape sequences">.  For
example, the CR (carriage return) control code moves the cursor to the
left hand edge of the screen.  A certain escape sequence (several
bytes where the first byte is the "escape" control code) can move the
cursor to the location on the screen specified by parameters placed
inside the escape sequence.

The <ref id="early_terms" name="first terminals"> had only a few such
commands but modern terminals have hundreds of them.  The appearance
of the display may be changed for certain regions: such as bright,
dim, underline, blink, and reverse video.   A speaker in a terminal
can "click" when any key is pressed or beep if a mistake has occurred.
Function keys may be programmed for special meanings.  Various fonts
may exist.  The display may be scrolled up or down.  Specified parts
of the screen may be erased.  Various types of flow control may be
used to stop the flow of data when bytes are being sent to the
terminal faster than the terminal can handle them.  There are many
more as you will see from looking over an advanced terminal manual or
from the Internet links <ref id="esc_seq_lists" name="Esc Sequence
List">

<sect1> Lack of Standardization Solved by Terminfo 
<p> While terminals
made for the US all used the same ASCII code for the alphabet (except
for IBM terminals which used EBCDIC), they unfortunately did not all
use the same escape sequences.  This happened even after various ANSI
(and ISO) standards were established since these standards were never
quite advanced enough.  Furthermore, older terminals often lacked the
capabilities of newer terminals.  This might cause problems.  For
example, the computer might send a terminal an escape sequence telling
it to split the screen up into two windows of specified size, not
realizing that the terminal was incapable of doing this.

To overcome these problems a database called "termcap" (meaning
"terminal capabilities") was established.  Termcap was later
superceded by "terminfo".  This database resides in certain files on
the computer and has a section of it (sometimes a separate file) for
each model of terminal.  For each model (such as VT100) a list of
capabilities is provided including a list of certain escape sequences
available.  For example blink=\E5m means that to make the cursor start
blinking the terminal must be sent: Escape 5 m.  See Section <ref
id="termcap2" name="Termcap and Terminfo (detailed)" > for more
details.  Application programs may utilize this database by calling
certain C-Library functions.  One large set of such programs (over
200) is named "ncurses" and are listed in the manual page for
"ncurses" which comes with a developer's ncurses package.  There is
also a NCURSES-programming-HOWTO.

<sect1> The Interface 
<p> The environment variable TERM is the type of
terminal Linux thinks you are using.  Most application programs use
this to look up the capabilities in the terminfo database so TERM
needs to be set correctly.   But there is more to a correct interface
than the computer knowing about the capabilities of the terminal.

For bytes to flow from the computer to the terminal the terminal must
be set to receive the bytes at the same baud rate (bits per second) as
they are sent out from the terminal.  If the terminal is set to
receive at 19,200 baud and the computer sends out characters at 9600
baud, only garbage (or perhaps nothing) will be seen on the screen.
One selects the baud rate for a terminal (as well as many other
features) from the terminals "set-up" menus at the terminal.  Most
terminals have a large number of options in their "set-up" menus  (see
<ref id="term_conf_details" name="Terminal Set-Up (Configure)
Details">).  The computer serial port has options also and these
options must be set up in a compatible way (see <ref
id="comp_conf_details" name="Computer Set-Up (Configure) Details">.

<sect1> Emulation

<p> Most terminals today have more than one emulation (personality or
"terminal mode").  The terminal model numbers of terminals formerly
made by DEC (Digital Equipment Corporation now Compaq) start with VT
(e.g. VT100).  Many other terminals which are not VT100 may be set up
to emulate a VT100.  Wyse was a major terminal manufacturer until
about 2005.  Most of their terminals can emulate various DEC terminals
such at VT100 and VT220.  Thus if you want to, say, use a VT320
terminal you may either use a real VT320 in "native" personality or
possibly use some other terminal capable of emulating a VT320.

The "native" personalities usually have more capabilities so, other
things being equal, "native" is usually the best to use.  But other
things may not be equal.  Since the Linux console emulates a VT102 it
you may want to have a terminal emulate this (or something close to it
such as VT100).  This will help insure that some programs that may not
handle terminals properly will still work OK on your terminal.  Some
programs will assume that you are using a VT102 if the program can't
find a terminfo for your terminal (or can't find a certain
capability).  Thus the failure of a program to work correctly with
your non-vt102 terminal may well be your fault if you don't provide a
good terminfo file for your terminal.  Using "native" and then
reporting any bugs will help discover and fix bugs which might not
otherwise get detected.

The most common type of emulation is to use a PC like it was a vt100
terminal (or the like).  Programs loaded into the PC's memory do the
emulation.  In Linux (unless you're in X Window) the PC monitor
(called the console) emulates a terminal of type "Linux" (close to
vt100).  Even certain windows within X Window emulate terminals.  See
<ref id="term_emulation" name="Terminal Emulation">.

<sect1> The Console

<p> On a PC, the monitor is normally the console.  It emulates a
terminal of type "Linux".  One logs on to it as a virtual terminal.
See <ref id="console_dev" name="The Console">.  It receives messages
from the kernel regarding booting and shutdown progress.  One may have
the messages that normally go to the console, go to the terminal.  To
get this you must manually patch the kernel, except that for kernel
2.2 (or higher) it is a "make config" option.  See <ref
id="term_as_console" name="Make a Serial Terminal the Console">.

<sect> Terminal Special Files such as /dev/tty <label id="devices_">

<p> "tty" is an abbreviation for "Teletype".  The first terminals were
Teletypes (like remotely controlled typewriters).  See subsection <ref
id="teletype" name="Teletypes">.  A list of Linux devices (the stuff
in the /dev directory) may be found in "Linux Allocated Devices" which
should be included with kernel sources.  It "describes" what each
device used for in only a word or two but doesn't tell you how to use
them.

<sect1> Serial Port Terminals 
<p> The computer considers each serial
port to be a "device".  It's sometimes called a terminal device since
at one time terminals were the most common use for a serial port.  For
each such serial port there is a special file in the /dev (device)
directory.  /dev/ttyS0) is the special file for the serial port known
as COM1 in the DOS/Windows world. 

To send text to a terminal you may redirect standard output of some
command-line command to the appropriate special file.  For example
typing "echo test > /dev/ttyS1" at the command prompt should send the
word "test" to the terminal on ttyS1 (COM2) provided you have write
permission on /dev/ttyS1.  Similarly, typing "cat my_file >
/dev/ttyS0" will send the contents of the file my_file to COM1
(ttyS0).

<sect1>Pseudo Terminals

<p> Pseudo terminals are pairs of devices such as  /dev/ptyp3 and
/dev/ttyp3.  There is no physical device directly associated with
either of them, not even a serial port connector.   But if a program
treats ttyp3 like it was a serial port, what is read and written to
that port appears on the other member of the pair ptyp3 which another
program uses to read and write to.  Thus two programs talk to each
other via this method and one program on ttyp3 thinks it's talking to
a serial port.  It's something like a "pipe" between these two tty's.

For talking to ttyp3, any program designed to talk to a serial port
will do.  But for the other program that talks to ptyp3, it must have
been specially written to talk to it.  It's mainly programmers that
must concern themselves with pseudo terminals and most users don't
need to worry about them.

Here's an example:  If someone connects via telnet to your computer
over a network (you are a telnet server), the part of the telnet
program handling this connection on your computer may wind up
connected to the pseudo terminal ptyp2.  A getty program should be
running on the corresponding ttyp2.  Getty thinks it's talking to a
terminal.  When telnet gets a character from the remote client, it
goes thru ptyp2 to ttyp2 to getty which then sends back "login:"
routed via ttyp2, ptyp2, your server telnet program, and then out to
the network back to the client.  Here the login program and the telnet
server program talk to each other via a "pseudo terminal".  Note that
there is no pseudo terminal used on the client computer, just telnet.
Of course the server allocates a pseudo terminal (on the server) for
each client.

In X Window, the terminal emulator programs (such as xterm) use pseudo
terminals.  Ham radio programs under Linux also use them.  By using
certain application software, it is possible to have 2 or more pseudo
terminals attached to the same physical serial port.

For a pseudo terminal pair such as ptyp3 and ttyp3, the pty... is the
master or controlling terminal and the tty...  is the slave.

There are only 16 ttyp's: ttyp0-ttypf (f is a hexadecimal digit).  To
get more pairs, more letters such as q, r, s are used instead of p.
For example the pair ttys8, ptys8 is a pseudo terminal pair.  Later
on, even more letters were added so as to allow even more pseudo
terminals.  And when z was reached, they wrapped around to a.  This is
confusing but old habits are difficult to change.  Today Linux allow
say ttyp189 but it's not used.  The device file system, which was
abandoned in 2004, would have used tty/s189.  Be sure not to type say
ttys2 if you mean ttyS2 (a real serial port).

The master and slave are really the same "port" but the slave is used
by the application program and the master is used by a network program
(or the like) which supplies (and gets) data to/from the slave port.
The program using the slave port can run "as is" since it thinks it is
talking to a serial port.

Unix98 pseudo terminals (available on Linux) is more advanced than the
above but the basic concepts are the same (only the device names and
methods of creating them change).  It creates pseudo terminal devices
on request so there is no need to check if the pseudo terminal you
might want to use in in use.  By opening /dev/ptmx a new pseudo
terminal pair is created.  The master doesn't show up as a device but
is just a file descriptor number passed to the computer program that
opened /dev/ptmx.  But the slave is put into the /dev/pts directory:
for example" /dev/pts/3. 

The /dev/pts directory is considered to be a file system of type
devpts and appears in the lists of mounted filesystems.  While the
"file" /dev/pts/3 looks like an entry in the now obsolete device
filesystem, /dev/pts Is really a wholly different kind of filesystem.

See the Linux manual pages "pty" and "pts" (Unix 98 style) for more
details.  For programmers there's the man-page openpty/forkpty (either
name displays the same man-page) which assumes that you already
understand pseudo terminals.  There is a usr/include/pty.h file for
use by programmers.  In earlier versions of Linux there was a pty.o
module, but it now seems that it's been built into the kernel.  Here's
an example of some options available when you are compiling a Linux
2.6 kernel:

<tscreen><verb> CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256 </verb></tscreen>

<sect1> The Controlling Terminal /dev/tty 
<p> /dev/tty stands for the
controlling terminal (if any) for the current process.  To find out
which tty's are attached to which processes use the "ps -a" command at
the shell prompt (command line).  Look at the "tty" column.  For the
shell process you're in, /dev/tty is the terminal you are now using.
Type "tty" at the shell prompt to see what it is (see manual pg.
tty(1)).  /dev/tty is something like a link to the actually terminal
device name with some additional features for C-programmers: see the
manual page tty(4).

<sect1> /dev/ttyIN "Terminals" 
<p> N stands for an integer.  One use
of these in Linux is with the ISDN driver package: isdn4linux.  The
ttyIN is something like ttySN but it emulates a modem and can be given
modem commands.

<sect1> The Console: ttyN or vc/N<label id="console_dev"> 
<p> In Linux the PC monitor is usually called the console and has
several device special files associated with it: vc/0 (tty0), vc/1
(tty1), vc/2 (tty2), etc.  When you log in you are on vc/1.  To go to
vc/2 (on the same screen) press down the 2 keys Alt(left)-F3.  For
vc/3 use Left Alt-F3, etc.  These (vc/1, vc/2, vc/3, etc.) are called
"virtual terminals".  vc/0 (tty0) is just an alias for the current
virtual terminal and it's where messages from the system are sent.
Thus messages from the system will be seen on the console (monitor)
regardless of which virtual terminal it is displaying.

You may log in to different virtual terminals and thus have a few
different sessions with the computer going on at the same time.  Only
the system or the root user may write to /dev/vc/0 to which
/dev/console is sometimes linked.  For more info on the console see
<ref id="console_" name="The Linux Console">.

<sect1> Creating a Device with "mknod" 
<p> The /dev directory comes
supplied with many device special files.  If you need something that's
not there you may try to create it with the "mknod" command.  See the
manual page ttys(4) for how to do this for serial ports.  To use
<tt/mknod/ you must know the major and minor device numbers.  You
might be able to infer the numbers you need by using the "<tt/ls -l/"
command in the /dev directory.  It will display the major and minor
numbers of existing special files.

<sect> Some Details on How Terminals Work <label
id="HowTermsWorkDetail">

<p> If you know almost nothing about terminals, it's suggested that
you first read <ref id="intro" name="Introduction"> and also read <ref
id="overview" name="Overview of How Terminals Work">.

<sect1> Terminal Memory Details <label id="term_mem_detail"> 
<p> The
terminal screen refreshes itself at perhaps 60 times per second from
an image stored in the memory of the terminal.  For a PC the monitor's
image is stored on the video card inside the computer but for a
terminal, the equivalent of the video card is inside the terminal.
For a text terminal the storage of the image uses little memory.
Instead of putting every dot (pixel) on the screen into memory and
requiring the storage of about a quarter-million dots, a much more
efficient method of storage is used.

A screen-full of text may be represented inside the terminal memory by
ASCII bytes, one for each character on the screen.   An entire screen
only takes about 2K ASCII bytes.  To display these characters, the
terminal must also know the bit-map (the shape) of each of the almost
100 printable ASCII characters.  With a bit-map of a character using
say 15 bytes, only about 1.5K of memory is needed for the bit-maps of
all the ASCII characters (the font).  This ASCII text and font memory
is scanned so that the resulting image is put on the screen about 60
times each second.  This is a form of shared memory where a single
bit-map of a letter such as the letter e, is shared by all of the many
letter e's which appear on a screen-full of text.  Low memory
requirements meant low costs to produce monitors in the early 1980's
when the cost of memory was several thousand times higher than it is
today (costing then several dollars per kilobyte).

<sect1> Early Terminals  <label id="early_terms"> 
<p> The first terminals were something like remotely controlled
typewriters which could only "display" (print on paper) the character
stream sent to them from the computer.  The earliest models were
called <ref id="teletype" name="Teletypes">.  The name "tty" is just
an abbreviation for "Teletype".   Early terminals could do a line feed
and a carriage return just like a typewriter and ring a bell when a
bell character was received.  Due to the lack of significant
capabilities this was the first type of terminal to be labeled "dumb".
This type of terminal interface (using a terminal type called "dumb")
is sometimes used today when the computer can't figure out what kind
of a terminal it is communicating with.

<sect1> Escape Sequences and Control Codes (intro) 
<p> Terminals have
many capabilities some of which are always present and some of which
require commands from the computer to change or activate.  To exercise
all these capabilities under the control of the computer requires that
special codes be established so that the computer can tell the
terminal what to do.  There are two major type of such codes: escape
sequences and control codes (control characters).  There are many
times more escape sequences than control codes.

<sect2> Control codes  <label id="control_codes"> 
<p> The control
codes (or control characters) consist of the first 32 bytes of the
ASCII alphabet.  They include the following: carriage-return (cursor
to far left), line-feed (cursor down one line), backspace,
escape-character, tab, and bell.  They do not normally show on the
screen.  There is usually a command which you may give to your
terminal which will result in them being displayed when they are
received by the terminal.  It's called something like "Display
Controls" or "Monitor".  If you do this then the display may look a
mess since escape sequences, which all start with the ESC (escape)
control character, are no longer executed.  Words which should appear
at the top or bottom of the screen will show up in other locations.
The escape sequences to reposition the cursor display on the screen
but the cursor doesn't move to where the escape sequence says.

<sect2> Escape sequences <label id="esc_seq"> 
<p> Since there are not
nearly enough control codes to do everything (and for some reason, not
all of them are utilized) many escape sequences are used.  They
consist of the "escape" (ESC) control character followed by a sequence
of ordinary characters.  Upon receiving an escape character, the
terminal examines the characters following it so that it may interpret
the sequence and carry out the intended command from the computer.
Once it recognizes the end of a valid sequence, further characters
received just display on the screen (unless they are control codes or
more escape sequences).  Some escape sequences may take parameters (or
arguments) such as the coordinates on the screen to move the cursor
to.  The parameters become a part of the escape sequence.  An <ref
id="esc_seq_lists" name="Esc Sequence List"> is on the web for some
terminals, but it's terse.

A list of the escape sequences for your terminal should be in the
"programmers manual" for the terminal.  Except for very old terminals,
there may be two or three hundred such sequences.  If you don't have a
such manual it's not easy to find them.  Some of the sequences are
available on the Internet.  One link is <ref id="esc_seq_lists"
name="Esc Sequence List">.  By searching the Internet for one sequence
(such as ESC&lsqb;5m) you may come across a long list of them.

Another way to determine some of them is to find the terminfo entry
(termcap) for the terminal and mentally decode it.  See <ref
id="termcap2" name="Terminfo and Termcap (detailed)"> in this document
and/or the <ref id="termcap_docs" name="Termcap Manual"> on the
Internet.  Unfortunately, the terminfo (termcap) for a terminal often
does not list all of the escape sequences which the terminal has
available for use, but fortunately, the most important ones are
usually there.

<sect1> Display Attributes & Magic Cookies <label
id="display_attributes"> <p> Terminals have various methods of
generating character attributes such as bold, reverse-video,
underlining, etc.  There should be no need for the user to worry about
how this is done, except that it creates problems for some old
terminals and there is sometimes an option for this in the set-up menu
of newer terminals.

The magic cookie method is obsolete.  It's the simplest (and worst)
method of defining attributes: Use a certain byte for the start of an
attribute and another to end that attribute.  For example, a "start
underlining" magic cookie byte is placed just before the first word to
be underlined.  These extra bytes are put into the memory of the
screen page, just like character bytes that display as characters.
But this might foul up the count of the number of characters per line
since non-printable magic cookie characters are intermingled with
other printable characters.  This sometimes causes problems.

A better method which uses more memory is to assign an attribute byte
(or half=byte, etc.) to each displayed character.  This method is used
by PC video cards (for text) for the common PC monitor.

<sect> Special Features/Types of Some Terminals

<sect1> Terminal Uses a PC Monitor
<p>One may use a PC (including it's monitor) to emulate a terminal.
But PCs have become so powerful that only a small portion of the PC's
capacity is utilized to run the emulation.  So why not make a tiny PC
that has low computing capability so it is barely able do the task of
emulating a terminal.  Then call this tiny device a text terminal and
point out that one must supply and plug in a PC monitor in order to
use this terminal.  Such devices exist and are only about an inch
high.  They are sometimes referred to as small footprint terminals.
Their advantage is that they are cheap, take up little space, and
might be able to use surplus monitors that otherwise might be
discarded.

<sect1> Color 
<sect2>Emulated text terminals
<p>In contrast to the monochrome or most real text terminals, an
emulated text terminal usually has colors since it displays on a PC
color monitor.  See <ref id="colors" name="Colors on Emulated Terminals">

<sect2>Old real text terminal
<p>Some real terminals had color displays but most had either no color
or fixed "color" displays other than white such as green or amber.  All
terminals had black (electron beam turned off = zero brightness).  A
real color terminal can change the color of the text and background to
many different colors while a monochrome terminal can only change the
brightness of a fixed color.

However, changing the brightness, etc. gives a lot of possibilities.
For example, a black and white (monochrome) terminal can have white,
grey, and black by varying the brightness.  Some words can be black on
a light grey background while other are highlighted by black on white.
In addition there is white on black, underlining, and blinking.

Real color works like the color on a computer monitor or TV screen.
The CRT has three colors of dots permanently on it with the brightness
of each color controlled by its own electron beam (3 beams).  The
monochrome of real text terminals had inherently better resolution
since it didn't depend on dots permanently fixed on the screen.  For
text terminals the only use of color is to differentiate text and this
advantage was often not worth the cost of worse resolution.  Thus
monochrome may have historically been better since it also cost less.
But today color displays have are ubiquitous and have improved in
resolution since the olden days of the real text terminal.

<sect1> Multiple Sessions 
<p> For dual sessions the terminal has two
serial ports of equal status.  Each port is connected to a serial port
on a different computer.  Thus one may log in to two different
computers with each session displaying in a split-screen window.
Alternatively, each session may run full-screen with a "hot" key (or
the like) to switch between sessions.  One could also connect to two
different serial ports on the same computer and log in twice (similar
to "virtual terminals" at the console).  The program "screen" will
make any ordinary terminal (single session) connected to a single
computer run two or more "sessions".

<sect1> Printer/Auxiliary Port 
<p> Many terminals have a connector on
the rear for such a port.  It may be labeled as "Aux" or "Printer",
etc.  Some printer ports are for parallel printers while others are
for serial printers.  If a printer is connected to the printer or
auxiliary port, then pressing certain keys will print the screen.  One
may also have everything that displays on the screen go also to the
printer.  If the port is an auxiliary port, one may connect this to
another computer and almost have dual sessions as above.  However, the
video memory inside the terminal may not retain both sessions so you
may need to refresh the screen when switching to the other session.
There will likely not be a hot key either but possibly a programmable
function key may be programmed to do this.  There exists various key
combinations and escape sequences for controlling such a port.  See
<ref id="printer_esc" name="Printer Esc">.

There is a program called <tt/vtprint/ which is designed to send a
print job (text only) to your terminal to be printed on a printer
attached to the terminal.  It's homepage is <tt><url
url="http://vtprint.sourceforge.net/" name="vtprint"></tt>.  It's also
included in the Debian distribution of Linux.  <tt/xprt/ (also in
Debian) seems to do something similar, but only for X Window terminals
??

Using the printer port to print may be useful if you don't have an
extra port on your PC for a printer or for "point of sale" use in a
store.  "Transparent print mode" is where whatever the PC sends out to
the terminal goes instead to the printer.  If you want the printer to
be able to send bytes to the PC (in the reverse direction) then (per
Wyse) it's "bidirectional mode".  The Wyse "auxiliary print mode" is
just transparent print mode where the terminal screen monitors what's
being printed.

<sect1> Pages <label id="pages_"> 
<p> Many terminals permit the
storage of more than one page in their video memory.  Sometimes the
page size is the same as the screen, but sometimes it is larger so
that scrolling will reveal unseen parts of a page.  So when one looks
at a screen, there may be hidden text on the same page above or below
the display.  In addition, if there is more than just one page, there
may be hidden text on these other pages.  One use for pages is on
terminals that support dual sessions.  Each session may have its own
page and one may switch back and forth between them.

Even if you only have a one-page-terminal with the page sized equal to
what is displayed on the screen, you will still see other pages of a
file (etc.) as the host sends more data to the terminal.  One
advantage to having additional pages stored in the terminal memory is
so that you can jump to them instantly without waiting a second or so
for them to be transmitted from the host.

Multiple pages is supported by ncurses.  There is also a commercial
program called "Multiscreen" which supports multiple pages but
probably not for Linux ??  Multiscreen is reported to be part of SCO
and is something like the virtual terminals on a Linux PC console.
The Linux program "screen" makes it look like you have multiple pages
but they are stored in the computer and but you can have only one
page-like window for each running program.

<sect1> Character-Sets <label id="char_sets">

<p> A character-set is normally represented by a list (or table or
chart) of characters along with the byte code assigned to each
character.  The codes for a byte range from 0 to 255 (00 to FF in
hexadecimal).  In MS-DOS, character-set tables are called
"code-pages".  You should examine such a table if you're not familiar
with them.  They are sometimes included in printer and terminal
manuals but also are found on the Internet.

Many character sets include letters from foreign languages.  But they
may also include special characters used to draw boxes and other
special characters.

ASCII was the traditional English character set used on text terminals
It is a 7-bit code but will usually work OK even if your terminal is
set to 8-bit mode.  In 8-bit mode with ASCII, the high order bit is
always set to zero.  Other character-sets are usually available and
usually use 8-bit codes (except on very old terminals where the only
choice is ASCII).  The first half of most character-sets are the
conventional 128 ASCII characters and the second half (with the
high-order bit set to 1) belong to a wide variety of character-sets.
Character sets are often ISO standards.  To get specialized character
sets on a terminal, you may need to download a soft-font for that
character-set into the memory of the terminal.  Many terminals have a
number of built-in character sets (but perhaps not the one you need).

Here are some common 8-bit character sets.  CP stands for Code Page
character sets invented by IBM: CP-437 (DOS ECS), ISO-8859-1
(Latin-1), CP-850 (Multilingual Latin 1 --not the same as ISO
Latin-1), CP-1252 (WinLatin1 = MS-ANSI).  MS Windows uses CP-1252
(WinLatin1) while the Internet often uses Latin-1.  There are several
ISO-8859- character sets in addition to Latin-1.  These include Greek
(-7), Arabic (-6), Eastern European (-2), and a replacement for
Latin-1 (-15) called Latin-9.  There are many others.  For example,
KOI8-R is more commonly used for Russian than IS0-8859-5.  Unicode is
a very large character-set where each character is represented by 2
bytes instead on just one byte.

More info re character-sets are: 
<itemize>
<item> Manual pages: charsets, iso_8859-l or latin1 (covers 8859 series), ascii
<item> HOWTO's for various languages (often written in that language).
<item> <url url="http://czyborra.com/charsets/iso8859.html"
name="ISO-8859 Alphabet Soup"> More than just iso8859.  Extensive.
<item> <url url="http://www.cs.tut.fi/~jkorpela/chars.html" name="A
tutorial on character code issues"> Clearly written.
<item> <url url="http://www.w3.org/International/O-charset-lang.html"
name="Languages, Countries and Character Sets">
<item> <url url="http://www.osk.3web.ne.jp/logos/" name="Languages of
the World by Computers ...">
<item> <url url="ftp://kermit.columbia.edu/kermit/e/isok7.txt" name="...
International Character Sets">
</itemize>

Once you've found the character set name (or alpha-numeric
designation) you are interested in, you may search for more info about
it on the Internet.

<sect2> Graphics (Line Drawing, etc.) 
<p> There are special characters
for drawing boxes, etc.  There are also numerous non-ASCII symbols
such as bullets.   These may either be part of an 8-bit character set
(such as WinLatin1 = CP-1252) or provided as a separate font (in vt100
terminals).  Your terminfo may be set up to use them.  But if you see
a row of letters when there should be a line, it may mean that
terminfo hasn't implemented them.

You need to know the following if your graphics don't work right.  The
default graphic character set is the vt-100 ANSI graphics.  Otherwise
the string acsc must be defined in your terminfo.  It establishes a
map between the vt-100 graphic characters codes and the actual codes
used on your terminal.  So even if your terminal doesn't have the
vt-100 graphics, it can likely still generate such graphics with some
other character set.  If terminfo has it right, this will happen
automatically.

If character sets must be switched then the terminfo variables: enacs,
rmacs, and smacs should be defined.  Note acs = Alternate Character
Set.  Even if the upper half of the normal character set contains the
graphic characters it may be considered a separate 7-bit character set
that needs to be switched to.

<sect2> National Replacement Characters (obsolete) 
<p> In the 1960's,
the ASCII 7-bit code was devised to map 7-bit bytes to English
letters, numbers, punctuation marks, etc.  Other countries adopted
ASCII, but most of them had some additional letters which were not
present in the ASCII code.  What to do?  Various people decided to
purge certain symbols (such as ^, }) from ASCII and to substitute
national letters (ones with dots over them, etc.) for the ASCII
letters.  In other words they replaced ASCII letters with "National
Replacement Characters"

There were a lot of problems with this, since it was done mostly by
companies which sold computer terminals with a resulting lack of
standardization.  Another problem was that sometimes the purged
symbols were needed.  This problem was solved in the 1980's and 1990's
with the adoption of 8-bits/byte character sets which had many more
letters.

Many West-European languages only needed several additional letters
which were not in ASCII.  To get them in 7-bit code, they borrowed the
codes for seldom used ASCII symbols:<newline> @  [  \  ]  ^  `  {  \
}  &tilde<newline> The symbols $ and # are sometimes used also.   So
when using these replacement character sets, you are deprived of using
certain of these ASCII symbols since they now are used for the new
non-ASCII letters.  Now that 8-bit character codes have replaced 7-bit
ones, it's better to use an 8-bit code which has both all the ASCII
symbols plus the non-ASCII characters for various languages.  There's
also Unicode which replaces 8-bit codes with the same code scheme to
cover all languages (well almost all significant ones).

ISO-646 (for 1972 and later) permitted using National Replacement
Characters (7-bit).  It specified that the above mentioned character
codes may be borrowed, but doesn't specify which national characters
are to replace them.  Some countries standardized the replacements
by registering them with ECMA.

Many terminals exist which support these national replacement
characters but you probably don't want to implement this support
unless you have some old files to read.  Very old terminals may only
support the national characters for the country in which they were
sold.  Later terminals offered a choice of languages.  Modem terminals
are 8-bit and don't need "national replacements".  Replacement
characters exist for the following languages/countries: British, Cuba
(Spanish), Dutch, Finnish, French, French Canadian, German, Hebrew,
Hungarian, Italian, Norwegian/Danish, Portuguese, Spanish, Swedish,
Swiss (German).

Here's tables for some character sets taken from Kermit and Unisys
documents:

<tscreen><verb>
			      Swedish     Danish
ASCII           German        Finnish      Norwegian    French

@ at-sign       section       -------      -------      a-grave
[ left-bracket  A-diaeresis   A-diaeresis  AE-digraph   degree
/ backslash     O-diaeresis   O-diaeresis  O-slash      c-cedilla
] right-bracket U-diaeresis   A-circle     A-circle     section
^ circumflex    ------        U-diaeresis  -------      -------
` accent-grave  ------        e-acute      -------      -------
{ left-brace    a-diaeresis   a-diaeresis  ae-digraph   e-acute
| vertical-bar  o-diaeresis   o-diaeresis  o-circle     u-grave
} right-brace   u-diaeresis   a-circle     a-circle     e-grave
~ tilde         ess-zet       u-diaeresis  --------     diaeresis

ASCII		 Italian     Spanish

@ at-sign        section     section
[ left-bracket   degree      inverted-exclamation
/ backslash      #-pound     N-tilde
] right-bracket  e-acute     inverted-question-mark
^ circumflex     -------     -------
` accent-grave   u-grave     -------
{ left-brace     a-grave     degree
| vertical-bar   o-grave     n-tilde
} right-brace    e-grave     --------
~ tilde          i-grave     --------
</verb></tscreen>

<sect1> Fonts

<p> Most terminals made after the mid 1980's can accept downloaded
soft-font.  This means that they can display almost any character set
provided that you can find the soft-font for it.  If you can't find
the needed soft-font, you can always create your own.  A free font
editor for this is called BitFontEdit (written by the author of this
document) and is at<newline>
<url url="http://www.ibiblio.org/pub/Linux/utils/terminal/"><newline>
For mapping the keyboard (and screen) for use of various fonts see
<ref id="mapchan_" name="Character Mapping: mapchan">

<sect1> Keyboards & Special Keys

<p>Terminal keyboards often have a number of keys that one doesn't find
on a PC keyboard.  Few (if any) actual terminals will have all of
these keys and most will have additional keys not listed here.  Some
have a large number of special purpose keys such as terminals made for
use with cash registers.  There are often many more key meanings than
shown here since these keys often have extended meanings when used in
conjunction with other keys (such as shift and control).

<itemize>
<item> BREAK sends a very long 0 bit (space = +12 V) of duration 300
to 700 milliseconds to the host.  The host may interpret this as an
interrupt if stty has set brkint or ignore it if ignbrk is set.

<item> NO SCROLL stops the screen from scrolling like ^S does.
Depressing it again resumes scrolling.  Uses flow control signals to
do this.

<item> REPEAT if held down with an other key, forces repeated output of
that other key even if the auto-repeat option is set to off.

<item> LINE FEED sends the line feed character ^J to the host.  Seldom
used.

<item> SET-UP allows the manual configuration of the terminal via
menus.  Sometimes purposely disabled by putting a block under it so it
can't be pressed down.  Sometimes another key such as shift or control
must be pressed at the same time. See <ref id="enter_setup"
name="Getting Into Set-Up (Configuration) Mode">.

<item> LOCAL disconnects the terminal from the host.  In local, what
one types goes directly to the screen.  Useful for testing.

<item> RETURN is the same as the "enter" key on a PC.  It usually
sends a carriage return to the host which normally get translated to a
new-line character by the host's device driver.  On some terminals it
may be set up to send something else.

<item> F1, F2, ... or PF1, PF2, ... are function keys which sometimes
may be programmed to send out a sequence of bytes (characters).  See
<ref id="funct_keys" name="Function Keys">
</itemize>

<sect1> Mouse
<p> A few text-terminals support a mouse.  When the mouse is clicked,
an escape sequence is sent to the host to tell it where the mouse is.
An article for a mouse on VT terminals was once at 
http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html but it's now a
dead link (2013).  Try the "Wayback" machine." These escape codes for
mice are called "DEC Locator sequences". The FALCO Infinity Series of
terminals, model ANSI-G supports it. Did any linux applications support
this ??  

<sect> Terminal Emulation (including the Console) <label id="term_emulation">

<sect1> Intro to Terminal Emulation
<p> A trivial type of terminal emulation is where you set up a real
terminal to emulate another brand/model of terminal.  To do this you
select the emulation you want (called "personality" in Wyse jargon)
from the terminal's set-up menu.  This section will not discuss this
case.

Since a PC has a screen and keyboard (as does a real terminal) but
also has much more computing power, it's easy to use some of this
computing power to make the PC computer behave like a real text
terminal.   Still a third type is where you just use a text-based
interface (at the console --usually just the monitor) to your Linux
PC, either by a terminal screen (such as xterm) in Xwindow or by a
"virtual terminal".  

To fully emulate a real terminal on a PC requires that a serial
port of the computer will be used to connect the emulated terminal to
another computer.  This would be either with a direct cable connection
from serial port to serial port, or via a modem.  But in other cases,
the serial port will not be used directly as the interface.  Instead,
the interface may be a network and the flow of bytes to and from the
terminal will travel in network packets via either a modem on a serial
port or via an ethernet port.

Emulation for connection to a remote computer provides more that just
a real text-terminal since the PC doing the emulation can also do
other tasks at the same time it's emulating a terminal.  For example,
for serial port connections, kermit or zmodem may be run on the PC to
enable transfer of files over the serial line (and possibly over the
phone line via a modem) to the other computer that you are connected
to.  The emulation needs only to be run on one of the virtual consoles
of the PC, leaving the other virtual consoles available for using the
PC in command-line-interface.

For Linux see <ref id="pc_as_terminal" name="Make a Linux PC a serial
port terminal">.  Emulation software for this also available for use
under MS Windows.  See <ref id="non_linux_pc" name="Make a non-Linux
PC a terminal">  This can be used to connect a Windows PC (as a
Text-Terminal) to a Linux PC.

Most Linux free software can only emulate a VT100, VT102, or
VT100/ANSI, xterm, pterm, or Wyse60 (but not fully).  Since most PC's
have color monitors while VT100 and VT102 were designed for a
monochrome monitor, the emulation usually adds color capabilities
(including a choice of colors).  Sometimes the emulation is not 100%
perfect but this usually causes few problems.  None of them provide
programmable function keys.  The non-free emulation software running
under MS Windows can emulate many more terminals than free Linux can.

<sect1> Don't Try to Use TERM Variable for Emulation
 <label id="term_not_for_emulation">
<p> Some have erroneously thought that they could create an emulator
at a Linux console (monitor) by setting the environment variable TERM
to the type of terminal they would like to emulate.  This does not
work.  The value of TERM only tells an application program what
terminal you are using.  This way it doesn't need to interactively ask
you this question (and it's too dumb to be able to probe the terminal to
find out what type it is).  If you're at a Linux PC monitor (command
line interface) it's a terminal of type "Linux", and since you can't
change this, TERM must be set to "Linux".  But this "Linux" should be
set automatically, without you needing to do anything.

If you set it to something else, you are fibbing to an application
program.  As a result, it will incorrectly interpret certain escape
sequences from the console resulting in a corrupted interface.  Since
the Linux console behaves almost like a vt100 terminal, it could still
work almost OK if you falsely claimed it was a vt100 (or some other
terminal which is close to a vt100).  In this case it may seeming work
OK most of the time but once in a while will give errors.

<sect1> Serial Communication programs 
<p>while the newer free PuTTY and Terra-Term programs can connect
directly to a serial line but can't dial out, most of the older
programs did dialing out via a serial port modem.  Some dialing
programs are for making a PPP connection to the Internet via a modem,
such as wvdial, and don't normally include any terminal emulation.
But some other programs (such as minicom or seyon) do both terminal
emulation and modem dialing (without PPP so it's not easy to use them
to connect to the internet).  But since these programs connect to a
modem via a specified serial port (including "internal" serial ports
that have no connector on the back of the PC), they may be used to
connect to a serial line via a possible serial port connector on the
back of a PC.  For this case you just set them up to connect without
dialing a phone number.  The program "picocom" just does terminal
emulation although it's possible to type in a modem command and a
phone number to dial out manually.  These programs are also useful for
testing modems.  Seyon is only for use with X Window and can emulate
Tektronix 4014 terminals.  In the past (before the Internet was
widespread) one could use dialing programs to dial up some public
libraries to use their catalogs and indexes, or even read magazine
articles on line.  But today such activity is almost always done using
the Internet where there is a much larger choice of connections and no
long-distance telephone bills.  

The communication program C-Kermit (sometimes just called kermit)
doesn't do terminal emulation for Linux (in 2006).  But Kermit can
emulate many terminals in its non-free MS Windows versions so you`ll
see lots of claims that Kermit can do terminal emulation.  With Linux,
it's merely a semi-transparent pipe between whatever terminal you are
on and the remote site you are connected to.  Thus if you use kermit
on a Linux PC the terminal type will be "Linux".  If you have a Wyse60
connected to your PC and run kermit from that, you will appear as a
Wyse60 to the remote computer (which may not be able to handle Wyse60
terminals).  Minicom emulates a VT102 and if you use it on Wyse60
terminal vt102 the remote host will think you are a vt102 and send you
vt102 escape sequences.  These will flow into your computer's serial
port and will get translated to the Wyse escape sequences before going
out another serial port on your computer to your Wyse60 terminal.
C-Kermit can't do this sort of thing.

Emulators exist under DOS such as <tt/telix/ and <tt/procomm/ work
just as well.  The terminal emulated is often the old VT100, VT102, or
ANSI (like VT100).

<sect2> Emulation under X Window
<p>There are many terminal emulation programs (such as xterm, uxterm.
gnome-terminal, and konsole) which may be run under X Window.  They can
usually emulate a VT102, but some may be able to emulate at VT220, or
Tektronix 4014.  They provide a command line interface to the computer
but they don't communicate via the serial port like a text terminal.
See <url
url="http://packages.ubuntu.com/dapper/virtual/x-terminal-emulator"
name="Ubuntu -- x-terminal-emulator"> for a brief list of such
emulators.  Some are multilingual.  Your Linux distribution has likely
installed one for you.

<sect2> Real terminals once were better
<p> Unless one was using X Window with a large display, a real
terminal was often nicer to use than emulating one.  It often had
better resolution for text (since it's monochrome), and had no disk
drives to make annoying noises.  Today, the resolution of modern color
displays is better than that of the old text-terminals and disk drives
are quieter.

<sect1> Testing Terminal Emulation
<p> For the VT series terminals there is a test program: <tt/vttest/
to help determine if a terminal behaves correctly like a vt53, vt100,
vt102, vt220, vt320, vt420 etc.  There is no documentation but it has
menus and is easy to use.  To compile it run the configure script and
then type "make".  It may be downloaded from: <url
url="http://www.ibiblio.org/pub/Linux/utils/console/">

<sect1> The Linux Console <label id="console_">
<p> The console for a PC Linux system is normally the computer monitor
in text mode.  It emulates a terminal of type "Linux" and the escape
sequences it uses are in the man page: console_codes.  There is no way
to make this interface emulate anything else.  But of course you can run
emulation software on your PC so that the monitor and keyboard will
emulate a text terminal while that software program is running.
Setting the TERM environment variable to any type of terminal other
than "Linux" will not result in emulating that other terminal.  It
will only result in a corrupted interface since you have falsely
declared (via the TERM variable) that your "terminal" is of a type
different from what it actually is: Linux.  See <ref
id="term_not_for_emulation" name="Don't Use TERM For Emulation">

In X Window, using a terminal emulator gives you the equivalent of a
console.  For KDE they chose to call this emulation "konsole".
In some cases, the console for a Linux PC is a text-terminal.  One may
recompile Linux to make a terminal receive most of the messages which
normally go to the console.  See <ref id="term_as_console" name="Make
a Serial Terminal the Console">.

The "Linux" emulation of the monitor is flexible and has features
which go well beyond those of the vt102 terminal which it was intended
to emulate.  These include the ability to use custom fonts and easily
re-map the keyboard.  These extra features reside in the console
driver software (including the keyboard driver).  The console driver
only works for the monitor and will not work for a real terminal even
if it's being used for the console.  Thus the "console driver" is
really a "monitor driver".  In the early days of Linux one couldn't
use a real terminal as the console so "monitor" and "console" were
once always the same thing.

The stty commands work for the monitor-console just like it was a real
terminal.  They are handled by the same terminal driver that is used
for real terminals.  Bytes headed for the screen first go thru the
terminal (tty) driver and then thru the console driver.  For the monitor
some of the stty commands don't do anything (such as setting the baud rate).
You may set the monitor baud rate to any allowed value (such as a slow
300 speed) but the actual speed of putting text on the monitor screen
will not actually change.  The file /etc/ioctl.save stores stty
settings for use only when the console is in single user mode (but you
are normally in multiuser-user mode).  This is explained (a little) in the
init man page.

Many commands exist to utilize the added features provided by the
console-monitor driver.   Real terminals, which use neither scan codes
nor VGA cards, unfortunately can't use these features.  To find out
more about the console see the Keyboard-and-Console-HOWTO.  Also see
the various man pages about the console (type "man -k console").
Unfortunately, much of this documentation is outdated.

<sect1> Emulation Software
<p> Since there are free programs to emulate the most common
terminals, you will unlikely need to use any non-free software.  But
if you need to purchase software you should try to throughly check out
what other customers have to say about it.

<sect2> Make a Linux PC a serial port terminal <label
id="pc_as_terminal"> 
<p> Unless you want to emulate the standard vt100
(or close to it), xterm, or a Wyse 60, there doesn't seem to be much
free terminal emulation software available for Linux.  The free
programs are minicom, picocom, and for GUI: seyon and PuTTY.  Seyon
can emulate either xterm or vt100 while PuTTy uses its own termcap
(terminfo) named "putty" (put the terminal type "putty" in
/etc/inittab).  Putty's "pterm" can be used as a replacement for
xterm.

PuTTY is much newer than most other emulations and a major use of it
is as an SSH client but you can set its configuration for a serial
port connection.  Seyon is much older but with more features (some of
which are seldom needed).  There are also more recent (but weaker)
"emulators" for a GUI interface: gtkterm and cutecom, neither of which
can emulate any terminal except of type "dumb" ??).  Seyon can also
emulate a Tektronix 4014 terminal.  For Wyse see <url
url="http://gutschke.com/wy60/" name="Wyse 60 emulator">.

Both gtkterm (and likely cutecom) don't use escape sequences, and
might be said to emulate a terminal of type "dumb" so they would be
quite slow if used as a text terminal for editing files on the host
computer using the vim editor, etc.  gtkterm is simple to set up and
very weak in capabilities but it does show its current status at the
bottom of the screen.

Minicom, PuTTY, picocom, gtkterm, or cutecom may be used to emulate a
directly connected terminal by simply starting one of them.  For
minicom, you must configure it for the serial port used).  Picocom is
like a mini-minicom and doesn't have automatic dialout capability.
Gtkterm might be called a "mini-mini-minicom".

Minicom : For the case of minicom you obviously don't try to dial-out.
When you want to quit minicom (after you logout from the other PC) you
use minicom's q command to quit without reset since there is no modem
to reset.  When minicom starts, it automatically sends out a modem
init string to the serial port.  But since there's no modem there, the
string gets put after the "login:" prompt.  If this string is mostly
capital letters, the getty program (which runs login) at the other PC
may think that your terminal has only capital letters and try to use
only capital letters.  To avoid this, configure the modem init strings
sent by minicom to null (erase the init strings).

The non-free terminal emulator "Procomm" (which is from the MS world),
can be used on a Linux PC if you run dosemu to emulate Dos or possibly
in a mode emulating MS Windows.  The last version of it seems to be
4.8 released in around 2000 so it will likely not work with modern MS
systems.  It was sold by Symantec which has many files supporting it
which may be found using their search engine at <url
url="http://www.symantec.com/">.  And if you check the Internet (in
2008), it's still being sold here and there.

There was a specialized Linux distribution: Serial Terminal Linux.  It
would turn a PC to into a minicom-like terminal.  It's small (fits on a
floppy) and will not let you use the PC for any other purpose (when it's
running).  The link to it is broken, but one similar to it (in 2013),
but on CD, is <url url="http://www.asashi.net/pages/pitux.html"
name="ASASHI DOT NET: PITUX, micro SERIAL TERMINAL LINUX">

TERM (non-free commercial software from Century Software) <url
url="http://www.centurysoftware.com/terminal_emulator/advanced_terminal_emulator.php"
name="Terminal Emulator">  can emulate Wyse60, 50; VT 220, 102, 100,
52: TV950, 925, 912; PCTERM; ANSI; IBM3101; ADM-1l; WANG 2110.  Block
mode is available for IBM and Wyse.  It runs on a Linux PC.

<sect2> Make a Linux PC an IBM network terminal
<p>This happens automatically when you run programs like telnet or
ssh, provided of course that your computer is connected to a network
(perhaps via a modem).  Telnet normally uses a network (often the
Internet) to connect your console, which emulates a terminal of type
"Linux", to a remote computer for you to log in to.  However, there
are some  free programs that allow you to use telnet with IBM terminal
emulation on your PC to connect with IBM mainframes.

One IBM program emulates an IBM tn5250 terminal and printer and
another emulates an IBM c3270.  There's also one that emulates an IBM
pr3287 printer (the mainframe thinks it's connected to the printer).
The Debian distribution has these.  It's reported that the tn5250
emulates a vt keyboard under Linux and not a 5250 keyboard like it
should.  Also, it's reported that the documentation and keyboard
mapping for the MS Windows version are better than for the Linux
version.

<sect2> Make a non-Linux PC a terminal <label id="non_linux_pc">
<p> Emulators exist which run on non-Linux PCs.  They permit you to
use a non-Linux-PC as a terminal to connected to a Linux-PC.  Under DOS
there were many programs that not only emulated a terminal but let you
dial out with a modem so that you could connect to other computers
over telephone lines (without getting connected to the Internet).  Of
historical interest is an article in Byte magazine from Feb 1994
entitled "DOS Serial Communications.  It was onetime at
http://www.byte.com/art/9402/sec8/art1.htm.

Today Windows comes with "HyperTerminal" (formerly simply called
"Terminal" in Windows 3.x and DOS).  Competing with this is both the
free (open source) PuTTY and the non-free "HyperTerminal Private
Edition" <url url="http://www.hilgraeve.com/htpe/index.html"> which is
non-free to business.  It can emulate vt-220.  PuTTY emulates xterm and
supposedly also vt-102 but it doesn't have file transfer capabilities
(such as zmodem) like HyperTerminal does.  But PuTTY permits a display
with a height of over 24 lines (set the Linux shell variable LINES to
say 32 by typing: LINES=32).  Turbosoft's TTWin (non-free) can emulate
over 80 different terminals under Windows.  See <url
url="http://www.ttwin.com/"> or <url
url="http://www.turbosoft.com.au/"> (Australia).  See also <url
url="http://www.wrq.com/" name="WRQ">

For using a Mac computer to emulate a common terminal use either
PuTTY, Linux's "minicom" (ported to the  Mac OS X) or the old "zterm"
(shareware).  For very old Macs prior to OS X, see the mini-howto:
Mac-Terminal.  <url
url="http://www.carnationsoftware.com/carnation/HT.Carn.Home.html"
name="Carnation Software"> has non-free software to emulate a wide
variety of terminals on a Mac.  Mac OS X has a "terminal" program that
gives you a terminal window just like the xterm window in Linux's X
Window.  In that window you may run "minicom" (if it's available).
Both the "fink" and "darwinports" projects have ported minicom to the
Mac, but they may not have the most recent version and you might need
to compile minicom yourself.


<sect1>Colors on Emulated Terminals <label id="colors">
<p>Since displays used for text terminal emulation are almost always
color displays, you can utilize color coding of words.  Besides
displaying directories this way (See <ref id="ls_color" name="Example
for ls Function">) some other Linux programs display color-coded text.
It seems to mostly happen without any configuring but there may be
color conflicts.  For example, if you have set the background color
green, then if a programs sends you green text, it will be difficult
or impossible to read.

Color usually works by programs sending ANSI escape sequences to the
terminal.  One might think that an emulated terminal would show the
ANSI escape codes in the <ref id="termcap1" name="terminfo">.
for the terminal.  But this is not usually the case since if a terminal
support colors it seems to be assumed that these color will be sent to
the terminal using the ANSI encoding.

If you want to see what these encodings are, look at "man
console_codes".  The ECMA-48 color codes in this man page appear to be
a subset of the ANSI color codes.  For excruciating details see <url
url="http://en.wikipedia.org/wiki/ANSI_escape_code" name="ANSI escape
code - Wikipedia">.  Note that these ANSI codes cover more than just
colors.

For PuTTY one can select the precise color to display for every ANSI
code by using the settings menu and clicking on "Colours".  For
example if you have your screen background light green, then you can
remap that ANSI color to some shade of brown that you select.  Note
that light green is called "Green Bold".  It's bold because it
contains a lot of white which makes it a light color.

<sect> Flow Control (Handshaking) <label
id="flow_control">

<p> Flow control (= handshaking = pacing)  is to prevent too fast of a
flow of bytes from overrunning a terminal, computer, modem or other
device.  Overrunning is when a device can't process what it is
receiving quickly enough and thus loses bytes and/or makes other
serious errors.  What flow control does is to halt the flow of bytes
until the terminal (for example) is ready for some more bytes.  Flow
control sends its signal to halt the flow in a direction opposite to
the flow of bytes it wants to stop.  Flow control must both be set at
the terminal and at the computer.

There are 2 types of flow control: hardware and software (Xon/Xoff or
DC1/DC3).  Hardware flow control uses dedicated signal wires such as
RTS/CTS or DTR/DSR while software flow control signals by sending DC1
or DC3 control bytes in the normal data wires.  For hardware flow
control, the cable must be correctly wired.

The flow of data bytes in the cable between 2 serial ports is
bi-directional so there are 2 different flows (and wires) to consider:
<enum>
<item> Byte flow from the computer to the terminal
<item> Byte flow from the terminal keyboard to the computer.
</enum>

<sect1> Why Is Flow Control Needed ?
<p> You might ask: "Why not send at a speed slow enough so that the
device will not be overrun and then flow control is not needed?"  This
is possible but it's usually significantly slower than sending faster
and using flow control.  One reason for this is that one can't just
set the serial port baud rate at any desired speed such as 14,500,
since only a discrete number of choices are available.  The best
choice is to select a rate that is a little higher than the device can
keep up with but then use flow control to make things work right.

If one decides to not use flow control, then the speed must be set low
enough to cope with the worst case situation.  For a terminal, this is
when one sends escape sequences to it to do complex tasks that take more
time than normal.  In the case of a modem (with data compression but
no flow control) the speed from the computer to the modem must be slow
enough so that this same speed is usable on the phone line, since in
the worst case the data is random and can't be compressed.  If one
failed to use flow control, the speed (with data compression turned
on) would be no faster than without using any compression at all.

Buffers are of some help in handling worst case situations of short
duration.  The buffer stores bytes that come in too fast to be
processed at once, and saves them for processing later.

<sect1> Padding <label id="padding">
<p> Another way to handle a "worst case" situation (without using flow
control or buffers) is to add a bunch of nulls (bytes of value zero) to
escape sequences.  Sometimes DEL's are used instead provided they have
no other function.  See <ref id="rec_del" name="Recognize Del">.

The escape sequence starts the terminal doing something, and while the
terminal is busy doing it, it receives a bunch of nulls which it
ignores.  When it gets the last null, it has completed its task and is
ready for the next command.  This is called null padding.  These nulls
formerly were called "fill characters".  These nulls are added just to
"waste" time, but it's not all wasted since the terminal is usually
kept busy doing something else while the nulls are being received.  It
was much used in the past before flow control became popular.  To be
efficient, just the right amount of nulls should be added and figuring
out this is tedious.  It was often done by trial and error since
terminal manuals are of little or no help.  If flow control doesn't
work right or is not implemented, padding is one solution.  Some of
the options to the <tt/stty/ command involve padding.

<sect1> Overrunning a Serial Port
<p> One might wonder how overrunning is possible at a serial port
since both the sending and receiving serial ports involved in a
transmission of data bytes are set for the same speed (in bits/sec)
such as 19,200.  The reason is that although the receiving serial port
electronics can handle the incoming flow rate, the hardware/software
that fetches and processes the bytes from the serial port sometimes
can't cope with the high flow rate.

One cause of this is that the serial port's hardware buffer is
quite small.  Older serial ports had a hardware buffer size of only
one byte (inside the UART chip).  If that one received byte of data in
the buffer is not removed (fetched) by CPU instructions before the
next byte arrives, that byte is lost (the buffer is overrun).  Newer
UART's, namely most 16550's, have 16-byte buffers (but may be set to
emulate a one-byte buffer) and are less likely to overrun.  It may be
set to issue an interrupt when the number of bytes in its buffer
reaches 1, 4, 8, or 14 bytes.  It's the job of another computer chip
(usually the main CPU chip for a computer) to take these incoming
bytes out of this small hardware buffer and process them (as well as
perform other tasks).

When contents of this small hardware receive buffer reaches the
specified limit (one byte for old UART'S) an interrupt is issued.
Then the computer interrupts what it was doing and software checks to
find out what happened.  It finally determines that it needs to fetch
a byte (or more) from the serial port's buffer.  It takes these
byte(s) and puts them into a larger buffer (also a serial port buffer)
that the kernel maintains in main memory.  For the transmit buffer,
the serial hardware issues an interrupt when the buffer is empty (or
nearly so) to tell the CPU to put some more bytes into it to send out.

Terminals also have serial ports and buffers similar to the computer.
Since the flow rate of bytes to the terminal is usually much greater
than the flow in the reverse direction from the keyboard to the host
computer, it's the terminal that is most likely to suffer overrunning.
Of course, if you're using a computer as a terminal (by emulation),
then it is likewise subject to overrunning.

Risky situations where overrunning is more likely are:  1. When
another process has disabled interrupts (for a computer).  2. When the
serial port buffer in main (or terminal) memory is about to overflow.

<sect1> Stop Sending
<p> When its appears that the receiver is about to be overwhelmed by
incoming bytes, it sends a signal to the sender to stop sending.  That
is flow control and the flow control signals are always sent in a
direction opposite to the flow of data which they control (although
not in the same channel or wire).  This signal may either be a control
character (^S = DC3 = Xoff) sent as an ordinary data byte on the data
wire (in-band signalling), or a voltage transition from positive to
negative in the dtr-to-cts (or other) signal wire (out-of-band
signalling).  Using Xoff is called "software flow control" and using
the voltage transition in a dedicated signal wire (inside the cable)
is called hardware flow control.

<sect1> Keyboard Lock <label id="keybrd_lock">
<p> With terminals, the most common case of "stop sending" is where
the terminal can't keep up with the characters being sent to it and it
issues a "stop" to the PC.  Another case of this is where someone
presses control-S.  Much less common is the opposite case where the PC
can't keep up with your typing speed and tells the terminal to stop
sending.  The terminal "locks" its keyboard and a message or light
should inform you of this.  Anything you type at a locked keyboard is
ignored.  When the PC catches up on it's work, then the keyboard
should unlock.  When it doesn't, there is likely some sort of deadlock
going on.

Another type of keyboard lock happens when a certain escape sequence
(or just the ^O control character for Wyse 60) is sent to the
terminal.  While the previous type of lock is done by the serial
driver, this type of lock is done by the hardware of a real terminal.
It's a catch-22 situation if this happens since you can't type any
commands to escape out of this lock.  Going into setup and resetting
might work (but it failed on my Wyse 60 and I had to cycle power to
escape).  One could also send an "unlock keyboard" escape sequence
from another terminal.

The term "locked" is also sometimes used for the common case of where
the computer is told to stop sending to a terminal.  The keyboard is
not locked so that whatever you type goes to the computer.  Since the
computer can't send anything back to you, characters you type don't
display on the screen and it may seem like the keyboard is locked.
Scrolling is locked (scroll lock) but the keyboard is not locked.

<sect1> Resume Sending
<p> When the receiver has caught up with its processing and is ready
to receive more data bytes it signals the sender.  For software flow
control this signal is the control character ^Q = DC1 = Xon which is
sent on the regular data line.  For hardware flow control the voltage
in a signal line goes from negative (negated) to positive (asserted).
If a terminal is told to resume sending the keyboard is then unlocked
and ready to use.

<sect1> Hardware Flow Control (RTS/CTS etc.) <label
id="hdw_flow_control">

<p> Some older terminals have no hardware flow control while others
used a wide assortment of different pins on the serial port for this.
For a list of various pins and their names see <ref
id="null_modem_pinout" name="Standard Null Modem Cable Pin-out">.  The
most popular pin to use seems to be the DTR pin (or both the DTR pin
and the DSR pin).

<sect2> RTS/CTS, DTR, and DTR/DSR Flow Control
<p> Linux PC's use RTS/CTS flow control, but DTR/DSR flow control
(used by some terminals) behaves similarly.  DTR flow control (in one
direction only and also used by some terminals) is only the DTR part
of DTR/DSR flow control.

RTS/CTS uses the pins RTS and CTS on the serial (EIA-232) connector.
RTS means "Request To Send".  When this pin stays asserted (positive
voltage) at the receiver it means: keep sending data to me.  If RTS is
negated (voltage goes negative) it negates "Request To Send" which
means: request not to send to me (stop sending).  When the receiver is
ready for more input, it asserts RTS requesting the other side to
resume sending.  For computers and terminals (both DTE type equipment)
the RTS pin sends the flow control signal to the CTS pin (Clear To
Send) on the other end of the cable.  That is, the RTS pin on one end
of the cable is connected to the CTS pin at the other end.

For a modem (DCE equipment) it's a different scheme since the modem's
RTS pin receives the signal and its CTS pin sends.  While this may
seem confusing, there are valid historical reasons for this which are
too involved to discuss here.

Terminals usually have either DTR or DTR/DSR flow control.  DTR flow
control is the same as DTR/DSR flow control but it's only one-way and
the DSR pin is not used.  For DTR/DSR flow control at a terminal, the
DTR signal is like the signal sent from the RTS pin and the DSR pin is
just like the CTS pin.

<sect2> Connecting up DTR or DTR/DSR Flow Control 
<p> Some terminals use only DTR flow control.  This is only one-way
flow control to keep the terminal from being overrun.  It doesn't
protect the computer from someone typing too fast for the computer to
handle it.  In a standard file-transfer serial cable the DTR pin at
the terminal is connected to the DSR pin at the computer.  But Linux
doesn't support DTR/DSR flow control (although drivers for some
multiport boards may support DTR/DSR flow control.)  A way around this
problem is to simply wire the DTR pin at the terminal to connect to
the CTS pin at the computer and set RTS/CTS flow control (stty
crtscts).  The fact that it's only one way will not affect anything so
long as the host doesn't get overwhelmed by your typing speed and drop
RTS in a vain attempt to lock your keyboard.  See <ref
id="keybrd_lock" name="Keyboard Lock">.  For DTR/DSR flow control (if
your terminal supports this two-way flow control) you do the above.
But you also connect the DSR pin at the terminal to the RTS pin at the
computer.  Then you are protected if you type too fast.

<sect2> Old RTS/CTS handshaking is different
<p> What is confusing is that there is the original use of RTS where
it means about the opposite of the previous explanation above.  This
original meaning is: I Request To Send to you.  This request was
intended to be sent from a terminal (or computer) to a modem which, if
it decided to grant the request, would send back an asserted CTS from
its CTS pin to the CTS pin of the computer: You are Cleared To Send to
me.  Note that in contrast to the modern RTS/CTS bi-directional flow
control, this only protects the flow in one direction: from the
computer (or terminal) to the modem.

For older terminals, RTS may have this meaning and goes high when the
terminal has data to send out.  The above use is a form of flow
control since if the modem wants the computer to stop sending it drops
CTS (connected to CTS at the computer) and the computer stops sending.

<sect2>  Reverse Channel
<p> Old hard-copy terminals may have a reverse channel pin (such as
pin 19) which behaves like the RTS pin in RTS/CTS flow control.  This
pin but will also be negated if paper or ribbon runs out.  It's often
feasible to connect this pin to the CTS pin of the host computer.
There may be a dip switch to set the polarity of this signal.

<sect1> Is Hardware Flow Control Done by Hardware ?
<p> Some think that hardware flow control is done by hardware but
only a small part of it is done by hardware.  Most of it is actually
done by your operating system software.  UART chips and associated
hardware usually know nothing at all about hardware flow control.
When a hardware flow control signal is received (due to the signal
wire flipping polarity) the hardware gives an electrical interrupt
signal to the CPU.  However, the hardware has no idea what this
interrupt means.  The CPU stops what it was doing and jumps to a table
in main memory that tells the CPU where to go to find a program which
will find out what happened and determine what to do about it.  In
this case this program stops the outgoing flow of bytes.

But even before this program stops the flow,  it was already stopped by
the interrupt which interrupted the work of the CPU.  This is one
reason why hardware flow control stops the flow faster.  It doesn't
need to wait for a program to do it.  But if that program didn't
command that the flow be stopped, the flow would resume once
that program exited.   So the program is essential to stop the flow
even though it is not the first to actually stop the flow.  After the
interrupt happens any bytes (up to 16) which were already in the
serial port's hardware transmit buffer will still get transmitted.  So
even with hardware flow control the flow doesn't instantly stop.

Using software flow control requires that each incoming byte be
checked to see if it's an "off" byte.  These bytes are delayed by
passing thru the 16-byte receive buffer.  If the "off" byte was the
first byte into this buffer, there could be a wait while 15 more bytes
were received.  Then the 16 bytes would get read and the "off" byte
found.  This extra delay doesn't happen with hardware flow control.

<sect1> Obsolete ?? ETX/ACK or ENQ/ACK Flow Control
<p> This is also software flow control and requires a device driver
that knows about it.  Bytes are sent in packets (via the async serial
port) with each packet terminated by an ETX (End of Text) control
character.  When the terminal gets an ETX it waits till it is ready to
receive the next packet and then returns an ACK (Acknowledge).  When
the computer gets the ACK, it then send the next packet.  And so on.
This is not supported by Linux ??   Some HP terminals use the same
scheme but use ENQ instead of ETX.

<sect> Physical Connection <label id="cable">

<sect1> Introduction
<p> A terminal may be connected to its host computer either by a
direct cable connection, via a modem, or via a terminal server.  The
flow of data may be either a direct sequence of bytes (such as from a
serial port) or packets on a network (such as TCP/IP).

<sect1> Multiport I/O Cards (Adapters)
<p> Additional serial cards may be purchased which have many serial
ports on them called "multiport boards".  These boards are not covered
in this HOWTO but there is a list of some of them (with URLs) in the
Serial-HOWTO.

<sect1> Direct Serial Cable Connection.
<p> The simplest way to connect a terminal to a host computer is via a
direct connection to a serial port on the computer.  You may also use
some the info in this section for connecting one computer to another
(via the serial port).  Most desktop PC's come with a serial port or
two, one of which may be used by a mouse.  For the EIA-232 port, you
need a null modem cable (PC-to-PC cable) that crosses over the
transmit and receive wires.  In ethernet terminology it would be
called a "crossover cable" (but the ethernet cable will not work for
the serial port).  If you want hardware flow control, you will
probably use the DTR pin (or both the DTR and DSR pins).

Make sure you have the right kind of cable.  A null modem cable
bought at a computer store may do it (if it's long enough), but it
probably will not work for hardware flow control.  Such a cable may be
labeled as a serial printer cable.   Only larger computer stores are
likely to stock such cables.  A "modem cable" will not work since the
wires go straight thru (and don't cross over).  See <ref
id="buy_or_make_cable" name="Buy or Make"> your own cable.  Make sure
you are connecting to your PC's serial port at the male DB25 or the
DB9, and not to your parallel port (female DB25).

<sect2>Pin numbering
<p>Pin numbers are often printed on the plastic right next to the
pins.  You may need a bright light and/or a magnifying glass to read
them.  Looking at the male pins of a DB connector with the wider row
up, the pin in the upper left is 1 (there is no pin 0).  Then the next
pin in this row is 2, etc.  At the end of this row is pin 5 or 13.
Then the next pin (6 or 14) is in the next row all the way to the left
and below pin 1.  If you look at the female connector with the wider
row up, then pin 1 is in the upper right corner.

<sect2> Null Modem cable pin-out (3, 4, or 5 conductor)
<p> These 3 diagrams are for real text-terminals.  But you could use
them to connect up 2 PCs if you substitute RTS for DTR and CTS for
DSR.  (Don't use 4-conductors for PC-to-PC).  For terminals, if you
only have DTR flow control (one-way) you may eliminate the RTS-to-DSR
wire.  If you have no hardware flow control, then you may also
eliminate the CTS-to-DTR wire.  Then if you have 2@ twisted pairs, you
may then use 2 wires for signal ground per <ref id="twist_pair_kludge"
name="A Kludge using Twisted-Pair Cable">.  For a DB25 connector on
your PC, you need:

<tscreen><verb>
  PC male DB25				Terminal DB25
    TxD   Transmit Data       2 --> 3       RxD   Receive Data
    RxD   Receive Data        3 <-- 2       TxD   Transmit Data
    SG    Signal Ground       7 --- 7       SG    Signal Ground
    CTS   Clear To Send       5 <--20       DTR   Data Terminal Ready
    RTS   Request To Send     4	--> 6       DSR   Data Set Ready
</verb></tscreen>

If you have a DB9 connector on your PC, try the following:
<tscreen><verb>
	PC DB9   			       Terminal DB25
    RxD   Receive Data        2 <-- 2	    TxD   Transmit Data
    TxD   Transmit Data       3 --> 3	    RxD   Receive Data
    SG    Signal Ground       5 --- 7 	    SG    Signal Ground
    CTS   Clear To Send       8 <--20       DTR   Data Terminal Ready
    RTS   Request To Send     7	--> 6       DSR   Data Set Ready   **
</verb></tscreen>

If you have a DB9 connector on both your serial port and terminal:
<tscreen><verb>
	PC DB9   			       Terminal DB9
    RxD   Receive Data        2 <-- 3	    TxD   Transmit Data
    TxD   Transmit Data       3 --> 2	    RxD   Receive Data
    SG    Signal Ground       5 --- 5 	    SG    Signal Ground
    CTS   Clear To Send       8 <-- 4       DTR   Data Terminal Ready
    RTS   Request To Send     7	--> 6       DSR   Data Set Ready   **
</verb></tscreen>

The above don't have modem control lines so be sure to give a "local"
option to getty (which is equivalent to "stty clocal").  Also if you
need hardware flow control it must be enabled at your computer (use a
-h flag with agetty) ( equivalent to "stty crtscts" ).

<sect2> Standard Null Modem cable pin-out (7 conductor)
<label id="null_modem_pinout">
<p> The following 3 diagrams show full "standard" null modem cables.
One that you purchase may be wired this way.  Another pinout is for 20
and 6 to cross over and to have 8 cross over to both 4 and 5.  This
will not provide hardware flow control (RTS/CTS) for directly
connected computers.   Both of the above will work for terminals using
software (Xon/Xoff) flow control (or no flow control).  None of these
cables will work for terminal hardware flow control since most real
terminals support DTR or DTR/DSR flow control (handshaking) but Linux
doesn't yet (2000).

<tscreen><verb>
PC male DB25     			Terminal DB25
DSR   Data Set Ready        6 <--|
DCD   Carrier Detect        8 <--|- 20    DTR   Data Terminal Ready
TxD   Transmit Data         2 ----> 3     RxD   Receive Data
RxD   Receive Data          3 <---- 2     TxD   Transmit Data
RTS   Request To Send       4 ----> 5     CTS   Clear To Send
CTS   Clear To Send         5 <---- 4     RTS   Request To Send
SG    Signal Ground         7 ----- 7     SG    Signal Ground
DTR   Data Terminal Ready  20 -|--> 8     DCD   Carrier Detect
                               |--> 6     DSR   Data Set Ready


</verb></tscreen>
<label id="DB_pin-out">
Alternatively, a full DB9-DB25 file-transfer (null-modem) cable (will
not work with terminal hardware handshaking; see above):

<tscreen><verb>
PC DB9      				Terminal DB25
RxD   Receive Data          2 <---- 2     TxD   Transmit Data
TxD   Transmit Data         3 ----> 3     RxD   Receive Data
                               |--> 6     DSR   Data Set Ready
DTR   Data Terminal Ready   4 -|--> 8     DCD   Carrier Detect
SG    Signal Ground         5 ----- 7     SG    Signal Ground
DCD   Carrier Detect        1 <--|
DSR   Data Set Ready        6 <--|- 20    DTR   Data Terminal Ready
RTS   Request To Send       7 ----> 5     CTS   Clear To Send
CTS   Clear To Send         8 <---- 4     RTS   Request To Send
RI   Ring Indicator        9 (not needed)
</verb></tscreen>
(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and
DB25 connectors!)

Here's how to connect two DB9's together (but DTR flow control will
not work):
<tscreen><verb>
PC DB9      				DB9
RxD   Receive Data          2 <----- 3     TxD   Transmit Data
TxD   Transmit Data         3 -----> 2     RxD   Receive Data
                                |--> 6     DSR   Data Set Ready
DTR   Data Terminal Ready   4 --|--> 1     DCD   Carrier Detect
GND   Signal Ground         5 ------ 5     GND   Signal Ground
DCD   Carrier Detect        1 <--|
DSR   Data Set Ready        6 <--|-- 4     DTR   Data Terminal Ready
RTS   Request To Send       7 -----> 8     CTS   Clear To Send
CTS   Clear To Send         8 <----- 7     RTS   Request To Send
RI   Ring Indicator         9 (not used)
</verb></tscreen>

Using the above 2 connections provide full modem control signals and
seemingly allow one to set "stty -clocal".  Then one must turn on the
terminal first (asserts DTR) before the port may be opened in a normal
manner by getty, etc.  But there is likely to be trouble if you fail
to turn on the terminal first (see <ref id="rapid_respawn" name="Getty
Respawning Too Rapidly">).  For this reason one should use "stty
clocal" which is the default (ignores modem control lines) and the
additional wires in these cables then serve no useful purpose.

In olden days when it may not have been this easy to ignore modem
control signals etc, the following "trick" was done for cables that
lacked conductors for modem control: on your computer side
of the connector, connect RTS and CTS together, and also connect DSR,
DCD and DTR together.  This way, when the computer needs a certain
handshaking signal to proceed, it will get it (falsely) from itself.

<sect2> Overcoming length limitations <label id="length_">
<p> A cable longer than a 50 feet or so may not work properly at high
speed.  Much longer lengths sometimes work OK, especially if the speed
is low and/or the cable is a special low-capacitance type and/or the
electronics of the receiving end are extra sensitive.  It is claimed
that under ideal conditions at 9600 baud, 1000 feet works OK.  One way
to cover long distances is to install 2@ line drivers near each serial
port so as to convert unbalanced to balanced (and conversely) and then
use twisted pair cabling.  But line drivers are expensive.

Another way to increase the distance is to try to cancel out much of
the magnetic field created by the currents in the transmit and receive
data wires: TxD and RxD.  To do this, ground return lines,  which have
current which is roughly equal (but in the opposite direction) are
placed next to the transmit and received wires.  Twisted pair has
the best cancellation.  Some DEC terminals have two signal ground
wires for this purpose.  For example, one pair would be TxD and
SG(TxD) where SG is signal ground.  If you use ribbon cable, insure
that the TxD and SG(TxD) wires are right next to each other.
Similarly for the RxD.

If there is only one signal ground wire provided by both the PC and
the terminal, it may be split into two wires in a twisted pair cable
for this purpose.  You might think that return currents will be
equally split between the two signal ground wires.  This would cancel
out only about half of the magnetic field.  But it's better
cancellation than this because return current prefers the path of
least impedance.  The return path of a data signal (such as TxD) has
the lowest impedance (due to lower inductance) if it flows back in the
same twisted pair.  Although I've haven't seen any experimental test
results for this method, it should allow longer cable lengths.

<sect2> Hardware Flow Control cables
<p> If you expect to use hardware flow control (handshaking) you will
likely need to make up your own cable (or order one made).  Of course,
if the connecters on the ends of a used cable remove, you might rewire
it.  See <ref id="db_conn_install" name="Installing DB Connectors">.
You will need to determine whether or not the terminal uses the
DTR pin for this, and if not, what pin (or pins) it uses.  The set-up
menus may give you a clue on this since there may be an option for
enabling "DTR handshaking" (or flow control) which of course implies
that it uses the DTR pin.  It may also use the DSR pin.  See <ref
id="hdw_flow_control" name="Hardware Flow Control"> for a detailed
explanation of it.  Older terminals may have no provision for hardware
flow control.

<sect2> Cable tips
<p> The normal "straight thru" cable will not work unless you are
using it as an extension cable in conjunction with either a null modem
(crossover or file-transfer) cable or a null modem adapter.  Make sure
that the connectors on the cable ends will mate with the connectors on
the hardware.  One may use telephone cable which is at least
4-conductor (and possibly twisted pair).  Shielded, special
low-capacitance cable computer cable is best.

<sect2> A kludge using twisted-pair cable <label
id="twist_pair_kludge">
<p> See also <ref id="length_" name="Overcoming Length Limitations">.
Although none of the EIA-232 signals are balanced for twisted pair
one may attempt to use twisted-pair cable with it.  Use one pair for
transmit and another for receive.  To do this connect signal ground to
one wire in each of these 2 pair.  Only part of the signal ground
current flows in the desired wire but it may help.  Due to the lower
inductance of the twisted pair circuit (as compared to ground return
current by some other path)  more return (ground) current will confine
itself to the desired twisted pair than one would expect from only
resistance calculations.  This is especially true at higher
frequencies since inductive impedance increases with frequency.  The
rectangular wave of the serial port contains high frequency harmonics.

<sect2> Cable grounding
<p> Pin 1 (of a DB25) should be chassis ground (also earth ground) but
on cheap serial ports it may not even be connected to anything.  A
9-pin connector doesn't even have a chassis ground.  The signal ground
is pin 7 and is usually grounded to chassis ground.  This means that
part of the signal current will flow thru the ground wires of the
building wiring (undesirable).  Cable shields are supposed to be only
grounded at one end of the cable, but it may be better to ground both
ends since it's better to have current in the shield than in the
building wiring ??

<sect1> Modem Connection

<p> By using a terminal-modem combination (without a computer) one may
dial out to other computers.  Up to the mid 1990s in the US, there
were many "bulletin boards" one could dial out to.  Some even provided
connections to the Internet.  But bulletin boards lost out in favor of
the Internet.

<sect2> Dialing out from a terminal
<p> Instead of connecting a terminal (or computer emulating a
terminal) directly to a host computer using a cable it may be
connected to the host via a telephone line (or dedicated private line)
with a modem at each end of the line.  The terminal (or computer) will
usually dial out on a phone line to a host computer.

Most people use a PC and modem for dialing out.  The PC could have a
terminal connected to a serial port and the person at the terminal
may dial out using the PC.   Connecting a real terminal directly to an
external modem is more difficult since the real terminal isn't very
intelligent and doesn't give as much feedback to the user.  For
dialing out, many terminals can store one or more telephone numbers as
messages which may be "set-up" into them and are sent out to the modem
by pressing certain function keys.  Many modems can also store phone
numbers.  The modem initiation sequence must precede the telephone
number.  When the outgoing call is answered by another modem at the
other end of the phone line, the host computer on this modem may
run a getty program to enable you to log in.

<sect2> Terminal gets dialed into
<p> It's common for a computer running Linux to get dialed into.  The
caller gets a login prompt and logs in.  At first glance, it may seem
strange how a dumb terminal (not connected to any computer) could
accept an incoming call, but it can.  One possible reason for doing
this is to save on phone bills where rates are not symmetric.  Your
terminal needs to be set up for dial-in: Set the modem at your
terminal for automatic answer (Register S0 set to 2 will answer on the
2nd ring).  You turn on the terminal and modem before you expect a
call and when the call comes in you get a login prompt and log in.

The host computer that dials out to your terminal needs to do
something quite unusual.  As soon as your modem answers, it needs to
run login (getty).   A host may do this by running the Linux program
"callback" sometimes named "cb".  Callback is for having computer A
call computer B, and then B hangs up and calls A back.  This is what
you want if you are using computer A to emulate a terminal.  For the
case of a real terminal this may be too complex a task so the host may
utilize only the "back" part of the callback program.  The setup file
for callback must be properly configured at the host.  Callback makes
the call to the terminal and then has mgetty run a login on that port.
Mgetty by itself (as of early 1998) is only for dial-in calls but
there is work being done to incorporate callback features into it and
thus make it able to dial-out.  As of early 1999 it didn't seem to have
been done.

<sect1> Telnet and ssh
<p>Telnet is a program which lets a text terminal (or a PC console)
connect to a host computer over a network.  No serial ports are used
for the telnet connection.  Of course if you are sitting at a real
text terminal there is a serial connection to your own host.  But when
you run telnet, your host connects to another host via serial-less
telnet.

Telnet uses tcp/ip packets over various networks: the Internet, LANs,
etc.  You run telnet (as a client) and it connects to a telnet server
on another computer on a network.  Then you get a login prompt and log
in just as if you were directly connected via a cable to a serial
port.

Ssh is "Secure Shell" and is like telnet.  At one time it was much
more secure than the conventional telnet which sent passwords in the
clear (no encoding).  But now (2006) there are packages "telnet-ssl"
which offer secure telnet.  But since telnet was slow in introducing
security, ssh may have become more popular.

Telnet may put each character you type inside a packet and naturally
there's a lot of overhead with this.  But there's an option for sending
one line at a time.  To use telnet as a client, you need to have an
account on another computer on that runs a telnet server.  Then you
give the telnet command and specify the address of the computer that
will accept a connection from you.

What kind of terminal does telnet emulate?  It doesn't.  Instead, it
connects you to a remote computer using whatever kind of terminal you
are currently using.  If you're on a Linux console, it's a terminal of
type Linux.  The remote computer needs to somehow find out what type
of terminal you're on so it can send the correct escape sequences.

So using telnet is much like connecting up a dumb terminal to a serial
port except that instead of a cable between you and the computer,
there is a stream of packets flowing over the Internet between you and
some distant computer.

<sect1> Terminal Server Connection
<sect2> What is a terminal server ?
<p> A terminal server is something that serves to connect a bunch of
terminals to a host computer(s) via a network.  Today this server is
often located nearby or inside the host computer.  If you directly
connect some terminals to a PC or connect them via dial-up modems thru
serial ports at each end, you don't need a terminal server.

But if the terminals are connected to the host over a network, then
you may need a terminal server to make the serial-to-network
conversions.  This is useful for devices such as printers and
terminals that have no built-in network support.  However the
definition of "terminal server" has broadened to the case where all
data flows entirely over a network (except of course within the
computer itself) and where no serial ports are involved.  The term
"terminal" may include a thin client type terminal with a GUI.  The
network usually uses tcp/ip and/or ppp but other protocols (including
protocol conversion) are sometimes supported.

One way to connect a "terminal" (your PC console) to a network is to
run telnet on your PC (assuming your PC has a network connection).  At
one time, terminal servers were dedicated hardware which could be used
only as terminal servers.  Today a PC can simultaneously serve as a
terminal server, thereby serving many terminals.

Today, most terminal servers serve thin client terminals rather than
text-terminals.  The "Linux Terminal Server Project" is an example. 
But it can also serve text terminals using telnet.  Such a text-terminal
is likely to be just a PC monitor emulating a terminal of type
"Linux".  The terminal server is just software running on the host
computer.  Telnet server software is like a simple terminal server.

A host that only has directly connected terminals (or modem
connections without tcp/ip or ppp) is sometimes called a "terminal
server".  Although it's doing the same job as a real terminal server,
it strictly speaking is not a terminal server. 

<sect2> Evolution of the "terminal server"
<p>Originally a terminal server served real text-terminals via the
serial port.  A server for real text-terminals would have a number of
serial ports.  The user would log in to the server and then get
connected via tcp/ip, etc. to a host computer where s/he would login a
second time again.  Sometimes the first login would be automatic, or
perhaps there would be a choice given the user as to what host
computer (or printer) to connect to (or what protocol to use).

The use of real text-terminals declined as the PC replaced mainframes.
But the PC could emulate a terminal (using say minicom (Linux) or
(hyper)terminal for MS).   One could could then dial-out via a modem
to a bulletin-board or the like.  There would be a bank of modems to
accept such calls and each modem would be connected to a serial port.
The serial port could either be on a multiport card or on a dedicated
terminal server.  Note that in both the above cases there is no client
software.  It's not a client-server model.

When the Internet became popular, one would run the PPP protocol on
the phone line and still go thru a modem and "terminal server" at the
ISP.  This server would handle PPP and ultimately connect one to the
Internet.  But the PC was no longer emulating a text terminal since
browser images were being displayed.  Today with ISPs getting only
digital signals from the phone company, they don't need real modems
anymore.  So what was once a "terminal server" evolved into a "remote
access server".  It's infrequently been called a "digital terminal
server".  Note that 56k modem service requires that an ISP have a
digital connection to the phone company.

With remote access servers, instead of many individual telephone line
cables connected to a terminal server, one now finds just a few cables
with many digitized telephone calls on each cable (multiplexed).  The
multitude of connectors needed for large numbers of terminals or
modems is no longer present on a remote access server and thus the
successor to this type of terminal server can't readily serve
text-terminals anymore.

More recently with the advent of thin clients terminals, the term
"terminal server" was revived to apply to the hosts that served the
thin clients.  Both MS Windows and Linux can serve thin clients.

<sect1> Connector and Adapter Types
<p> A connector is more-or-less permanently attached to the end of a
cable or to a hardware unit.  There are two basic types of connectors
used in serial communications: 1. DB types with pins (DB 9 or DB25) and 2.
modular telephone-style connectors.

An adapter looks about like a connector but it has two ends with pins.
It is just like a cable that is so short that there is no cable part
left at all --just different connectors on each end is all that
remains.  The adapter just plugs in to two other connectors on each side
of it.  It allows two incompatible connectors to mate with each other
by going in between them.  Except that even for two connectors that
will mate with each other, an adapter may be used to connect the cable
conductors together in other than straight-thru.  Obviously, one may
use a special cable (perhaps homemade) as a substitute for an adapter.

<sect2> Sex of connector/adapters
<p> Connectors (or one side of adapters) are either male or female.
The connectors that have pins are male and the ones that have sockets
(sometimes also called pins) are female.  For modular connectors, the
ones with exposed contacts are plugs while the ones with internal
contacts (not easy to see) are jacks.  Plugs are male; jacks are
female.

<sect2> Types of adapters
<p> There are three basic types of adapters: null modem, gender
changers and port adapters.  Some adapters perform more than one of
these three functions.
<itemize>
<item> null modem adapter: Reroutes wires, like a null modem cable.
<item> gender changer: Changes the sex of a cable end.  Two connectors
 of the same sex can now connect (mate) with each other.
<item> port adapter: Goes from one type of connector to another (DB9
 to DB 25, etc.)
</itemize>

<sect2> DB connectors <label id="db_conn">
<p> (For how to install a DB connector on the ends of a cable see <ref
id="db_conn_install" name="Installing DB Connectors">.)  These come in
9 or 25 pins.  The EIA-232 specs. call for 25 pins but since most of
these pins are not used on ordinary serial ports, 9 pins is
sufficient. See <ref id="DB_pin-out" name="DB9-DB25"> for the pin-out.
The pins are usually numbered if you look closely enough or use a
magnifying glass.

<sect2> RJ modular connectors <label id="rj_conn">
<p> RJ means Registered Jack.  These look like modern telephone
connectors but are sometimes not compatible with telephone connectors.
See also <ref id="rj_conn_install" name="Installing RJ Connectors">.
For use with serial ports they may be 6 or 8 conductor.  A few are
10-conductor but may not officially belong to the RJ series.

<sect3> 6-conductors: RJ11/14, RJ12,  and MMJ
<p> RJ11 are all the same size but may have  2, 4, or 6 conductors.
If it has two conductors, it should be called a RJ11.  If it has 4
conductors, some call it a RJ14.  If it has 6 conductors, many call it
a RJ12 (but a RJ12 per the phone company has only 4 conductors).
Seems confusing but they are all the same size and differ mainly by
the number of conductor contacts present.

A look-alike (almost) is a MMJ connector (6-conductor) used on later
model VT (and other) terminals.  It's sometimes referred to as a
DEC-423 or a DEC RJ11.  MMJ has an offset tab and is not compatible
with RJ ones (unless the tab is cut off).  However, some connectors
have been made that are compatible with both MMJ and the RJ ones.
Since MMJ connectors are both hard to find and may be expensive some
people have forced a RJ (6 conductor) to fit MMJ by filing off the
offset tab with a file.

The MMJ (DEC) pinout is: 1-DTR, 2-TxD, 3-TxD_Gnd, 4-RxD_Gnd, 5-RxD,
6-DSR.  Cyclades Cyclom-8Ys RJ12 has: 1-DTR, 2-TxD, 3-Gnd, 4-CTS,
5-RxD, 6-DCD.  Specialix IO8+ has: 1-DCD, 2-RxD, 3-DTR/RTS, 4-Gnd,
5-TxD, 6-CTS.  The pins of the RJ (and MMJ) are numbered similar to
the RJ45.

<tscreen><verb>
       Plug                         Jack (or socket)
  (Looking at the end           (Looking at the cavity
   end of a cable)               in a wall or PC back)
     .________.                       .________.
     | 654321 |                       | 123456 |
     |__.  .__|                       |__.  .__|
        |__|                             |__|
</verb></tscreen>

A standard MMJ file-transfer (null-modem) cable has a MMJ connector at
each end.  It connects to the PC using a MMJ-to-DB adapter.  This
adapter plugs into a DB (say 25 pin) connector on the back of the PC
and the MMJ connecter plugs into it.  If you don't have such an
adapter, you can make a custom cable with a MMJ (or filed RJ)
connector on one end and a DB connector on the other end.

The standard file-transfer (null-modem) cable with two MMJ (or
RJ11/14) connectors will connect: 1-6, 2-5, and 3-4.  Note that such a
cable supports DTR/DSR flow control which is not supported (yet) by
Linux.  Making up your own standard 6-conductor file-transfer cable is
very simple if you understand that the ordinary 4-conductor telephone
cable from the wall to your telephone, used in hundreds of millions of
homes, is also a file-transfer cable.  Find one and wire your cable the
same way.

If you lay such a cable flat on the floor (with no twists) you will
note that both plugs on the ends have their gold contacts facing up
(or both facing down).  Although it's symmetrical, it is also
file-transfer if you think about it a bit.  One may put a few such
cables together with inline couplers and everything works OK because
each inline coupler is also a file-transfer (null-modem) adapter.  Two
file-transfer cables in series result in a straight-thru connection.

Here's a custom cable diagram (by Mark Gleaves) for connecting MMJ to
a 9-pin serial port using RTS/CTS flow control:
<tscreen><verb>
  DEC MMJ                            Linux PC DB9
Pin  Signal                           Signal  Pin
===  ======                           ======  ===
 1    DTR -----------------------|---> DSR     6
				 |---> CTS     8
 2    TxD ---------------------------> RxD     2
 3    SG (TxD)--------------------|--- SG      5
 4    SG (RxD)--------------------|
 5    RxD <--------------------------- TxD     3
 6    DSR <-----------------------|--- RTS     7
				  |--> DTR     4
				  |--> CD      1
		       (no connection) RI      9
</verb></tscreen>
<sect3> 8-conductors and 10-conductors
<p> RJ45 and RJ48 are 8-conductor modular telephone plugs.
There exists some 10-conductor connectors which are allegedly wider
and will not mate with the 8-conductor ones.  People have called the
10-conductor ones RJ45 and/or RJ48 but this may be incorrect.  These
connectors are used for both flat telephone cable and round twisted
pair cable.  The cable end of the connector may be different for round
and flat cable.  RJ48 has an extra tab so that a RJ48 plug will not
push into a RJ45 jack (but a RJ45 plug will mate with a RJ48 jack).
They're used on some multiport serial cards and networks.  Heres the
pin numbers for an 8-conductor:

<tscreen><verb>
  Plug                          Jack (or socket)
  (Looking at the end           (Looking at the cavity
   end of a cable)               in a wall)
     .__________.                   .__________.
     | 87654321 |                   | 12345678 |
     |__.    .__|                   |__.    .__|
        |____|                         |____|
</verb></tscreen>

<sect1> Making or Modifying a Cable
<sect2> Buy or make ? <label id="buy_or_make_cable">
<p> You may try to buy a short, null modem cable.  Just a "modem
cable" will not work.  Null modem cables were once labeled as "serial
printer" cables but serial printers are not popular today (2004).
They also may be labeled as "file-transfer" cables or "PC-to-PC"
cables.  Hardware flow control will work on them for PC-to-PC
connections (terminal emulation) but not for the DTR flow control used
by most real text terminals.  If Linux supported DTR flow control,
real terminals would work OK .  Make sure the connectors on the cable
ends will fit the connectors on your computer and terminal.

But if you need longer cables to connect up terminals or need hardware
flow control, how do you get the right cables?  The right ready-made
cables may be difficult to find (you might find them by searching the
Internet), especially if you want to use a minimum (say 4) of
conductors.  One option is to get them custom made, which is likely to
be fairly expensive although you might find someone to make them at
prices not too much higher than ready-made cable (I did).

A low-cost alternative is to buy used cables (if you can find them).
If you get a used terminal, ask if they have a cable for it.  Another
alternative is to make your own.  Even if you get used cables, they
may need some changes to the pin wiring.  In either case, this may
require special tools.  Most connectors that come with short cables
are permanently molded to the cable and can't be rewired but most
custom-made and homemade cables have connectors that can be rewired.
One advantage of making your own cable is that the skills you learn
will come in handy if a cable breaks (or goes bad) or if you need to
make up another cable in a hurry.

<sect2> Pin numbers of 9 and 25 pin connectors
<p> The pin numbers are often engraved in the plastic of the
connector but you may need a magnifying glass to read them.
Note DCD is sometimes labeled CD.  The numbering of the pins on a
female connector is read from right to left, starting with 1 in the
upper right corner (instead of 1 in the upper left corner for the male
connector as shown below).  --> direction is out of PC.

<tscreen><verb>
  ___________                    ________________________________________
  \1 2 3 4 5/  Looking at pins   \1  2  3  4  5  6  7  8  9  10 11 12 13/
   \6 7 8 9/  on male connector   \14 15 16 17 18 19 20 21 22 23 24 25/
    ------                         -----------------------------------
</verb></tscreen>

<sect2>	Installing DB connectors on cable ends <label id="db_conn_install">
<p> See <ref id="db_conn" name="DB Connectors"> for a brief description
of them.  Unfortunately, most cables one purchases today have molded
connectors on each end and can't be modified.  Others have connectors
which unscrew and can be rewired.  If you are making up cable or
modifying an existing one then you need to know about pins.  There are
two types: soldered and crimped.

The crimped pins require a special crimping tool and also need an
"insertion/extraction" tool.  But once you have these tools, making up
and modifying cable may be faster than soldering.  If you are
connecting two wires to one pin (also needed if you want to jumper one
connected pin to another pin) then soldering is faster (for these
pins).  This is because the crimped pins can only take one wire each
while the soldered ones can accept more than one wire per pin.

To insert crimped pins just push them in by hand or with the insertion
tool.  Using the tool for either insertion of removal first requires
putting the tool tip around the wire.  The tool tip should completely
encircle the wire at the back of the pin.

Removing a pin with this tool is a little tricky.  These directions
can be best understood if you have both the tool and wires in front of
you as you read this.  With the tool tip around the wire insert the
tool as far as it will go into the hole (about 1 1/2 cm.  Some tools
have a mark (such as a tiny hole) on them to indicate how far to
insert it.  The tool tip should have a tapered gap so that you may get
the tip around the wire by starting it in where the gap is wider than
the wire.  The tool may have 2 tips.  The one that is the most
difficult to get around the wire is also the one that removes the wire
the easiest since it almost completely envelops the wire.

With the tip properly inserted pull on both the tool and the wire
with a gentle pull.  If it doesn't come out, the tool was likely not
inserted correctly so either push it in more or twist it to a
different position (or both).   Perhaps you should have used another
tip that fits tighter around the pin.  Using this tool, one may
readily convert a straight-thru cable to a file-transfer (null-modem)
cable, etc.

There can be problems using the "insertion/extraction" tool.  If the
tools will not insert on the back of the pin, it could be that the pin
was not neatly crimped to the wire and is sort of square where it
should be round, etc.  If a pin starts to come out but will not pull
out all the way, the pin may be bent.  Look at it under a magnifying
glass.  Straightening a pin with needle-nose pliers may damage the
gold plating but you may have to straighten it to remove it.
Sometimes a stuck pin may be pushed out with a thick screwdriver blade
tip (or the like) but if you push too hard you may gouge the plastic
hole or bend the pin:.

Don't try soldering unless you know what you're doing or have read
about how to do it.

<sect2>	Installing RJ connectors <label id="rj_conn_install">
<p> These are telephone modular connecters one type of which is used
for most ordinary telephones.  But there are many different types (see
<ref id="rj_conn" name="RJ Modular Connectors">).

These are not easy to reuse.  You might be able to pull the wires out,
push in something wedged that would lift up the gold-colored contacts
and reuse the connector.  There are special crimping tools used to
install them; a different tool for each type.

If you don't have a crimping tool, installation is still possible (but
difficult) using a small screwdriver (and possibly a hammer).  Push in
the cable wires and then push each gold-colored contact down hard with
a small screwdriver that will just fit between the insulating ridges
between the contacts.  You may damage it if you fail to use a
screwdriver with a head almost the same thickness as the contacts or
if the screwdriver slips off the contact as you are pushing it down.
You may also use a small hammer to pound on the screwdriver (push
first by hand).

Be sure to not hurt the "remove lever" on the connecter when you push
in the contacts.  Don't just set it down on a table and push in the
contacts.  Instead, put a shim (about 1 mm thick) that fits snugly
in the crevice between the lever and the body.  For such a shim you
may use thick cardboard, several calling cards, or wood.  Since the
bottom of the connector (that you will put on the table) isn't level
(due to the "remove lever), make sure that the table top has something
a little soft on it (like a sheet of cardboard) to help support the
non-level connector.  Even better would be to put another 1mm shim
under the first 6mm of the connector, supporting it just under where
you see the contacts.  A soft tabletop wouldn't hurt either.  Another
method (I've never done this) is to hold the connector in a vice but
be careful not to break the connector.

As compared to using a crimping tool, installing it per above takes a
lot longer and is much more prone to errors and failure but it's sometimes
more expedient and a lot cheaper than buying a special tool if you
only have one or two connectors to install.

<sect> Set-Up (Configure) in General <label id="setup_">

<sect1> Intro to Set-Up
<p> Configuring (Set-Up) involves both storing a configuration in the
non-volatile memory of the terminal, and putting commands in start-up
files (on your hard disk) that will run each time the computer is
powered on (or possibly only when the run-level changes).  This
section gives an overview of configuring and covers the configuring of
the essential communication options for both the terminal and the
computer.  The next two major sections cover in detail the
configuration of the terminal (see <ref id="term_conf_details"
name="Terminal Set-Up"> and the computer (see <ref  id="comp_conf_details"
name="Computer Set-Up (Configure) Details">.

<sect1> Terminal Set-Up (Configure) Overview <label id="term_conf_ov">
<p> When a terminal is installed it's necessary to configure the
physical terminal by saving (in its non-volatile memory which is not
lost when the terminal is powered off) the characteristics it will
have when it is powered on.  You might be lucky and have a terminal
that has already been set-up correctly for your installation so that
little or no terminal configuration is required.

There are two basic ways of configuring a terminal.  One is to sit at
the terminal and go thru a series of set-up menus.  Another is to send
escape sequences to it from the host computer.  Before you can send
anything to the terminal (such as the above escape sequences), its
<ref id="commun_config" name="Communication Interface"> options such
as the baud rate must be set up to match those of the computer.  This
can only be done by sitting at the terminal since the communications
must be set up right before the computer and the terminal can "talk"
to each other.  See <ref id="term_conf_details" name="Terminal
Set-Up">.

<sect1> Computer Set-Up (Configure) Overview
<p> Besides possibly sending escape sequences from the computer to
configure the terminal, there is the configuring of the computer
itself to handle the terminal.  If you're lucky, all you need to do is
to put a "getty" command in the /etc/inittab file so that a "login:"
prompt will be sent to the terminal when the computer starts up.  See
the section <ref id="getty_" name="Getty (used in /etc/inittab)"> for
details.

The computer communicates with the terminal using the serial device
driver software (part of the kernel).  The serial device driver has a
default configuration and is also partly (sometimes fully) configured
by the getty program before running "login" at each terminal.
However, additional configuration is sometimes needed using programs
named "stty" and "setserial".  These programs (if needed) must be run
each time the computer starts up since this configuration is lost each
time the computer powers down.  See <ref id="comp_conf_details"
name="Computer Set-Up (Configure) Details">.

<sect1> Many Options
<p> There are a great many configuration options for you to choose
from.  The communication options must be set right or the terminal
will not work at all.  Other options may be set wrong, but will cause no
problem since the features they set may not be used.  For example, if
you don't have a printer connected to the terminal it makes no
difference how the printer configuration parameters are set inside the
terminal.  This last statement is not 100% correct.  Suppose that you
have no printer but the computer (by mistake) sends the terminal a
command to redirect all characters (data) from the computer to the
printer only.  Then nothing will display on the screen and your
terminal will be dead.  Some terminals have a configuration option to
inform the terminal that no printer is attached.  In this case the
terminal will ignore any command to redirect output to the "printer"
and the above problem will never happen.  However, this doesn't help
much since there are many other erroneous commands that can be sent to
your terminal that will really foul things up.  This is likely to
happen if you send the terminal a binary file by accident.

In some cases a wrong setting will not cause any problem until you
happen to run a rare application program that expects the terminal to
be set a certain way.  Other options govern only the appearance of the
display and the terminal will work fine if they are set wrong but may
not be as pleasant to look at.

Some options concern only the terminal and do not need to be set at
the computer.  For example: Do you want black letters on a light
background?  This is easier on the eyes than a black background.
Should a key repeat when held down?  Should the screen wrap when a
line runs off the right end of the screen?  Should keys click?

<sect1> Communication Interface Options <label id="commun_config">
<p> Some of these communication settings (options) are for both the
terminal and the computer and they must be set exactly the same for
both: speed, parity, bits/character, and flow control.  Other
communication options are only set at the terminal (and only a couple
of these are essential to establish communications).  Still others
such as the address and interrupt (IRQ) of the physical port ttyS2 are
set only at the computer using the "setserial" command.  Until all of
the above essential options are compatibly set up there can be no
satisfactory serial communication (and likely no communication at all)
between the terminal and the computer.  For the terminal, one must set
these options manually by menus at each terminal (or by using some sort
of special cartridge at each terminal).  The host computer is
configured by running commands each time the computer is powered up
(or when people log in).  Sometimes the getty program (found in the
/etc/inittab file) which starts the login process will take care of
this for the computer.  See <ref id="getty_" name="Getty (used in
/etc/inittab)">

The settings for both the computer and the terminal are:
<itemize>
<item> <ref id="speed" name="Speed (bits/second) ">
<item> <ref id="parity_" name="Parity">
<item> <ref id="ch_size" name="Bits per Character ">
<item> <ref id="flow_control" name="Flow Control ">
</itemize>

Some essential settings for the terminal alone are:
<itemize>
<item> <ref id="port_select" name="Port Select">
<item> Set communication to full duplex (=FDX on Wyse terminals)
</itemize>

If the  <ref id="getty_" name="Getty (used in /etc/inittab)"> program
can't set up the computer side the way you want, then you may need to
use one (or both) of the <ref id="stty_setserial" name="Stty &
Setserial"> commands.

<sect2> Speed <label id="speed">
<p> These must be set the same on both the terminal and the computer.
The speed is the bits/sec (bps or baud rate).  Use the highest speed
that works without errors.  Enabling flow control may make higher
speeds possible.  There may be two speeds to set at the terminal:
Transmit and Receive, sometimes abbreviated T and R.  Usually they are
both set the same since stty in Linux doesn't seem to have the option
yet of setting them differently.  (There is an option to do this with
the "stty" command but it seems to actually set them both the same.)
Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ...
The slower speeds (like 600) are for printers and hard-copy terminals.

<sect2> Parity & should you use it ? <label id="parity_">
<p> For a definition see <ref id="parity_def" name="Parity Explained">.
Parity-disabled is often the default.  To enable parity, you must both
enable it and then select either even or odd parity.  It probably
makes no difference if it's odd or even.  For terminals there are
sometimes settings for both transmit and receive parity.  You should
set both of these the same since stty at the computer doesn't permit
setting them differently.  The PC serial port usually can't support
different parities either.  Some terminal are unable to set receive
parity and will simply always ignore received parity bits.  On some
older terminals if you use 8-data-bits per byte then parity will not
work since there is no room in the hardware for the extra parity bit.

Should you use parity  at all?  Parity, while not really necessary, is
nice to have.  If you don't have parity, then you may get an incorrect
letter here and there and wind up trying to correct spelling errors
that don't really exist.  However parity comes at a cost.  First, it's
more complicated to set up since the default is usually no parity.
Secondly, parity will slow down the speed with which bytes travel over
the serial cable since there will be one more bit per byte.  This may
or may not slow down the effective speed.

For example, a hard-copy terminal is usually limited by the mechanics
of the printing process.  Increasing the bytes/sec when the computer
(its UART chip) is transmitting only results in more flow-control
"halt" signals to allow the mechanical printing to catch up.  Due to
more flow-control waits the effective speed is no better without
parity than with it.  The situation is similar for some terminals:
After you implement parity there may be fewer flow-control waits per
unit time resulting in more bits/sec (average).  However, due to the
added parity bits the bytes/sec (average) stays the same.

One option is to install terminals with no parity.  Then if parity
errors are noticed, it can be implemented later.  To spot possible
errors with no parity, look for any spelling errors you don't think
you made.  If you spot such an error, refresh the screen (retransmit
from the computer).  If the error goes away, then it's likely a parity
error.  If too many such errors happen (such as more than one every
few hundred screens) then corrective action is needed such as:  Enable
parity and/or reduce speed, and/or use a shorter/better cable.
Enabling parity will not reduce the number of errors but it will tell
you when an error has happened.

Just the opposite policy is to initially enable parity.  Then if no
parity errors (error symbols on the CRT) are ever seen (over a
reasonable period of time, say a month or two) it may be safely
disabled.

<sect2> Bits/Character <label id="ch_size">

<p> This is the character size (the number of data bits per character
excluding any parity bit).  To use international character sets you
need 8 bits.  But it's not of much use unless your terminal has the
fonts for them.  See <ref id="char_sets" name="Character-Sets"> If you
are only going to use ASCII characters, then select 7-bits since it's
faster to transmit 7 bits than 8.  Some very old terminals only
support 7-bit characters.


<sect2> Which Flow Control (Handshaking) ?

<p> The choice is between "hardware" (for example  dtr/cts)
or "software" (Xon/Xoff) flow control.  While hardware flow control
may be faster (if the one or two extra wires for it are available in
the cable and if the terminal supports it) in most cases Xon/Xoff
should work OK.  Some people report that they solved disturbing
problems (see below) by converting to hardware flow control but
software flow control has worked fine at other installations (and for
me personally).

If you use software (Xon/Xoff) flow control and have users who don't
know about it, then they may accidentally send an Xoff to the host and
lock up their terminal.  While it's locked, they may type frantically
in a vain attempt to unlock it.  Then when Xon is finally sent to
restore communication, all that was typed in haste gets executed,
perhaps with unexpected results.  They can't do this with hardware
flow control.  See <ref id="flow_control" name="Flow Control"> for an
explanation of flow control.

<sect2> Port select <label id="port_select">
<p> Since most terminals have two or more connectors on the back, it
is usually possible to assign one of these connecters to connect to
the host computer and assign another connector to be the printer port.
The connector may have a name next to it (inspect it) and this name
(such as Aux, Serial 2, or Modem) may be assigned to either be the
main host connection or the printer connection (or the like).

<sect1> Quick Attempt
<p> While all the above may seem overly complex, to get a terminal
working is often fairly simple.  The <ref id="quick_install"
name="Quick Install"> section describes a simple way to try to do
this.  But if that doesn't work or if you want to make the display
look better and perform better, more reading will be needed.

<sect> Terminal Set-Up (Configure) Details <label id="term_conf_details">

<p> Except for the next subsection on sending escape sequences to the
terminal, this section mainly presents the details of setting up the
terminal manually by sitting at the terminal and going thru menus.  If
you haven't already done so, you should read <ref id="term_conf_ov"
name="Terminal Set-Up (Configure) Overview">.  It's best if you have a
terminal manual, but even it you don't there is information here on
many of the options which you might possibly need to set.

The communication parameters such as its baud rate must always be set
up at the terminal since if this is not done there can be no
communication with the terminal.   Once communication is established
you have two choices for doing the rest of the terminal configuration.
You may continue to configure manually at the terminal and save the
results in the terminal's non-volatile memory or you may do this by
sending escape sequences to the terminal from the computer each time
the terminal is powered on (or the like).

If you know how to set up and save a good configuration inside the
terminal it may be the best way.  If you don't, you might want to just
send the init string from terminfo to your terminal each time you use
the terminal.  Perhaps doing nothing will still give you a usable
terminal.  You (or an application program) can always change
things by sending certain escape sequences to the terminal.

<sect1> Send Escape Sequences to the Terminal
<p> Once the communication interface is established, the rest of the
configuration of the terminals may sometimes be done by sending
escape sequences to the terminals from the computer.  If you have a
large number of terminals, it may be worthwhile to write (or locate) a
shell script to automatically do this.  There may (or may not) be a
command you can send to a terminal to tell it to save its current
set-up in its non-volatile memory so that it will be present the next
time the terminal is powered on.

There is an simple way to send these escape sequences and a complex
way.  Using the simple way, you never look up escape sequences but
issue commands that automatically find an appropriate escape sequence
in the terminfo database and send that.  Unfortunately, not all the
escape sequences which you might want to send are always in the
terminfo database.  Thus the more complex (but possibly better) way is
to directly send escape sequences.

For this complex method you'll need an advanced manual.  Old terminal
manuals once included a detailed list of escape sequences but newer
ones usually don't.  To find them you may need to purchase another
manual called the "programmers manual" (or the like) which is not
supplied with the terminal.  A <ref id="esc_seq_lists" name="Esc
Sequence List"> for some terminals is on the Internet but it's terse
and likely incomplete.

Even without a manual or the like, you may still send commands to
configure the terminal by using the programs "tput" and "setterm".
See <ref id="term_settings" name="Changing the Terminal Settings">.
You could just send the terminal an init string from the terminfo
entry if the init string sets up the terminal the way want it.  See
<ref id="init_string" name="Init String">.  Unless you plan to have
these sequences sent from the computer to the terminal each time the
terminal is powered on, you must somehow save the settings in the
non-volatile memory of the terminal.

<sect1> Older Terminals Set-Up
<p> On older terminals look at the keyboard for labels just above the
top row of numeric keys.  If they exist, these labels may be what
these keys do in set-up mode.  Some older terminals may have only one
"set-up" menu.  Still older ones have physical switches.  In some
cases not all the switches are well labeled but they may be well
concealed.  Of course, if you set something with a switch, it's
"saved" and there is no need to save the setting in non-volatile
memory.

<sect1> Getting Into Set-Up (Configuration) Mode <label id="enter_setup">
<p> To select options (configure) at the terminal, you must first
enter "set-up" mode and then select options (i.e. configure) using
menus stored inside the terminal and displayed on the screen.  To do
this, the terminal does not even need to be connected to a computer.
How to get into set-up mode is covered in the terminal's manual, but
here's some hints that may help:

If there's a "set-up" key try pressing it.  Also try it shifted.
<itemize>
<item> Wyse: First try the shifted "Select" key; then substitute
 Ctrl for shifted in all of the above.
<item> VT, Dorio: F3 may be the set-up key.  On VT420 and later models
 this key may have been programmed to do something else so turn off the
 power.  When you turn on the power again, hit the F3 key as soon as
 you get an initial screen message.
<item> IBM: 3151: Ctrl-ScrollLock.  3153: Ctrl-Minus_on_Keypad (or
 like 3151)
</itemize>

To move around in the set-up menus, try the arrow keys.  Use Return,
Space, or a special key ("toggle" on old terminals) to select.
To exit set-up mode select exit from a menu (or on some older
terminals press the set-up key again).

<sect1> Communication Options
<p> For the terminal to work at all, speed, parity, :its/character,
and communication mode must be set correctly.  Incorrect flow control
may cause loss and/or corruption of data seen on the screen. The
essential communication options were dealt with (for both the terminal
and computer) in another section:  See <ref id="commun_config"
name="Communication Interface">.  The following list provides some
links to that section, as well as some additional communication
options set only at the terminal.

<itemize>
<item> <ref id="speed" name="Speed (bits/second) ">
 (baud rate): 9600, 19200, etc.
<item> <ref id="parity_" name="Parity"> none, even, odd, mark, space
<item> <ref id="ch_size" name="Bits per Character "> {Data}: 7 or 8
<item> <ref id="flow_control" name="Flow Control:"> or Handshake
 {Hndshk}: none, Xon-Xoff, or hardware (DTR, etc).
  <itemize>
  <item> Receiver Handshake {Rcv Hndshk} protects data being Received
   by the terminal by transmitting flow-control signals to the host.
  <item> Transmitter Handshake {Xmt Hndshk} is protection of data being
   Transmitted by the terminal.   The terminal receives flow-control
   signals (and locks/unlocks the keyboard).  Includes "Incoming Xon/Xoff".
  </itemize>
<item> number of stop bits: 1 or 2. See <ref id="byte_seq" name=
 "Voltage Sequence for a Byte">
<item> Flow control level {Rcv Hndshk Level} {{Xoff at ...}}: Flow
 control will send "stop" when this number of bytes in the terminal's
 buffer is exceeded.
<item> <ref id="half_duplex" name="Communication Mode"> {Comm}: <ref
 id="half_duplex" name="Full Duplex {FDX}, Half Duplex {HDX}"> {{Local
 Echo}}, <ref id="local_mode" name="Local Mode"> {{Online/Local}}
<item> Transmit Rate (Speed) Limit {Xmt Lim}: limits the transmit rate
 to the specified cps (chars/sec) even though the baud rate setting may
 be at a higher speed.
<item> Function-Key Rate Limit: as above but for function key
 messages.
<item> <ref id="port_select" name="Port Select">: Which physical connecter
 is for the host {Host Port} ?
</itemize>

<sect1> Saving the Set-up
<p> Your set-up must be saved in the non-volatile memory of the
terminal so that it will be effective the next time you turn on the
terminal.  If you fail to save it, then the new settings will be lost
when you turn off the terminal.  Before you go to the trouble of
setting up a terminal, make sure that you know how to save the
settings.  For modern terminals the save command is done via a menu.
In some older terminals, only the manual tells how to save.  For many
of these you press Ctrl-S to save.

<sect1> Set-Up Options/Parameters <label id="set_up_pars">

<p> What follows in this section describes some of the options which are
available in the set-up menus of many terminals.  Options are also
called parameters or features.  Many options may be called "modes".
Setting options is often called "configuring".  Many of these options
may also be set by sending certain escape sequences to the terminal.
Different models and brands of terminals have various options and the
same option may be called by different names (not all of which are
given here) Terse names used by Wyse are enclosed in {...}.  Names
used mostly for VT terminals are enclosed in {{...}}.

<sect1> Emulation {Personality} {{Terminal Modes}}
<p> Most modern terminals can emulate several other terminals.  The
terminal can likely do more if it is set to emulate itself (actually
no emulation) {native personality}.   Sometimes there are 2 different
emulations for the same model of terminal.  For example VT220-7
emulates a VT220 with 7-bits/byte while VT220-8 emulates a VT220 with
8-bits/byte (256 possible characters).

Older models of terminals usually have fewer features than newer
models.  Suppose one wanted to emulate an old terminal but also wanted
some of the advanced capabilities of the later model terminal they are
sitting at.  This is sometimes possible (to some degree).  This
feature is sometimes called {Enhance} (or Enhanced ??).

<sect1> Display Options
<sect2> Character Cell Size {Char Cell}
<p> This is the size of the cell in which a character fits.  It is
measured in pixels (=tiny dots).  The more dots, the better the
resolution.   10x16 is 10 dots wide by 16 dots high (16 rows and 10
columns).  Note the notation is inverted as compared to the notation
for matrix dimensions which gives rows (height) first..  Also, the
character cell includes rows and columns of pixels allocated for the
space between adjacent characters so the cell size which defines the
boundaries of an actual character may be smaller.

<sect2> Columns/Lines
<p> Usually 80 columns and 24 or 25 lines.  This means that there may
be up to 80 characters in a row (line) on the screen.   Many terminals
have a 132 column option but unless you have a large screen, the tiny
characters may be hard to read. {{Set 132 column mode}}.  If you set
25 lines, make sure that this is in the terminfo.  You should also put
"export LINES=25" into /etc/profile and also use: "stty -F /dev/ttySx
rows 25".  If you don't it might result in a scrolling problem (see
<ref id="no_scroll_25" name="Terminal doesn't scroll">

<sect2> Cursor
<p> The cursor may be set to appear as a rectangle (= block) {Blk}.
Other options are underline {Line} or blinking.  I prefer non-blinking
{Steady} block since it's big enough to find quickly but there is no
distractive blinking.  If you set it invisible (an option on some
terminals) it will disappear but new letters will appear on the screen
as you type at the invisible cursor.

<sect2> Display Attributes (Magic Cookies)
<p> <ref id="display_attributes" name="Display Attributes"> may either
be magic cookies or be attribute bytes assigned to each character.
For magic cookies, there is a limit to their extent: Are they in
effect to the end of the line or to the end of the page?  It's best to
use attribute bytes (which could actually be half-bytes = nibbles).

<sect2> Display Control Characters {Monitor}
<p> May be called various names such as "Display Controls".  When off
(normal) it's "Interpret Controls".  When set on, you see the escape
sequences from the host (which you normally never see on the screen).
So that these sequences may be viewed in sequence on a line, they are
not acted upon (interpreted) by the terminal.  Except that a CR LF
sequence creates a new line.  See <ref id="control_codes"
name="Control Codes">.

<sect2> Double Width/Height
<p> Some terminals can have their characters double width and/or
double height.  This feature is seldom needed.  When changing a line
to double width (DW) the right half (RH) is pushed off the screen and
there is the question of whether or not to delete (erase) it.
"Preserve" means to keep the RH of DW lines.  When in double height
mode, it may be necessary to send each such line twice (the 2nd time
down one row) in order to get a double-height line on the screen.

<sect2> Reverse Video {Display} (Background Light/Dark)
<p> Normal video is light (white, green, amber) letters (foreground)
on a dark (black) background.  Reverse video {Display Light} is the
opposite: black text on a light background.  This is easier on the
eyes (unless the room is dark).

<sect2> Status Line
<p> A status line is a line at the top or bottom of the screen that
displays info about the application program you are running.  It's
often highlighted in some way.  With a status line enabled, an
application can send the terminal a special escape sequence which
means that the text that follows is for the status line.  However,
many applications don't use this feature but instead only simulate a
real status line by direct cursor positioning.  The ordinary user
looking at it doesn't know the difference.

<sect2> Upon 80/132 Change: Clear or Preserve?
<p> When switching the number of columns from 80 to 132 (or
conversely) should the data displayed in the old format be erased
(cleared) or preserved? {80/132 Clr} {{Screen Width Change}}.  It
should make no difference how you set this option since if an
application program uses 132 columns, it should set this option
appropriately via a control sequence.

<sect1> Page Related Options
<p> For a Wyse terminal to be able to access multiple pages of display
memory {Multipage} must be set to on.

<sect2> Page Size
<p> The terminal memory may be divided up into a number of pages.
See <ref id="pages_" name="Pages"> and <ref id="pages_def" name="Pages
(definition)"> for explanations of pages.  You may partition the page
memory into a number of pages of selected length.  Linux applications
don't seem to use pages at present so it shouldn't make much
difference how you set this up.

<sect2> Coupling (of cursor & display)
<p> The terminal memory may be divided up into a number of pages.
See <ref id="pages_" name="Pages"> and <ref id="pages_def" name="Pages">
for explanations of pages.  When the cursor is moved to a location in
video memory not currently displayed (such as another page, or on the
same page but to a location not displayed on the screen) should the
display change to let one view the new cursor location?  If so, this
is called "Coupling".  For cursor movement within the same page there
is "Vertical Coupling" and "Horizontal Coupling".  For movement to
another page there is "Page Coupling".

<sect1> Reporting and Answerback
<p> The terminal will identify itself and its state, or send out a
pre-recorded message in response to certain escape sequences.

<sect2> Answerback Message (String)
<p> You may write a short message during set-up which may optionally
be sent to the host at power-up or be sent to the host in response to
a request from the host (perhaps the ENQ (inquire) control character).

<sect2> Auto Answerback
<p> If set, sends the answerback message to the host at power-on
without the host asking for it.  Do any "getty" processes look for
this ??

<sect2> Answerback Concealed
<p> If set, will never let anyone see the answerback message (except
of course the host computer).  If it needs to be changed, deselect
"answerback concealed" and the formerly concealed message will be
destroyed so you then may enter a new message (but you don't get to
see the old one).

<sect2> Terminal ID {ANSI ID}
<p> The terminal sends this reply in answer to a request for identity.

<sect1> Keyboard Options
<sect2> Keyclick
<p> When set, pressing any key makes a click (broadcast by a tiny
loudspeaker in the keyboard).  These clicks annoy some people and I
think it's best to set keyclick off.

<sect2> Caps Lock {Keylock}
<p> When the Caps-Lock key is down, should only the alphabetic keys
generate shifted characters?  If set to {Caps} or upper-case-only
then hitting a number key with the Caps-Lock on will type the number.
To get the symbol above the number one must manually hold down the
shift key.  This is the normal mode.  If set to {Shift} then all keys
type the shifted character when Caps-Lock is on (hitting the 5 key
should type % without holding down Shift, etc.).

<sect2> Auto Repeat {Repeat}
<p> If a key is held down then that key is repeatedly "typed".  This
is handy for repeatedly typing the same character to create a line across
the page.

<sect2> Margin Bell
<p> When the cursor is 8 columns away from the right side of the
display, a bell is rung (like on an old typewriter).  Almost all
editors will automatically create a new line if needed (no need to
hit the Return key) so this feature is seldom needed.

<sect2> Remapping the Keys
<p> The code sent to the host when a key is pressed is normally the
ASCII code for that key (depends also on Shift and Control key).  On
some terminals you may make any key send any code you wish.  That is,
you may completely remap the keyboard by setting up the terminal that
way.  This may be useful for some foreign languages and Dvorak
keyboard layouts, etc. which permit one to type faster.  Even for
terminals that don't have the feature, there is software to remap the
keyboard (and screen also).  It's something like a device driver
which uses a pseudo terminal.  See <ref id="mapchan_" name="Character
Mapping: mapchan">

<sect2> Corner Key (for Wyse only)
<p> Wyse terminals have a key near the lower left corner which may be
set to do various things.  Its may be labelled "Funct", "Compose
Character", "Alt", "Hold" or "Scroll Lock".  Early models don't have
all of the following options:

<itemize>
<item>Hold: No-Scroll.  Hitting it stops the flow of data (using flow
control) to the terminal.  Hitting the key again restores normal flow.
<item>Compose: Hitting it followed by certain other keys permits one
to generate a limited number of pre-defined non-Latin characters.
<item>Meta: Holding it down while typing another key sets the
high-order bit on each byte.  Are there models where it acts like a
toggle to lock in the meta effect ??
<item>Funct: Holding it down while typing any alphanumeric key
gets a header (SOH) and trailer (CR) byte framing the ASCII byte code.
<item>Kpd Compose: Holding it down while typing a decimal number
on the numeric keys (followed by "enter") sends out the same number in
hexadecimal ??
</itemize>

<sect2> Numeric Keypad or Arrow Keys Sends
<p> The numeric keypad (the rectangle of mostly numeric keys to the
right of the main part of the keyboard) can be set to send special
codes which will do special things in certain application programs.
Ditto for the arrow keys.  There is thus a "normal" mode where they
send what is shown on the keycap (or the normal code sequence for an
arrow-key) and an "application" mode where special escape sequences
are sent.  In some cases there is a "hex" numeric mode which is almost
like normal numeric mode except that 6 non-numeric keys send the
letters A-F.  Thus one may type for example "B36F" on the numeric
keypad.

<sect2> What does shifted-del and shifted-bs send?
<p> Depending on how they're set up, shifted-del sometimes sends the
control character CAN and shifted backspace sometimes sends DEL.

<sect2> PC Scan Codes
<p> Many terminals can emulate a PC keyboard by sending PC scancodes
(see Keyboard-and-Console-HOWTO) instead of ASCII codes.  This is
mostly used with special Multiuser DOS OSs.  It won't work with
ordinary MS DOS.  See <ref id="non_linux" name="Non-Linux OSs">
However, hardly any Linux programs that run via the serial port can
accept scancodes.  If this is the latest version of this HOWTO, let me
know if any programs do this.  I think Foxpro can do it.  You need to
define smsc and rmsc in the terminfo, and perhaps pctrm.

When using scancodes it's best to use hardware flow control since
normal software flow control conflicts with some of the codes (??).
If you do use software flow control, you must use the XPC type of flow
control.  It uses 0x65 and 0x67 for on and off characters.  It must be
set this way both in the terminal and by stty for the PC.

<sect2> Alternate Characters
<p> Some keys may have alternative letters on them.  When keys is set
to "Typewriter" they send what they would normally send on a
typewriter.  When keys is set to something else the alternative
characters are sent.

<sect1> Meaning of Received Control Codes
<sect2> Auto New Line {Newline}
<p> In this case "New Line" means a new line starting at the left
margin below the current line.  In Linux and C "new line" (NL) may
have a different meaning: the line-feed control character LF also
called new-line or NL.  This is because in Linux text files, the LF
character means a "new line starts here" so it's labeled NL.
Normally, a LF (NL) sent to a terminal only results in the cursor
jumping down one line below where is was and does not move the cursor
back to the start of this "new line".

If Auto New Line is set, the above "normal" situation is canceled and
a physical new line is created on the display upon receiving a LF from
the host.  This is exactly what one wants in Linux.  Except that (when
Auto New Line is set) the Return (or Enter) key sends a CR LF sequence
to the host (for Wyse and VT100, but for VT420 ??).  Since Linux uses
LF as a "new line" marker in files, Linux would like only a LF to be
sent (and not a CR LF).  Thus the "New Line" option is seldom used.
Instead, the required translations are made by the serial port device
driver by default.  It is as if one gave the command "stty onlcr
icrnl".  But you don't need to do this since it's the default.

<sect2> Auto Line Feed {Rcv CR}
<p> This is just another type of "Auto New Line".  When a CR (carriage
return) character is received, a LF (line feed) action is added
resulting in a new line being displayed.  Since Linux marks the end of
lines with LF, this option is not used.

<sect2> Recognize Del (Wyse Only ??) or Null <label id="rec_del">
<p> If off, the DEL character received by the terminal is ignored.  If
on the DEL performs a destructive backspace.  Null characters are
usually ignored in any case.  Both DEL and NULL are sometimes used for
padding.  See <ref id="padding" name="Padding">

<sect1> Where New Text Goes
<sect2> Line Wrap
<p> Also called "Auto Wrap(around)".  What happens when the right edge
of the screen is reached (col. 80, etc) and no return character (or
the like) has been sent from the host?  If Line Wrap is set, then the
rest of the line displays on the line below, etc.  Otherwise, the rest
of the line is lost and is not seen on the screen.  Any good
application should handle the situation correctly (provided the
terminfo knows how Line Wrap is set).  Thus even if Line Wrap is not
set, the application should either wrap the screen for long lines or
provide another way for you to view the cutoff tail of long lines (by
use of the arrow keys, etc).  But a raw copy command (and other
situations) may not do this so it's often best to set line wrap.

For an 80 col. screen, most terminals only wrap if the 81st character
from the host is a graphic (printable) character.  This allows for the
case where 81st character from the host might be "return" or a
"newline" (non-graphic characters) which means that the application is
handing the wrapping OK and intervention by the terminal is not
needed.

<sect2> Scrolling
<p> Scrolling {Scrl} is where all the lines on the screen move up or
down.  Its also called "panning" which includes movement sideways.  In
ordinary scrolling lines roll off the bottom or top of the screen and
disappear, and new lines from the host appear at the opposite edge
(top or bottom).  There are 3 types of this: smooth, jump, or burst.
Burst is not really scrolling since its an instant replacement of an
old screenfull by a new one (although some lines on the new screen may
be from the old screen).  Jump is where new lines jump into view one
at a time.  Smooth {Smth} is where the text moves at a steady speed
upward or downward.  If the smooth scroll rate is slow enough, one may
read the newly visible lines when they are still scrolling (in motion).

Smooth scrolling on slow terminals was once useful since one could
continue reading as the display was scrolling.  But with higher baud
rates, jump scroll is so fast that little time is lost as the new
display appears.  Since it takes a little longer to read scrolling
text than fixed text, it may actually waste more time if smooth
scrolling is selected.

If (auto)scrolling {Autoscrl} is disabled, then new text from the host
must go somewhere so it is put at the top of the display.  If the old
text is not erased, the new text merges (nonsensically) into the old.
If the old text is erased, then the new text is out of context.  So
keep (auto)scrolling enabled.

<sect2> New Page?
<p> See <ref id="pages_" name="Pages"> and <ref id="pages_def"
name="Pages"> for explanations of pages.  When the current page is
full (the last line is finished) should the page scroll, or should a
new page be created (leaving the previous page stored in the
terminal's display memory).  If {Autopage} is set, then a new page is
created.  Since you are probably not using pages, you should probably
set this to off.

<sect1> Function Keys <label id="funct_keys">
<p> These are the keys labeled F1, F2, etc.  On older terminals they
may be labeled PF1, PF2, etc. where the P stands for Programmable.
Some keyboards have both.  One may program (redefine) these keys to
send out a string of user-defined bytes.  This doesn't work for older
terminals such as vt100 or for the Linux command-line interface (how
sad).  They may often be easily "programmed" using a certain set-up
menu {FKey}.  On some terminals, one may also specify where this
string is sent to when the key is pressed.  In "normal" mode, pressing
the key is just like typing the string at the keyboard.  In "local"
mode pressing the key sends it to the terminal (just like if the
terminal was in local mode).  This may be used to send escape
sequences to the terminal so as to configure it in a special way.  In
"remote" mode, the string is always sent out the serial port to the
host computer (even if the terminal is in local mode).

<sect1> Block Mode Options
<p> Some options are only for the case of <ref id="block" name="Block
Mode">.  This option is powerful since it provides forms and takes
load off the host computer by transmitting in bursts.  But it's more
complicated to set up and is thus not used too much.

<sect2> Forms Display
<p> In block mode some regions of the screen are for the text of forms
and are thus write-protected "Prot" {WPRT}.  Options may set the characters
in these regions to appear dim, reverse video {WPRT Rev}, and/or
underlined {WPRT Undrln}.  {WPRT Intensity} may be set to dim, normal,
or even blank (invisible)

<sect2> Send Entire Block ?
<p> Should write-protected text (the original text in the form) be
sent to the host upon transmission of a block: {Send All} or is
write-protected text also read-protected: {Send Erasable}

<sect2> Region to Send
<p> Should the entire screen be sent or just the scrolling region?
{Send Area}.  Should the sending stop when the current cursor position
is reached?  If {Xfer Term} is set to Cursor, only the data on the
screen up to the cursor is sent.

<sect2> Block/Page terminator
<p> What is the termination symbol to be appended to a block of data?
{Blk End} or at the end of a page {Send Term}ination.

<sect1> Locks
<p> There are various types of Locks.  One is the Locked keyboard due
to flow control.  See <ref id="keybrd_lock" name="Keyboard Lock">
Another lock {Feature Lock} is that which prohibits the host computer
from changing the terminal set-up by sending certain escape sequences
to the terminal.  Placing such a lock may result in unexpected
behavior as application programs send escape sequences to the
terminals that are ignored.  Not all set-up parameters lock.  Unless
you have a good reason to do so, you should not enable such locking.

A Function Key lock will prohibit the computer from redefining what a
programmable function key sends.  You may want to use this if you have
something important programmed into the function keys.

<sect1> Screen Saver {Scrn Saver}
<p> Also called "CRT Saver".  This turns off (or dims) the screen
after the terminal is not used for a period of time.  It may prolong
the life of the screen and save some energy.  Hitting any key will
usually restore the screen and may "execute" that key so it's best to
hit the shift-key, etc.

<sect1> Printer
<p> For Wyse, if there is no {Printer Attached} set it to Off.  It's
not essential to do this, but if you do it any escape sequence to send
text to the printer (instead of the terminal) will be ignored.

Setting up the printer port is about the same (usually simpler) as
setting up the communications on the main port.  There are a couple of
options specific to the printer.  Is the printer a serial or parallel
printer?  If it's parallel it should be designated as such in setup
and connected to the parallel port on the terminal (if there is one).
Should a FF (form feed) be sent to the printer at the end of a print
job?  If {Print Term} is set to FF, this will happen.

<sect> Computer Set-Up (Configure) Details <label id="comp_conf_details">
<p> There are various files to edit to set up the computer for
terminals.  If you're lucky, you'll only need to edit /etc/inittab.
One does this by editing at the console (or from any working terminal).

<sect1> Getty (used in /etc/inittab)  <label id="getty_">
<sect2> Introduction to Getty
<p> In order to have a login process run on a serial port (and the
terminal connected to it) when the computer starts up (or switches run
levels) a getty command must be put into the /etc/inittab file.
Running getty from the command line may cause problems (see <ref
id="stopped_" name="If getty run from command line: Programs get
stopped"> to see why ).  Getty GETs a TTY (a terminal) going.  Each
terminal needs its own getty command.  There is also at least one
getty command for the console in every /etc/inittab file.  Find this
and put the getty commands for the real terminals next to it.  This
file may contain sample getty lines for text terminals that are
commented out so that all you need to do is to uncomment them (remove
the leading #) and change a few arguments.

The arguments which are permitted depend on which getty you
use:<newline>
Two gettys best for directly connected terminals are:
<enum>
<item> agetty (sometimes just called getty):  Easy to set up with no config
required.  See <ref id="agetty_" name="agetty">
<item> <ref id="getty_ps" name="getty (part of getty_ps)"> More
advanced with config file. 
</enum>
Two gettys best for dial-in modems (avoid for directly connected
terminals) are:
<enum>
<item> mgetty: the best one for modems; works for terminals too but inferior
<item> uugetty: for modems only; part of the getty_ps package
</enum>
Simple gettys to use if you don't use a real text-terminal.  Most
Linux users use one of these at their monitor:
<enum>
<item> mingetty
<item> fbgetty
<item> fgetty
<item> rungetty
</enum>

Your Linux distribution may come with either getty_ps or agetty for
text-terminals.  Some distributions supply neither.  Unfortunately,
they often just call it "getty".  If you need to determine which one
you have look at the man page for "getty".  As of 2007 agetty (in the
"util-linux package) seems to be more widely used then getty_ps which
was at:
<url
url="http://rpmfind.net/linux/rpm2html/search.php?query=getty_ps&amp;subm"
name="getty_ps">

As a last resort to try to determine which getty you have, you might
check out its executable code (usually in /sbin).  getty_ps has
/etc/gettydefs embedded in this code.  To search for it, go
to /sbin and type:<newline> 
<tt>strings getty | grep getty </tt><newline>
If getty is actually agetty the above will result in
nothing.  However if you have agetty typing:<newline>
<tt>getty -h</tt><newline> should show the agetty options [-hiLmw].

The source codes for various gettys may be downloaded from <url url=
"http://ibiblio.org/pub/Linux/system/serial/getty/" name="Getty
Software">.

If you are not using modem control lines (for example if you only use
the minimum number of 3 conductors: transmit, receive, and common
signal ground) you should let getty know this by using a "local" flag.
The format of this depends on which getty you use.

<sect2> Getty exits after login (and can respawn)
<!-- getty_seq.D begin (in MM, TT)
This is the sequence of events that happens after getty starts up.
<sect2> How getty respawns
-->
<p>After you log in you will notice (by using "top", "ps -ax", or
"ptree") that the getty process is no longer running.  What happened
to it?  Why does getty restart again if your shell is killed?  Here's
why.

After you type in your user name, getty takes it and calls the login
program telling it your user name.  The getty process is replaced
by the login process.  The login process asks for your password,
checks it and starts whatever process is specified in your password
file.  This process is often the bash shell.  If so, bash starts and
replaces the login process.  Note that one process replaces another
and that the bash shell process originally started as the getty
process.  The implications of this will be explained below.

Now in the /etc/inittab file, getty is supposed to respawn (restart) if
killed.  It says so on the line that calls getty.  But if the bash shell
(or the login process) is killed, getty respawns (restarts).  Why?
Well, both the login process and bash are replacements for getty and
inherit the signal connections establish by their predecessors.  In
fact if you observe the details you will notice that the replacement
process will have the same process ID as the original process.  Thus
bash is sort of getty in disguise with the same process ID number.  If
bash is killed it is just like getty was killed (even though getty
isn't running anymore).  This results in getty respawning.

When one logs out, all the processes on that serial port are killed
including the bash shell.  This may also happen (if enabled) if a
hangup signal is sent to the serial port by a drop of DCD voltage by
the modem.  Either the logout or drop in DCD will result in getty
respawning.  One may force getty to respawn by manually killing bash
(or login) either by hitting the k key, etc. while in "top" or with
the "kill" command.  You will likely need to kill it with signal 9
(which can't be ignored).


<sect2> If getty run from command line: Programs get stopped
 <label id="stopped_">
<p> You should normally run getty from inside <tt>/etc/inittab</tt>
and not from the command line or else some programs running on the
terminal may be unexpectedly suspended (stopped).  Here's why (skip to
the next section if the why is not important to you).  If you start
getty for say ttyS1 from the command line of another terminal, say tty1,
then it will have tty1 as its "controlling terminal" even though the
actual terminal it runs on is ttyS1.  Thus it has the wrong
controlling terminal.  But if it's started inside the inittab file
then it will have ttyS1 as the controlling terminal (correct).

Even though the controlling terminal is wrong, the login at ttyS1 works
fine (since you gave ttyS1 as an argument to getty).  The standard
input and output are set to ttyS1 even though the controlling terminal
remains tty1.  Other programs run at ttyS1 may inherit this standard
input/output (which is connected to ttyS1) and everything is OK.  But
some programs may make the mistake of trying to read from their
controlling terminal (tty1) which is wrong.  Now tty1 may think that
these programs are being run in the background by tty1 so an attempt
to read from tty1 (it should have been ttyS1) results in stopping the
process that attempted to read.  (A background process is not allowed
to read from its controlling terminal.).  You may see a message
something like: "<tt>[1]+  Stopped</tt>" on the screen.  At this point
you are stuck since you can't interact with a process which is trying
to communicate with you via the wrong terminal.  Of course to escape
from this you can go to another terminal and kill the process, etc.

<sect2> agetty (may be named getty) <label id="agetty_">
<p>agetty means "alternative getty" and it was an easier-to-use
alternative to the original getty (getty_ps).<newline>
An example line in /etc/inittab: <newline>
<tscreen><verb>
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
</verb></tscreen>
S1 is from ttyS1.  23 means that getty is run upon entering run levels
2 or 3.  respawn means that if getty (or a process that replaced it
such as bash) is killed, getty will automatically start up (respawn)
again.  /sbin/getty is the getty command.  The -L means Local (ignore
modem control signals).  -h (not shown in the example) enables
hardware flow control (same as stty crtscts).  19200 is the baud rate.
ttyS1 means /dev/ttyS1 (COM2 in MS-DOS).  vt102 is the type of
terminal and this getty will set the environment variable TERM to this
value.  There are no configuration files.  Type "init q" on the
command line after editing getty and you should see a login prompt.

<sect3> Agetty's auto-detection of parity problems
<p> The <tt/agetty/ program will attempt to auto-detect the parity set
inside the terminal (including no parity).  It doesn't support 8-bit
data bytes plus 1-bit parity.  See <ref id="parity_8-bit" name="8-bit
data bytes (plus parity)">.  If you use <tt/stty/ to set parity,
<tt/agetty/ will automatically unset it since it initially wants the
parity bit to come thru as if it was a data bit.  This is because it
needs to get the last bit (possibly a parity bit) as you type your
login-name so that it can auto-detect parity.  Thus if you use parity,
enable it only inside the text-terminal and let <tt/agetty/
auto-detect it and set it at the computer.  If your terminal supports
received parity, the login prompt will look garbled until you type
something so that getty can detect the parity.  The garbled prompt
will deter visitors, etc. from trying to login.  That could be just
what you want.

There is sometimes a problem with auto detection of parity.  This
happens because after you first type your login name, <tt/agetty/
starts the <tt/login/ program to finish logging you in.
Unfortunately, the <tt/login/ program can't detect parity so if the
<tt/getty/ program failed to determine the parity then <tt/login/ will
not be able to determine it either.  If the first login attempt fails,
<tt/login/ will let you try again, etc. (all with the parity set
wrong).  Eventually, after a number of failed attempts to login (or
after a timeout) <tt/agetty/ will start up again and start the login
sequences all over again.  Once getty is running again, it may be able
to detect the parity on the second try so everything may then work OK.

With wrong parity, the <tt/login/ program can't correctly read what
you type and you can't log in.  If your terminal supports received
parity, you will continue to see a garbled screen.  If getty fails to
detect parity an /etc/issue file is usually dumped to the screen just
before the before the prompt, so more garbled words may appear on the
screen.

Why can't agetty detect parity by the first letter typed?  Here's an
example: Suppose it detects an 8-bit byte with its parity bit 0
(high-order bit) and with an odd number of 1-bits.  What parity is it?
Well, the odd number of 1 bits implies that it's odd parity.  But it
could also just be an 8-bit character with no parity.  There's no way
so far to determine which.  But so far we have eliminated the
possibility of even parity.  The detection of parity thus proceeds by
a process of elimination.

If the next byte typed is similar to the first one and also only
eliminates the possibility of even parity, it's still impossible to
determine parity.  This situation can continue indefinitely and in rare
cases login will fail until you change your login-name.  If agetty
finds a parity bit of 1 it will assume that this is a parity bit and
not a high-order bit of an 8-bit character.  It thus assumes that you
don't use meta-characters (high bit set) in your user name (i.e that
your name is in ASCII).

One may get into a "login loop" in various ways.  Suppose you only
type a single letter or two for your login name and then hit return.
If these letters are not sufficient for parity detection, then login
runs before parity has been detected.  Sometimes this problem happens
if you don't have the terminal on and/or connected when agetty first
starts up.

If you get stuck in this "login loop" a way out of it is
to hit the return key several times until you get the getty login
prompt.  Another way is to just wait a minute or so for a timeout.
Then the getty login prompt will be put on the screen by the getty
program and you may try again to log in.

<sect3> 8-bit data bytes (plus parity) <label id="parity_8-bit">
<p> Unfortunately, agetty can't detect this parity.  As of late 1999
it has no option for disabling the auto-detection of parity and thus
will detect incorrect parity.  The result is that the login process
will be garbled and parity will be set wrong.  Thus it doesn't seem
feasible to try to use 8-bit data bytes with parity.

<sect2> getty (part of getty_ps) <label id="getty_ps">
<p>The name has often been misspelled as <tt>ps_getty</tt>. (Most of
this is from the old Serial-HOWTO by Greg Hankins)<newline> For this
getty one needs to both put entries in a configuration file and add an
entry in <tt>/etc/inittab</tt>.  Here are some example entries to use
for your terminal that you put into the configuration file
<tt>/etc/gettydefs</tt>.

<tscreen><verb>
# 38400 bps Dumb Terminal entry
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400

# 19200 bps Dumb Terminal entry
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200

# 9600 bps Dumb Terminal entry
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
</verb></tscreen>
<p> Note that the DT38400, DT19200, etc. are just labels and must
be the same that you use in <tt>/etc/inittab</tt>.

If you want, you can make <tt/getty/ print interesting things in the
login banner.  In my examples, I have the system name and the serial
line printed.  You can add other things:
<tscreen><verb>
@B    The current (evaluated at the time the @B is seen) bps rate.
@D    The current date, in MM/DD/YY.
@L    The serial line to which getty is attached.
@S    The system name.
@T    The current time, in HH:MM:SS (24-hour).
@U    The number of currently signed-on users.  This is  a
      count of the number of entries in the /etc/utmp file
      that have a non-null ut_name field.
@V    The value of VERSION, as given in the defaults file.
To display a single '@' character, use either '\@' or '@@'.
</verb></tscreen>

When you are done editing <tt>/etc/gettydefs</tt>, you can verify that
the syntax is correct by doing:
<tscreen><verb>
linux# getty -c /etc/gettydefs
</verb></tscreen>

Make sure there is no other <tt/getty/ or <tt/uugetty/ config file for
the serial port that your terminal is attached to such as
(<tt>/etc/default/{uu}getty.ttyS</tt><em/N/ or
<tt>/etc/conf.{uu}getty.ttyS</tt><em/N/), as this will probably
interfere with running <tt/getty/ on a terminal.  Remove such
conflicting files if they exits.

Edit your <tt>/etc/inittab</tt> file to run <tt/getty/ on the serial
port (substituting in the correct information for your environment -
port, speed, and default terminal type):
<tscreen><verb>
S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
</verb></tscreen>
Restart <tt/init/:
<tscreen><verb>
linux# init q
</verb></tscreen>

At this point, you should see a login prompt on your terminal.  You
may have to hit return to get the terminal's attention.

<sect2> mgetty
<p> The "m" stands for modem.  This program is primarily for modems
and as of mid 2000 it will require recompiling to use it for
text-terminals (unless you use hardware flow control --and that
usually requires a hand-made cable).  For the documentation for
directly connected terminals see the "Direct" section of the manual:
<tt>mgetty.texi.</tt>

Look at the last lines of <tt>/etc/mgetty/mgetty.config</tt> for an
example of configuring it for a terminal.  Unless you say "toggle-dtr
no" it will think that you have a modem and drop (negate) the DTR pin
at the PC in a vain attempt to reset the non-existent modem.  In
contrast to other gettys, mgetty will not attach itself to a terminal
until someone hits any key of that terminal so you'll see a ? for the
terminal in <tt/top/ or <tt/ps/ until this happens.  The logs in
<tt>/var/log/mgetty/</tt> may show a few warning messages which are
only applicable to modems which you may ignore.

Here's an example of the simple line you put in <tt>/etc/inittab:</tt>

<tscreen><verb>
s1:23:respawn:/sbin/mgetty -r ttyS1
</verb></tscreen>

<sect1> Stty & Setserial <label id="stty_setserial">
<p> There is both a "stty" command and a "setserial" command for
setting up the serial ports.   Some (or all) of the needed stty
settings can be done via getty and there may be no need to use
setserial so you may not need to use either command.  These two
commands (stty and setserial) set up different aspects of the serial
port.  Stty does the most while setserial configures the low-level
stuff such as interrupts and port addresses.  To "save" the settings,
these commands must be written in certain files (shell scripts) which
run each time the computer starts up.  Distributions of Linux often
supply a shell script which runs <tt/setserial/ but seldom supply one
which runs <tt/stty/ since on seldom need it.

<sect1> Setserial <label id="set_serial">
<!-- setserial.D  begin  (in MM TT SS)
<sect1>What is Setserial ? <label id="set_serial">
Change Log:
May 2000: <sect2> IRQs near end ttyS0 -> ttyS1 + clarity
Nov. 2000: auto_irq may work on the 2nd try
Dec. 2000: saving state of serial module
June 2001 OK to use setserial with Laptops
Nov. 2002 Debian's /var/lib/serial.conf
Nov. 2003 Major revision.  Plug-and-play dominates
May 2004 Old Debian 1999 bug reported by me removed (fixed in 1999)
Feb.2005 Where config files reside
 /var/lib/setserial/autoserial.conf
-->
<p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal.  There
are some minor differences, depending on which HOWTO it appears in.

<sect2>Setserial problems with linmodems, laptops
<p> 
If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you
read <ref id="laptops_" name="Laptops: PCMCIA">.

<sect2> Introduction
<p><tt/setserial/ is a program used for the user to communicate with
the serial device driver.  You normally never need to use it, provided
that you only use the one or two serial ports that come as standard
equipment with a PC.  Even in other cases, most extra serial ports
should be auto-detected by modern kernels.  Except you'll need to use
setserial if you have an obsolete ISA serial port set by jumpers on the
physical hardware or if your kernel (such as 2.2 or older) doesn't
both detect and set your add-on PCI serial ports.  In some cases the
setserial program may have been previously used and the wrong serial
port data has been manually given by the some past user (perhaps by
you).  If setserial hasn't been configured to accept what the kernel
says, it will override the (likely correct) kernel data with what
someone previously set.

<tt/setserial/ allows you (or a shell script) to talk to the serial
software.  But there's also another program, tt/stty/, that also deals
with the serial port and is used for setting the port speed, etc.
<tt/setserial/ is really a misnomer, it doesn't set any information on
the serial card.  Example: it can't change the irq set on the card.
More details on this later

<tt/setserial/ deals with the lower-level configuring of the serial
port, such as dealing with IRQs (such as 5), port addresses (such as
3f8), and the like.  A major problem with it is that it can't
set or configure the serial port hardware: It can't set the IRQ or
port addresses into the hardware.  Furthermore, when it seemingly
reports the configuration of the hardware, it's sometimes wrong since
it doesn't actually probe the hardware unless you specifically tell it
to.  Even then, it doesn't do the modern type of bus probing and some
hardware may never be found by it.  Still, what it shows is right most
all the time but if you're having trouble getting a serial port to
work, then there's a fair chance it's wrong.

In olden days, when the IRQ and port address was set by jumpers on the
serial card, one would use <tt/setserial/ to tell the driver how these
jumpers were set.  Today, when plug-and-play methods detect how the
jumperless serial port is set, <tt/setserial/ is not really needed
anymore unless you're having problems or using old hardware.
Furthermore, if the configuration file used by <tt/setserial/ is
wrong, then there's trouble.  In this case, if you use <tt/setserial/
to try to find out how the port is configured, it may just repeat the
incorrect information in the setserial configuration file.

<tt/setserial/ can sometimes be of help to find a serial port.  But 
it's only of use if you know the port address and use the right
options.  For modern ports, there's usually better ways to look for
them by plug-and-play methods.

Thus the name <tt/setserial/ is somewhat of a misnomer since it
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
them in the driver software.  And the driver naively believes that
what <tt/setserial/ tells it, even if it conflicts with what the driver
has found by using plug-and-play methods.  Too bad that it fails to
at least issue a warning message for setserial such a conflict.  Since the
device driver is considered to be part of the kernel, the word
"kernel" is often used in other documentation with no mention made of
any "serial driver". 

Some distributions (and versions) set things up so that <tt/setserial/
is run at boot-time by an initialization shell script (in the
/etc directory tree).   But the configuration file which this script
uses may be either in the /etc tree or the /var tree.  In some cases,
if you want <tt/setserial/ to run at boot-time, you may have to take
some action.  <tt/setserial/will not work without either serial
support built into the kernel or loaded as a module.  The module may
get loaded automatically if you (or a script) attempt to use
<tt/setserial/.

While <tt/setserial/ can be made to probe the hardware IO port
addresses to try to determine the UART type and IRQ, this has
severe limitations.  See <ref id="probing_ss" name="Probing">.  It
can't set the IRQ or the port address in the hardware of PnP or PCI
serial ports (but the plug-and-play features of the serial driver may
do this).  It also can't directly read the PnP data stored in
configuration registers in the hardware.  But since the device driver
can read these registers and setserial tells you what the device
driver thinks, it might be correct.  Or it could be telling you what
<tt/setserial/ had previously (and perhaps erroneously) told the
driver.  There's no way to know for sure without doing some other
checks.

The serial driver (for Linux Kernels 2.4 and 2.6) looks for a few
"standard" legacy serial ports, for PnP ports on the ISA bus, and for
all supported port hardware on the PCI bus.  If it finds your ports
correctly, then there's no need to use <tt/setserial/ unless they have
been "set" incorrectly in the setserial configuration file.  The driver
doesn't probe for the IRQs of old ISA serial ports set with jumpers on
the card and may get these wrong.

Besides the man page for <tt/setserial/, check out info in
<tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>.
This should tell you how setserial is handled for your distribution of
Linux.  While <tt/setserial/ behaves the same in all distributions,
the scripts for running it, how to configure such scripts (including
automatic configuration), and the names and locations of the script
files, etc., are all distribution-dependent.  If your serial port is Plug-and-Play you may need to consult other
HOWTOs such as Plug-and-Play or Serial.

<sect2>Serial module unload
<p>If a serial module gets unloaded, the changes previously made by
<tt/setserial/ will be forgotten by the driver.  But while the driver
forgets it, a script provided by the distribution may save it in a
file somewhere so that it can the restored if the module is reloaded.
Also changes made by setserial may be stored in setserial's
configuration file (see the documentation for your distribution, this
info is not in the man page).

  

<sect2>Giving the <tt/setserial/ command
<p>Remember, that <tt/setserial/ can't set any I/O addresses or IRQs
in the hardware.  That's done either by plug-and-play software (run by
the driver) or by jumpers for legacy serial ports.  Even if you give
an I/O address or IRQ to the driver via <tt/setserial/ it will not set
such values and assumes that they have already been set.  If you give
it wrong values, the serial port will not work right (if at all).

For legacy ports, if you know the I/O address but don't know the IRQ
you may command setserial to attempt to determine the IRQ.

You can see a list of possible commands by just typing <tt/setserial/
with no arguments.  This fails to show you the one-letter options such
as -v for verbose which you should normally use when troubleshooting.
Note that setserial calls an IO address a "port".  If you type:
<tscreen><verb>
setserial -g /dev/ttyS*
</verb></tscreen>
You'll see some info about how the device driver is configured for
your ports.  In many cases you'll see some ports displayed with what
appears at first glance to be erroneous IRQs and addresses.  But if
you also see: <tt>"UART: unknown"</tt> just ignore the entire line
since no serial port exists at that address. 

If you add -a to the option -g you will see more info although few
people need to deal with (or understand) this additional info since
the default settings you see usually work fine.  In normal cases the
hardware is set up the same way as "setserial" reports.  But if you are
having problems there is a good chance that <tt/setserial/ has it wrong.
In fact, you can run "setserial" and assign a purely fictitious I/O
port address, any IRQ, and whatever uart type you would like to have.
Then the next time you type "setserial ..." it will display these
bogus values you've supplied to the driver.  They will also be officially
registered with the kernel as displayed (at the top of the screen) by
the "scanport" command (Debian).  Of course the serial
port driver will not work correctly (if at all) if you attempt to use
such a port.  Thus, when giving parameters to <tt/setserial/, "anything
goes".  Well almost.  If you assign one port a base address that is
already assigned (such as 3e8) it may not accept it.  But if you use
3e9 it will accept it.  Unfortunately 3e9 is actually assigned since it
is within the range starting at base address 3e8.  Thus the moral of
the story is to make sure your data is correct before assigning
resources with setserial.

<sect2>Configuration file
<p>While assignments made by setserial are lost when the PC is powered
off, a configuration file may restore them when the PC is started
up again.  In newer versions, what you change by setserial might get
automatically saved to a configuration file.  When <tt/setserial/ runs
it uses the info from the configuration file.

Where this configuration file resides depends on your distribution.
Look at the start-up scripts somewhere in the /etc/ tree (such as
/etc/init.d/ or /etc/rc.d/) and read the startup script for "serial"
or "setserial" or the like.  It should show where the configuration
file(s) reside.  In Debian there are 4 options for use of this
configuration file:

<enum>
<item>Don't use this file at all.  At each boot, the serial driver
alone detects the ports and setserial doesn't ever run.  ("kernel" option)
<item>Save what <tt/setserial/ reports when the system is first
shutdown and put it in the configuration file.  After that, don't ever
make any changes to the configuration file, even if someone has made
changes by running the <tt/setserial/ command on the command line and
then shuts down the system. ("autosave-once" option)
<item>At every shutdown, save whatever <tt/setserial/ detects to the
configuration file.  ("autosave" option)
<item>Manually edit the configuration file to set the configuration.
Don't ever do any automatic saves to it. ("manual" option)
</enum>

In olden days (perhaps before 2000), there wasn't any configuration
file and the configuration was manually set (hard coded) inside the
shell script that ran <tt/setserial/.  See <ref id="old_sets_script"
name="Edit a script (prior to version 2.15)">.

<sect2> Probing <label id="probing_ss">
<p>You probe for a port with <tt/setserial/ only when you suspect that
it has been enabled (by PnP methods, the BIOS, jumpers, etc.).
Otherwise <tt/setserial/ probing will never find it since its address
doesn't exist.  A problem is where the software looks for a port at
specified I/O addresses.  Prior to probing with "setserial", one may
run the "scanport" (Debian) command to check all possible ports in one
scan.  It makes crude guesses as to what is on some ports but doesn't
determine the IRQ.  It's a fast first start.  It may hang your PC but
so far it's worked fine for me.  Note that non-Debian distributions
don't seem to supply "scanport".  Is there another scan program?

With appropriate options, <tt/setserial/ can probe (at a given I/O
address) for a serial port but you must guess the I/O address.  If you
ask it to probe for /dev/ttyS2 for example, it will only probe at the
address it thinks ttyS2 is at (2F8).  If you tell setserial that ttyS2
is at a different address, then it will probe at that address, etc.
See <ref id="probing_ss" name="Probing">

The purpose of such probing is to see if there is a uart there, and if
so, what its IRQ is.  Use <tt/setserial/ mainly as a last resort as
there are faster ways to attempt it such as wvdialconf to detect
modems, looking at very early boot-time messages, or using <tt>pnpdump
--dumpregs</tt>, or lspci -vv.  But if you want to detect hardware
with <tt/setserial/ use for example :<newline> <tt>setserial
/dev/ttyS2 -v autoconfig</tt><newline>
If the resulting message shows a uart type such as 16550A, then you're
OK.  If instead it shows "<tt/unknown/" for the uart type, then there
is supposedly no serial port at all at that I/O address.  Some cheap
serial ports don't identify themselves correctly so if you see
"<tt/unknown/" you still might have a serial port there.

Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either.  In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq.  In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into a
distribution-specific configuration file such as
<tt>/etc/serial.conf</tt> or <tt>/etc/sysconfig/serial</tt> or
<tt>/var/lib/setserial/autoserial.conf</tt> for Debian.  This will be
used next time you start Linux.  

It may be that two serial ports both have the same IO address set in
the hardware.  Of course this is not normally permitted for the ISA
bus but it sometimes happens anyway.  Probing detects one serial port
when actually there are two.  However if they have different IRQs,
then the probe for IRQs may show IRQ = 0.  For me, it only did this if
I first used <tt/setserial/ to give the IRQ a fictitious value.

<sect2>Boot-time Configuration <label id="sets_boot_time">
<p>While <tt/setserial/ may run via an initialization script,
something akin to <tt/setserial/ also runs earlier when the serial
module is loaded (or when the kernel starts the built-in serial driver
if it was compiled into the kernel).  Thus when you watch the start-up
messages on the screen it may look like it ran twice, and in fact it
has. 

If the first message is for a legacy port, the IRQs shown may be wrong
since it didn't probe for IRQs.  If there is a second report of serial
ports, it may the result of a script such as /etc/init.d/setserial.
It usually does no probing and thus could be wrong about how the
hardware is actually set.  It only shows configuration data that got
saved in a configuration files.  The old method, prior to setserial
2.15, was to manually write such data directly into the script.

When the kernel loads the serial module (or if the "module equivalent"
is built into the kernel) then all supported PnP ports are detected.
For legacy (non-PnP) ports, only <tt/ttyS{0-3}/ are auto-detected
and the driver is set to use only IRQs 4 and 3 (regardless of what
IRQs are actually set in the hardware).  No probing is done for IRQs
but it's possible to do this manually.  You see this as a boot-time
message just as if <tt/setserial/ had been run.

To correct possible errors in IRQs (or for other
reasons) there may be a script file somewhere that runs
<tt/setserial/.  Unfortunately, if this file has some IRQs wrong, the
kernel will still have incorrect info about the IRQs.  This file is
usually part of the initialization done at boot-time.  Whether it
runs or not depends on how you (and/or your distribution) have set
things up.  It may also depends on the runlevel.  

Before modifying a configuration file, you can test out a "proposed"
<tt/setserial/ command by just typing it on the command line.  In some
cases the results of this use of <tt/setserial/ will automatically get
saved somewhere such as /etc/serial.conf (or autoserial.conf or
serial) when you shutdown.  So if it worked OK (and solved your
problem) then there's no need to modify any configuration file.  See
<ref id="config_file" name="Configuration method using
/etc/serial.conf, etc.">.

<sect2> Edit a script (required prior to version 2.15)
 <label id="old_sets_script">
<p> This is how it was done prior to <tt/setserial/ 2.15 (1999)
The objective was to modify (or create) a script file in the /etc
tree that runs setserial at boot-time.  Most distributions provided
such a file (but it may not have initially resided in the /etc tree).

So prior to version 2.15 (1999) it was simpler.  All you did was edit
a script.  There was no /etc/serial.conf file (or the like) to
configure setserial.   Thus you needed to find the file that runs
"setserial" at boot time and edit it.  If it didn't exist, you needed
to create one (or place the commands in a file that ran early at
boot-time).  If such a file was currently being used it's likely
was somewhere in the /etc directory-tree.  But Redhat <6.0 has supplied it
in /usr/doc/setserial/ but you need to move it to the /etc tree before
using it.

The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past.
The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>.
Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's may
not have run early enough.  It was reported that other processes may
try to open the serial port before rc.local ran resulting in serial
communication failure.  Later on it most likely was found in
/etc/init.d/ but wasn't normally intended to be edited.

If such a file was supplied, it likely contained a number of
commented-out examples.  By uncommenting some of these and/or
modifying them, you could set things up correctly.  It was important
use a valid path for <tt/setserial/, and a valid
device name.  You could do a test by executing this file manually
(just type its name as the super-user) to see if it works right.
Testing like this was a lot faster than doing repeated reboots to get
it right.

For versions >= 2.15 (provided your distribution implemented the
change, Redhat didn't at first) it may be more tricky to do since the
file that runs setserial on startup, /etc/init.d/setserial or the like
was not intended to be edited by the user.  See <ref id="config_file"
name="Configuration method using /etc/serial.conf, etc.">.

An example line in such a script was:
<tscreen><verb>
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A  skip_test
</verb></tscreen>

or, if you wanted setserial to automatically determine the uart and the
IRQ for ttyS3 you would have used something like this:

<tscreen><verb>
/sbin/setserial  /dev/ttyS3 auto_irq skip_test autoconfig
</verb></tscreen>

This was done for every serial port you wanted to auto configure,
using a device name that really does exist on your machine.  In some
cases it didn't work right due to the hardware. 

<sect2> Configuration method using /etc/serial.conf, etc.
<label id="config_file">
<p> Prior to setserial version 2.15 (1999), the way to configure
setserial was to manually edit the shell-script that ran setserial at
boot-time.  See <ref id="old_sets_script" name="Edit a script (before
version 2.15)">.  This was simple, but the simple and clear method has
been changed to something that is unnecessarily complex.  Today the
script and configuration file are two different files instead of one.
This shell-script is not edited but gets its data from a configuration
file such as <tt>/etc/serial.conf</tt> (or
<tt>/var/lib/setserial/autoserial.conf</tt>).

Furthermore you may not even need to edit serial.conf (or the like)
because using the "setserial" command on the command line may
automatically cause serial.conf to be edited appropriately.  This was
done so that you may not need to edit any file in order to set up (or
change) what setserial does each time that Linux is booted.

What often happens is this:  When you shut down your PC the script
that ran "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do:  It uses
"setserial" to find out what the current state of "setserial" is, and
it puts that info into the serial configuration file such as
<tt>serial.conf</tt>.  Thus when you run "setserial" to change
the serial.conf file, it doesn't get changed immediately but only when
and if you shut down normally.

Now you can perhaps guess what problems might occur.  Suppose you
don't shut down normally (someone turns the power off, etc.) and the
changes don't get saved.  Suppose you experiment with "setserial" and
forget to run it a final time to restore the original state (or make a
mistake in restoring the original state).  Then your "experimental"
settings are saved.  And worst of all, unless you know which options
were set in the configuration file, you don't know what will happen.
One option in Debian (and likely other distributions) is known as
"AUTOSAVE-ONCE" which saves changes only for the first time you make
them with the setserial command.

If the option "###AUTOSAVE###" is set and you manually edit
serial.conf, then your editing is destroyed when you shut down because
it gets changed back to the state of setserial at shutdown.  There is
a way to disable the changing of serial.conf at shutdown and that is
to remove "###AUTOSAVE###" or the like from first line of serial.conf.
In the Debian distribution, the removal of "###AUTOSAVE###" from the
first line was once automatically done after the first time you
shutdown just after installation.  To retain this effect the
"AUTOSAVE-ONCE" option was created which only does a save when time
the system is shut down for the first time (just after you install or
update the setserial program).

The file most commonly used to run setserial at boot-time (in
conformance with the configuration file) is now /etc/init.d/setserial
(Debian) or /etc/init.d/serial (Redhat), or etc.,  but it should not
normally be edited.  For 2.15, Redhat 6.0 just had a file
/usr/doc/setserial-2.15/rc.serial which you have to move to
/etc/init.d/ if you want setserial to run at boot-time.

To disable a port, use <tt/setserial/ to set it to "uart none".  This
will not be saved.  The format of /etc/serial.conf appears to be just
like that of the parameters placed after "setserial" on the command
line with one line for each port.  If you don't use autosave, you may
edit /etc/serial.conf manually.

In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
normally happens when you shutdown: Run the shell-script
<tt>/etc/init.d/{set}serial stop</tt>.  The "stop" command will save
the current configuration but the serial ports still keep working OK.

In some cases you may wind up with both the old and new configuration
methods installed but hopefully only one of them runs at boot-time.
Debian labeled obsolete files with "...pre-2.15".

<sect2> IRQs

<p> By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and
ttyS3 share IRQ 3.  But while sharing serial interrupts (using them in
running programs) is OK for the PCI bus, it's not permitted for the
ISA bus unless you: 1. have kernel 2.2 or better, and 2. you've
compiled in support for this, and 3. your serial hardware supports it.
See
Serial-HOWTO: Interrupt sharing and Kernels 2.2+.


If you only have two serial ports, ttyS0 and ttyS1, you're still OK
since IRQ sharing conflicts don't exist for non-existent devices.

If you add a legacy internal modem (without plug-and-play) and retain
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
it in your serial port (or modem card) and then use setserial to
assign it to your device driver.  If IRQ 5 is not being used for a
sound card, this could be used for a modem.

<sect2> Laptops: PCMCIA <label id="laptops_">
<p>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
configuration.  For serial ports on the motherboard, setserial is used
just like it is for a desktop.  But for PCMCIA cards (such as a modem)
it's a different story.  The configuring of the PCMCIA system should
automatically run setserial so you shouldn't need to run it.  If you
do run it (by a script file or by /etc/serial.conf) it might be
different and cause trouble.  The autosave feature for serial.conf
shouldn't save anything for PCMCIA cards (but Debian did until
2.15-7).  Of course, it's always OK to use setserial to find out how
the driver is configured for PCMCIA cards.

<!-- setserial.D  end -->

<sect1> Stty <label id="stty_">
<!-- stty.D begin <sect1> Stty <label id="stty_">
In Serial and Text-Terminal
Feb. 2005: Put redirection info into Obsolete section
-->
<sect2> Introduction
<p> <tt/stty/ does much of the configuration of the serial port but
since application programs (and the getty program) often handle this,
you may not need to use it much.  It's handy if you're having problems
or want to see how the port is set up.  It also configures the terminal
interface which is not only used by the serial port but is also used
anytime you use a command-line interface in Linux.  Try typing ``stty
-a'' at your terminal/console to see how it's now set.  Also try typing
it without the -a (all) for a short listing which shows how it's set
different than "normal" which is how it's set using the command
<tt>"stty sane"</tt>.  Don't try to learn all the settings unless you
want to become a serial historian since many of the settings are only
for slow antique dumb terminals of the 1970's.  Most of the defaults
should work OK.

<tt/stty/ is documented in the man pages with a more detailed account
in the info pages.  Type <tt>"man stty"</tt> or <tt>"info stty"</tt>.

Many of the stty options (or settings) start with an "o" (output) or an
"i" (input).  For example: <tt/onlcr/.  Output is the flow of bytes out
of the computer while input is the flow of bytes into the computer.  The
"point of view" is the computer, not the serial port or the device
connected to the serial port.  For example, received input data comes in
on a cable and goes to the serial port chip.  This chip, after
converting the bits from the serial to parallel representation, then
sends it (via a program read) to the large serial port buffer in main
computer memory.  Thus the chip has both input and output but since it's
input data to the computer, its output is considered to be input.  The
situation is similar for output flowing thru this chip.  The "input" and
"output" refer to the direction of flow with respect to the computer and
not the serial port hardware (the chip).

Whereas <tt/setserial/ only deals with actual serial ports, stty is used
for terminals regardless of whether they are accesses via a serial port,
network, or by a virtual terminal on Linux PC monitor, or a GUI
terminal window such as xterm.  For the PC monitor, xterm, or a network
many of the stty settings are meaningless.  Changing the baud rate, etc.
doesn't appear to actually do anything.

Here are some of the items stty configures: speed (bits/sec), parity,
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
control, break signal, end-of-line markers, change case, padding, beep
if buffer overrun?, echo what you type to the screen, allow background
tasks to write to terminal?, define special (control) characters (such
as what key to press for interrupt).  See the <tt/stty/ man or info
page for more details.  Also see the man page: <tt/termios/ which
covers the same options set by stty but (as of mid 1999) covers
features which the stty man page fails to mention.
For use of some special characters see <ref
id="stty_chars" name="Special (Control) Characters">

With some implementations of getty (getty_ps package), the commands
that one would normally give to stty are typed into a getty
configuration file: /etc/gettydefs.  Even without this configuration
file, the getty command line may be sufficient to set things up so
that you don't need stty.

One may write C programs which change the stty configuration, etc.
Looking at some of the documentation for this may help one better
understand the use of the stty command (and its many possible
arguments).  Serial-Programming-HOWTO may be useful but it's outdated.
The manual page: termios contains a description of the C-language
structure (of type termios) which stores the stty configuration in
computer memory.  Many of the flag names in this C-structure are
almost the same (and do the same thing) as the arguments to the stty
command.

<sect2> Flow control options
<p> To set hardware flow control use "crtscts".  For software flow
control there are 3 settings: ixon, ixoff, and ixany.

ixany: Mainly for terminals.  Hitting any key will restart the flow
after a flow-control stop.  If you stop scrolling with the "stop
scroll" key (or the like) then hitting any key will resume scrolling.
It's seldom needed since hitting the "scroll lock" key again will do
the same thing.

ixon: Enables the port to listen for Xoff and to stop transmitting
when it gets an Xoff.  Likewise, it will resume transmitting if it gets
an Xon.

ixoff: enables the port to send the Xoff signal out the transmit line
when its buffers in main memory are nearly full.  It protects the
device where the port is located from being overrun.

For a slow dumb terminal (or other slow device) connected to a fast
PC, it's unlikely that the PC's port will be overrun.  So you seldom
actually need to enable ixoff.  But it's often enabled "just in case".

<sect2> Using stty at a "foreign" terminal
<p>How do you use stty to view or set a terminal other than the
terminal you are currently using?  It's usually impossible to do it if
the foreign terminal is in use and has a shell running on it.  In
other cases for dealing with say ttyS2 while typing at another
terminal (such as tty1) use <tt> stty -F /dev/ttyS2 ...</tt> (or
--file instead of F).  If ... is -a it displays all the stty settings
(-a means all).

But if the foreign terminal (ttyS2 in this example) has a shell
running on it, then what you see will likely be deceptive and trying
to set it will not work.  This problem exists for virtual terminals
also such as dealing with tty3 from tty1, etc.  See <ref
id="two_term_interfaces" name="Two interfaces at a terminal"> to
understand it.

<sect2> Two interface modes at a terminal <label id="two_term_interfaces">
<p> When using a shell (such as bash) with command-line-editing
enabled there are two different terminal interfaces (or line
disciplines: what you see when you type stty -a).  When you type in
modern shells at the command line you have a temporary "raw" interface
(or raw mode) where each character is read by the shell's
command-line-editor as you type it.  Once you hit the &lt;return&gt;
key, the command-line-editor is exited and the terminal interface is
changed from raw to the nominal "cooked" interface (cooked mode) for the
terminal using the stty configuration that was used for the last cooked
mode (the shell has saved it and it gets restored).  This cooked mode
lasts until the next prompt is sent to the terminal (which is only a
small fraction of a second) but it exists during the execution of the
command (or at least during the first stage of the command execution).
Note that one never gets to type any command into this cooked mode but
what was typed in raw mode on the command line starts execution by the
shell while in cooked mode.

When a prompt is sent to the terminal, the terminal goes from "cooked"
to "raw" mode (just like it does when you start an editor such as vim.
The prompt signals starting the command-line editor.  The settings for
the "raw" mode are based only on the basic stty settings taken from the
"cooked" mode.  Raw mode keeps these setting but changes several other
settings in order to change the mode to "raw".  It is not at all based
on the settings used in the previous "raw" mode (as contrasted to
"cooked" mode which gets restored by the shell to its previous
settings).  Thus if one uses stty to change settings for the raw mode,
such settings will be permanently lost as soon as one hits the
&lt;return&gt; key at the terminal.

Now when one types stty to look at the terminal interface, one may
either get a view of the cooked mode or the raw mode.  You need to
figure out which one you're looking at.  It you use stty from a
foreign terminal (other than the terminal you are currently typing at)
then you will likely see the raw mode settings since the terminal is in raw
mode almost all the time.  Any changes made will only be made to the raw
mode and will be lost when someone presses &lt;return&gt; at the foreign
terminal you tried to "set".  But if you type a stty command to
view/change the configuration of the terminal you are using, and then
hit &lt;return&gt; it's a different story.  The &lt;return&gt; puts the
terminal in cooked mode and your changes are saved by the shell before it
returns to raw mode.  Since going into raw mode doesn't change all stty
settings, some of the changes you made via stty may still be present in
raw mode and will not get destroyed by &lt;return&gt;.

This situation can create problems.  For example, suppose you corrupt
your terminal interface so that it's not displaying what you type, etc.
To restore it you go to another terminal (on the same PC) and type "stty
-F dev/ttyS1 sane" (or the like).  It will not work because the terminal
is in raw mode!  Of course you can try to type "stty sane ..." at the
terminal that is corrupted but you can't see what you typed.  All the
above not only applies to dumb terminals but to virtual terminals used
on a PC Monitor as well as to the terminal windows in X.  In other
words, it applies to almost everyone who uses Linux.

Luckily, when you start up Linux, any file that runs stty at boot-time
will likely deal with a terminal (or serial port with no terminal)
that has no shell running on it so there's no problem for this special
case.

<sect2> Where to put the stty command ? <label id="stty_where">
<p> Should you need to have <tt/stty/ set up the serial interface each
time the computer starts up then you need to put the <tt/stty/ command
in a file that will be executed each time the computer is started up
(Linux boots).  It should be run before the serial port is used
(including running getty on the port).  There are many possible places
to put it.  If it gets put in more than one place and you only know
about (or remember) one of those places, then a conflict is likely.
So make sure to document what you do.

One place to put it would be in the same file that runs setserial when
the system is booted.  The location is distribution and version
dependent.  It would seem best to put it after the setserial command
so that the low level stuff is done first.  If you have directories in
the /etc tree where every file in them is executed at boot-time
(System V Init) then you could create a file named "stty" for this
purpose.

<sect2> Obsolete redirection method
<p>Prior to about 2000 you needed to use the redirection operator "<"
if you wanted to use stty on a foreign terminal.  For example to use
stty on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2.
After 2000 (provided your version of setserial is >= 1.17 and stty >=
2.0) a better method was created using the -F option: stty -F
/dev/ttyS2.  This will work when the old redirection method fails.  

The old redirection example above makes ttyS2 the standard input to
stty.  This gives the stty program a link to the "file" ttyS2 so that
it may "read" it.  But instead of reading the bytes sent to ttyS2 as
one might expect, it uses the link to find the configuration settings
of the port so that it may read or change them.  In olden days, some
people tried to use ``stty ... &gt /dev/ttyS2'' to set the terminal.
This didn't work.  Instead, it takes the message normal displayed
by the stty command for the terminal you are on (say tty1) and sends
this message to ttyS2.  But it doesn't change any settings for ttyS2.

Here's a problem with the old redirection operator (which doesn't
happen if you use the newer -F option instead).  Sometimes when trying
to use stty, the command hangs and nothing happens (you don't get a
prompt for a next command even after hitting &lt;return&gt;).  This is
likely due to the port being stuck because it's waiting for one of the
modem control lines to be asserted.  For example, unless you've set
"clocal" to ignore modem control lines, then if no CD signal is
asserted the port will not open and stty will not work for it (unless
you use the newer -F option).  A similar situation seems to exist for
hardware flow control.  If the cable for the port doesn't even have a
conductor for the pin that needs to be asserted then there is no easy
way to stop the hang.

One way to try to get out of the above hang is to use the newer -F
option and set "clocal" and/or "crtscts" as needed.  If you don't have
the -F option then you may try to run some program (such as minicom) on
the port that will force it to operate even if the control lines say
not to.  Then hopefully this program might set the port so it doesn't
need the control signal in the future in order to open: clocal or
-crtscts.  To use "minicom" to do this you likely will have to
reconfigure minicom and then exit it and restart it.  Instead of all
this bother, it may be simpler to just reboot the PC or via using a
virtual terminal kill the process using "top" (or "ps" to get the
process number and then "kill" to kill that process.

The obsolete redirection method (which still works in later versions)
is to type ``stty ... &lt /dev/ttyS2''.   If the new method using -F
works but the obsolete one hangs, it implies that the port is hung due
to a modem control line not being asserted.  Thus the obsolete
redirection method might still useful for troubleshooting.
<!-- stty.D end -->


<sect1> Terminfo & Termcap (brief) <label id="termcap1">
<p> See <ref id="termcap2" name="Terminfo and Termcap (detailed)"> for
a more detailed discussion of termcap.  Many application programs that
you run use the terminfo (formerly termcap) data base.  This has an
entry (or file) for each model or type (such as vt100) of terminal and
tells what the terminal can do, what codes to send for various
actions, and what codes to send to the terminal to initialize it.

Since many terminals (and PC's also) can emulate other terminals and
have various "modes" of operation, there may be several terminfo
entries from which to choose for a given physical terminal.  They
usually will have similar names.  The last parameter of getty (for
both agetty and getty_ps) should be the terminfo name of the terminal
(or terminal emulation) that you are using (such as vt100).

The terminfo does more than just specify what the terminal is capable
of doing and disclose what codes to send to the terminal to get it to
do those things.  It also specifies what "bold" will look like (will
it be reverse video or will it be high intensity, etc.), what
the cursor will look like, if the letters will be black, white, or
some other color, etc.  In PC terminology these are called
"preferences".  It also specifies initialization codes to send to the
terminal (analogous to the init strings sent to modems).  Such strings
are not automatically sent to the terminal by Linux.  See <ref
id="init_string" name="Init String">.  If you don't like the way the
display on the screen looks and behaves you may need to edit (and then
update) the terminfo (or termcap) file.  See <ref id="tic"
name="Terminfo Compiler (tic)"> for how to update.

<sect1> Setting TERM and TERMINFO
<p> These are two environment variables for terminals: TERM and
TERMINFO, but you may not need to do anything about them.  TERM must
always be set to the  type of the terminal you are using (such as
vt100).  If you don't know the type (name) see <ref id="term_name"
name="What is the terminfo name of my terminal ?">.  TERMINFO contains
the path to the terminfo data base, but may not be needed if the
database is in a default location (or TERMINFO could be set
automatically by a file that comes with your distribution of Linux).
You may want to look at <ref id="tc_compiled_locs" name=" Compiled
database locations">.

Fortunately, the getty program usually sets TERM for you just before
login.  It just uses the terminal type that was specified on getty's
command line (in /etc/inittab).  This permits application programs to
find the name of your terminal and then look up the terminal
capabilities in the terminfo data base.  See <ref id="term_var"
name="TERM Variable"> for more details on TERM.

If your terminfo data base can't be found you may see an error message
about it on your terminal.  If this happens it's time to check out
where terminfo resides and set TERMINFO if needed.  You may find out
where the terminfo database is by searching for a common terminfo file
such as "vt100" using the "locate" command.  Make sure that your
terminal is in this database.  An example of setting TERMINFO is:
export TERMINFO=/usr/share/terminfo (put this in /etc/profile or the
like).  If the data for your terminal in this data base is not to your
liking, you may need to edit it.  See <ref id="termcap1"
name="Terminfo & Termcap (brief)">.

<sect2> What is the terminfo name of my terminal ? <label
id="term_name">
<p> You need the exact name in order to set the TERM environment
variable or to give to <tt/getty/.  The same name should be used by
both the termcap and terminfo databases so you only need to find it
once.  A terminal usually has alias names but if more than one name is
shown, use the first one.

To find it, try looking at the /etc/termcap... file (if you have it).
If not, then either look at the terminfo trees (see <ref
id="tc_compiled_locs" name=" Compiled database locations">) or try to
find the terminfo source code file (see <ref id="tc_source_loc"
name="Source-code database locations">.

<sect1> Rarely Needed /etc/ttytype File
<p> The configuration file /etc/ttytype is used to map /dev/ttySn's to
terminal names per terminfo.  tset/reset uses it, but if the TERM
environment variable is already set correctly, then this file is not
needed.  Since the Linux getty sets TERM for each tty, you don't need
this file.  In other Unix-like systems such as FreeBSD, the file
/etc/ttys maps ttys to much more, such as the appropriate getty
command, and the category of connection (such as "dialup").  An
example line of Linux ttytype: vt220 ttyS1

<sect1> Login Restrictions <label id="login_restr">
<p> By default, the root user may not login from a terminal.  To
permit this you must create (or edit) the file /etc/securetty per the
manual page "securetty".  To restrict logins of certain users and/or
certain terminals, etc. edit /etc/login.access (this replaces the old
/etc/usertty file ??).  /etc/login.def determines if /etc/securetty is
to be used and could be edited so as to make /etc/securetty not needed
(or not used).  /etc/porttime restricts the times at which certain
ttys and users may use the computer.  If there are too many failed
login attempt by a user, that user may be prohibited from ever logging
in again.  See the man page "faillog" for how to control this.

<sect1> Run Command Only If TERM=my_term_type
<p> Sometimes there are commands that one wants to execute at start-up
only for a certain type of terminal.  To do this for the stty command
is no problem since one uses the redirection operator < to specify
which terminal the command is for.  But what about shell aliases or
functions?  You may want to make a function for the ls command so it
will color-code the listing of directories only on color terminals or
consoles.  For monochrome terminals you want the same function name
(but a different function body) which will use symbols as a substitute
for color-coding.  Where to put such function definitions that are
to be different for different terminals?

You may put them inside an "if" statement in /etc/profile which runs
at startup each time one logs on.  The conditional "if" statement
defines certain functions, etc. only if the terminal is of a
specified type.

<sect2> Example for ls Function <label id="ls_color">
<p> While much of what this if statement does could be done in the
configuration file for dircolors, here's an example for the case of
the bash shell.  It makes the <em/ls/ command display colors if the
terminal is "linux" but uses <em/ls -F/ if you're using a dumb
terminal (VT220).  Note that the -F option uses symbols to give
information on file types just like color coding does. So there are
alternatives to using colors for the <em/ls/ command, although a color
display may look more impressive.

<code>
if [ "$TERM" = linux ]; then
    eval `dircolors`;
elif [ "$TERM" = vt220 ]; then
    ls () &lcub command ls -F $* ; &rcub
# to export the function ls():
    declare -xf ls
else echo "From /etc/profile: Unknown terminal type $TERM"
fi
</code>

<sect1> Character Mapping: mapchan <label id="mapchan_">
<p> There is a free program named "mapchan" which will map characters
(bytes) typed at a terminal keyboard (input) into different characters
per a user-supplied mapping table.  It can also map characters which
are sent to the screen (output).  This is nice for remapping the
keyboard for foreign language alphabets.  Most distributions don't
seem to supply it (let me know if any do).  Source code by Yura
Kalinichenko (Ukraine, partly in Russian ) <url
url="http://sourceforge.net/projects/mapchan/" name="download mapchan
etc.">

<sect>Terminfo and Termcap (detailed) <label id="termcap2">

<sect1> Intro to Terminfo

<p> Terminfo (formerly Termcap) is a database of terminal capabilities
and more.  For every (well almost) model of terminal it tells
application programs what the terminal is capable of doing.  It tells
what escape sequences (or control characters) to send to the terminal
in order to do things such as move the cursor to a new location, erase
part of the screen, scroll the screen, change modes, change appearance
(colors, brightness, blinking, underlining, reverse video etc.).
After about 1980, many terminals supported over a hundred different
commands (some of which take numeric parameters).

One way in which terminfo gives the its information to an application
program is via the "ncurses" functions that a programmer may put into
a C program.  For example, if a program wants to move the cursor to row
3, col 6 it simply calls: move(3,6).  The move() function (part of
ncurses) knows how to do this for your terminal (it has read
terminfo).  So it sends the appropriate escape sequence to the
terminal to make this particular move for a certain terminal.
Some programs get info directly from a terminfo files without using
ncurses.  Thus a Linux package that doesn't require ncurses may still
need a terminfo file for your terminal.

The terminfo abbreviations are usually longer than those of termcap
and thus it's easier to guess what they mean.  The manual pages for
terminfo are more detailed (and include the old termcap
abbreviations).  Also, the termcap entries had a size limitation which
is not present for terminfo.  Thus, unless you are already committed
to working with termcap, it's suggested you use terminfo.

<sect1> Terminfo Database <label id="database">
<sect2> Introduction
<p> The terminfo database is compiled and thus has a source part and a
compiled part.  The old termcap database has only a source part but
this source can, by a single command, be both converted to terminfo
source and then compiled.  Thus you may get by without having any
terminfo source since the termcap source can create the compiled
terminfo database.  To see a display of the database for the terminal
you're now using (including a PC monitor) type "infocmp" and you
should see the source terminfo "file" for it.

To see if your terminal (say vt100) is in the terminfo data base type
"locate vt100".  If you need to find the terminfo name for your
terminal, explore the listing of files in the compiled database or see
<ref id="term_name" name="What is the terminfo name of my terminal ?">

<sect2> Where is the database located ?
<sect3> Compiled database locations <label id="tc_compiled_locs">
<p> Typing "locate vt100" may show /usr/lib/terminfo/v/vt100,
/usr/share/terminfo/v/vt100, /home/.../.terminfo/v/vt100, and/or
/etc/terminfo/v/vt100.  All these are possible locations of the
compiled terminfo files.  Although the /etc/terminfo directory is not
a standard location for it, having a few terminal types there could be
useful in case the /usr directory is not accessible.  For example /usr
could be on a separate disk or partition that failed to mount.
Normally, programs that use your main terminfo data base are able to
find it if it's in at least one of the locations mentioned above.
Otherwise the environment variable TERMINFO may be set to the path to
this database.  Example: TERMINFO=/usr/share/terminfo

For the Debian Distribution of Linux, several commonly used terminals
(including the monitor-console) are in the ncurses-term package.
These are put into /etc/terminfo/.  All of the terminals in the
database are in the ncurses-bin package and go into
/usr/share/terminfo/.

If the compiled terminfo is in more than one location, everything is
usually OK until someone installs new terminfo files (from a newer
distribution, from the net, by editing the old one, etc.).  Each new
terminfo file should replace all the existing older copies of that file
(at various locations) unless you abolish redundant locations.  If you
don't ensure this gets done, then some application programs could wind
up still finding and using the old (and possibly buggy) terminfo data
that sill exists in a "possible" location.  Setting the environment
variable TERMINFO to the up-to-date location (as mentioned above)
would help avoid this problem.

<sect3> Source-code database locations <label id="tc_source_loc">
<p> While the source-code file may  not be installed on your computer
there's another way to get the source-code if you have the compiled
code.  Just use the "<tt/infocmp/" command.

The source code file (for all terminals) may be /etc/termcap and/or
terminfo.src (or another name).  See the man pages: terminfo(5) or
termcap(5) for the format required to create (or modify) these source
files.  The file terminfo.src may be in various locations on your
computer or it may not be included with your Linux distribution.  Use
the <tt/locate/ command to try to find it.  It is available on the web
at <url url="http://catb.org/terminfo/">.

<sect2> Terminfo Compiler (tic) <label id="tic">
<p> The data in the source files is compiled with the "tic" program
which is capable of converting between termcap format and terminfo
format.  Thus you can create a compiled terminfo data base from
termcap source.  The installation program which was used to install
Linux probably installed the compiled files on your hard disk so you
don't need to compile anything unless you modify /etc/termcap (or
terminfo.src ).  "tic" will automatically install the resulting
compiled files into a terminfo directory ready to be used by
application programs.  Which location it's installed in depends on ...
See "man tic" for the explanation.

<sect2> Look at Your Terminfo <label id="infocmp">
<p> It's a good idea to take a look at the terminfo entry for the
terminal you are using (source code of course) and read the comments.
A quick way to inspect it without comments is to just type "infocmp".
But the comments may tell you something special about the terminal
such as how you need to set it up so that it will work correctly with
the terminfo database.

<sect2> Deleting Data Not Needed
<p> In order to save disk space, one may delete all of the terminfo
database except for the terminals types that you have (or might need
in the future).  Don't delete any of the termcaps for a "Linux
terminal" (the console) or the ones used for x-terminal-emulation
such as xterm.  The terminal type "dumb" may be needed when an
application program can't figure out what type of terminal you are
using.  It would save disk space if install programs only installed
the terminfo for the terminals that you have and if you could get a
termcap for a newly installed terminal over the Internet in a few
seconds.

<sect1> Bugs in Existing Terminfo Files (and Hardware)
<p> Unfortunately, there are a number of bugs in the terminfo and
termcap files.  In addition, many of these terminfo files are
incomplete and do not define certain features available on the
terminals.  Sometimes you can get by without modifying the terminfo
but in other cases you need to modify it or possibly use another
emulation that has a good terminfo.

The sad state of the supplied terminfo files is due to a number of
reasons.  One is that during the 1980's when many of them were written
(often in termcap format), application programs did not utilize more
advanced terminal features.  Thus if such feature were not in the
termcap (or terminfo) file, no one complained.  Also, writing termcaps
was often done by volunteers who were in short supply.  Today,
programs such as vim use "context highlighting" and minicom uses the
terminal's graphics character set.  These often need more definitions
to be added to the old termcap.  This may (or may not) have already
been done.

Most terminals had hardware bugs (in their firmware) and sometimes
these were "fixed" by modifying the termcap.  Then the manufacturer
might send out replacement chips which would fix the bug.  Not all
owners would bother to get the replacement chips.  Thus there may be 2
or more terminfos for your terminal, depending on what firmware chips
it has in it.  This situation was often not noted in the termcap and
only one of these termcaps may be supplied with Linux.  Some hardware
bugs which existed for features that were almost never used in the
past likely never did get fixed.  Also, some reported hardware bugs
may never have been fixed since they were not of much significance at
the time or because the terminal manufacturing company went out of
business, etc.

<sect1> Modifying Terminfo Files
<p> To do this you need a manual for your terminal showing what escape
sequences it uses.  Newer manuals from the 1990's often don't show
this.  You also need a terminfo manual (the man page "terminfo" is
one).  After you edit the terminfo source file you compile it using
"tic".  "tic" should automatically put the compiled terminfo file in
the correct directory reserved for it.

If you would like to find a better terminfo entry for a certain terminal
than the one supplied, you might try searching the Internet (but what
you find could be worse).  If your new terminfo entry is better than
the old one and it seems stable (you've used it for a while with no
problems) then you should send a copy to the maintainer of terminfo as
noted at the start of the source file for terminfo (or termcap).

<sect1> Init String <label id="init_string">
<p> Included in the terminfo are often a couple of initialization
strings which may be sent to the terminal to initialize it.  This may
change the appearance of the screen, change what mode the terminal is
in, and/or make the terminal emulate another terminal.  No
initialization string is automatically sent to the terminal to
initialize it.  One might expect that the getty program should do
this.  If it did, one could make a change to the set-up stored inside
the terminal but this change wouldn't happen because the init string
would override it.  Application programs don't seem to initialize
(send an init string per terminfo) either.

To actually send an init string you must use a command given on the
command line (or in a shell script such as /etc/profile).  Such
commands are: "reset" "tset", "tput init", or "setterm -initialize".
Sometimes there is no need to send an init string since the terminal
may set itself up correctly when it is powered on (using
options/preferences one has set up and saved in the non-volatile
memory of the terminal).

<sect1> TERM Variable <label id="term_var">
<p> The Environment variable TERM should be set to the name of
terminal which you are using.  If TERM hasn't been set yet and you
don't know the name of your terminal see <ref id="term_name"
name="What is the terminfo name of my terminal ?">.  It is normally
set by the terminal_type parameter passed to the getty program (look
at it in the /etc/inittab file).  This name must be in the Terminfo
data base.  Just type "set" at the command line to see what TERM is
set to (or type: tset -q).  At a console (monitor) TERM is set to
"linux" which is the PC monitor emulating a fictitious terminal model
named "linux".  Since "linux" is close to a vt100 terminal and many
text terminals are also, the "linux" designation will sometimes work
as a temporary expedient with a text terminal.

If more than one type of terminal may be connected to the same port
(/dev/ttyS...) (for example, if there is a switch to permit different
terminal types to use the same serial port, or if the port is
connected to a modem to which people call in from different types of
terminals) then TERM needs to be set each time someone connects to the
serial port.  There is often a query escape sequence so that the
computer may ask the terminal what type it is.  Another way is to ask
the user to type in (or select) the type of terminal s/he is using.
You may need to use tset for this or write a short shell script to
handle this.

<label id="reset_">
One way to do this is to use "reset" (same as "tset"; see the manual
page).  reset tries to determine the terminal name of the terminal you
are using.  Then it looks up the data in terminfo and sends your
terminal an init string.  It can also set the value of TERM.  For
example, a user dials in and logs in.  The .profile login script is
executed which contains within it the following statement: eval `tset
-s ?vt100`.  This results in: The user is asked if s/he is using a
vt100.  The user either responds yes or types in the actual terminal
type s/he is using.  Then "reset" sends the init string and sets TERM
to this terminal name (type).

<sect1> Terminfo/Termcap Documents <label id="termcap_docs">
<p> <itemize>
<item> manual pages for terminfo(5) (best) and/or termcap(5).
<url url="http://www.delorie.com/gnu/docs/termcap/termcap_toc.html"
 name="The Termcap Manual"> (2nd ed.) by Richard M. Stallman is a GNU
 manual also known as the "Termcap Library".  It's somewhat obsolete
 since it doesn't include terminfo.  It's also at:
<url
url="http://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html"
name="Termcap Library">
<item> the files: terminfo.src and
 /etc/termcap have info about various versions of termcap files,
 naming conventions for terminals, and special capabilities code named
 u6-u9. If you don't have one, go to <url
 url="http://catb.org/terminfo/">
<item> "Termcap and Terminfo" is a book published by O'Reilly in
 1988.
</itemize>

<sect> Using the Terminal

<sect1> Intro to Using the Terminal
<p> This section is about controlling the terminal-computer interface
and/or changing the terminal set-up while using the terminal.  It
explains (or points to explanations of) how the user of a terminal can
control and inspect the interface and how to use various commands
provided by the device driver.  It does not explain how to use the
many application programs, shells or most Linux utilities.  Two
commands commonly used at the terminal are:

<itemize>
<item> clear (to clear the screen)
<item> reset (to reset the terminal
<item> setterm -reset (alternative for "reset" in case of bug)
</itemize>

<sect1> Starting Up the Terminal
<p> Of course the power must be on for the terminal to work.  If you
don't see a login prompt hit the "return" (or "enter") key a few times.
Then type your account name (followed by a return/enter) and your
password when prompted for it (also followed by return/enter).  Make
sure not to type all capital letters.  If you do, the computer may
think that you have an old terminal that can't send lowercase letters
and the serial driver may set itself up to send only capital letters
to the terminal.

If nothing happens, make sure that both the host computer and the
terminal are OK.  If the host computer is shut down (no power) what
you type at the terminal keyboard may appear on the screen since the
transmit and receive pins at the computer may be connected together
resulting in echoing of characters by an "off" computer.  If you can't
log in when the host computer is running, see <ref id="trouble_shoot"
name="Trouble-Shooting">.

<sect1> Terminal (Serial) Device Driver
<p> When typing at the command line, the shell (such as the Bash
shell) is reading what you type and reacting to it.  What you type
first passes thru the terminal driver part of your operating system.
This driver may translate certain characters (such as changing the
"return" character generated by the "return" key into a "new-line"
character for Linux files).  It also recognizes certain control codes
which you may type at the keyboard such as ^C to interrupt the
execution of a program.  It also normally echoes what you type back to
the display.   <ref id="stty_" name="Stty"> may be used to configure
how this terminal driver behaves, including disabling some (or all) of
its functionality.

<sect1> Problems with Editors
<p> There may be some problems with using both emacs and vi on some
terminals.  A few terminals have no escape key (ESC) so you may need
to type Ctrl-[ to get ESC.

<sect2> emacs
<p> If software flow control exists, then the ^S command in emacs will
freeze the display.  The ^Q command will unfreeze the display.  One
fix is to map this to another key-press by configuring emacs that way.
Some terminals have meta keys although you may need to setup the
terminal to create a meta key.

<sect2> vi and Cursor-Keys <label id="vi_k_keys">
<p> Vi uses the esc-key as a command to exit insert mode.
Unfortunately for most terminals the arrow-keys send an escape
sequence (starting with the ESC character) to the host.  Vi must
distinguish between these two meanings of ESC.  A smart vi (such as
vim if configured for it) is able to detect the difference by noting
the time between the ESC and the next key.  If it's a short time, then
it's likely that a cursor key was pressed.  Use "help cursor-keys" in
vim to find out more.

Here's another way to fix this.  On VT terminals the left-arrow-key
may be either set to send ESC [ D or ESC O D.  The other arrow keys
are similar but use A, B, and C instead of D.  If you're having
problems, choose ESC [ D since the "O" in the other alternative could
be interpreted by vi as a command to "Open a line".  The "[" should be
interpreted by vi to mean that an arrow-key has been pressed.  ESC [ D
will be sent provided "Cursor Key Application Mode" has not been set.
ESC [ D is normally the default so everything is seemingly OK.  Except
that many termcaps contain a string (not the init string) which sets
what you want to avoid: "Application Mode".  Editors may send this
string to the terminal when the editor starts up.  Now you are in
trouble.

This string has the termcap code "ks" (smkx in terminfo) meaning
enable the function (and related) keys (including the arrow keys).  An
application enables these keys by sending the "ks" string to the
terminal.  Whoever wrote the termcap reasoned that if an application
wants to enable these keys, then they should be put into "Application
Key Mode" since this is an "application", but you don't want this.

The Linux console has no "ks" string so you can't fall into this trap
at the console.  For other terminals you may need to edit the termcap
(or terminfo) or use another termcap entry.  You need to change not
only the "ks" string but also the termcap definitions of what they
send: kd, kl, kr, ku.  Then run tic to install it.

For vim (vi iMproved) there is a way to set it up to work OK with ESC
O D (so you don't need to edit termcap): See vim help for
"vt100-cursor-keys".  You may run "gitkeys" and then press your cursor
keys to see what they send but they may be set to send something
different when you're in an editor.

<sect1>Problem with Slow Scrolling <label id="slow_scroll">
<p>The scrolling speed of the text terminal is limited by the speed
over the serial line.  This limitation is good in one respect since
the scrolling speed is slow enough that you can almost read what is
scrolling on the screen before it disappears off the bottom of the
screen.

But there is a downside to this.  For example, if you copy a large
number of files (like everything on your hard drive) and use options
to display the full name (path name) of each file copied, then the
speed limitations of the serial line may only display 30 files per
second on the screen.  But your hard drive can copy many times faster
than this but the terminal will slow down the transfer to the speed at
which it can be displayed by the terminal.  It does this by
<ref id="flow_control" name="Flow Control">.

The fix is to disable "progress" information being displayed on the
screen for cases where it slows down the "progress".  If it just
updates progress numbers a few times per second or less, it shouldn't
be a problem.

<sect1> Bugs in Bash ? <label id="bash_bug">
<p> One problem still outstanding is that if certain terminal keys
send bytes with the high order bit set to 1, then Bash seems to ignore
the meaning for them as defined in a terminfo entry.  This may be
because, unless one is using 7-bit ASCII, bytes with the high order
bit set to 1, may represent a non-English letter.  I reported this as
a bug in Bash (but years later realized that it may not have been a
bug).  Other programs such as the vim editor and the lynx browser work
OK with such keys (when they are set to use 7-bit ASCII).

To work around this problem, one may define what these keys should do
in Bash by putting such definitions into <tt>/etc/inputrc.</tt>  For
example, A Wyse 60 will send D0-D3 when the arrow-keys are hit
provided the terminal is in "application key mode".   After modifying
the terminfo to reflect this, they still wouldn't work on the command
line in the Bash shell.  So I explicitly defined the arrow-keys in
<tt>/etc/inputrc</tt> like this:

<tscreen><verb>
# Arrow keys in 8 bit keypad mode: Sends d0-d3.  -ap means application.
$if term=wy60-25-ap
set enable-keypad on
"\xd0":		backward-char
"\xd1":		forward-char
"\xd2":		next-history
"\xd3":		previous-history
$endif
</verb></tscreen>

If the terminal is already in "application key mode" there's no need
to "set enable-keypad on".  enable-keypad will send the terminal the
escape sequence named smkx in terminfo (which for wyse60 is \E&tilde;3
and makes the arrow keys send D0-D3).  Many other applications  (other
than Bash) send this without needing to be told to do so.

<sect2>A fixed Bash bug
<p>There have been problems with the readline interface to the Bash
shell.  Bash 2.01 (1998) had a readline interface which was quite
corrupted if one used a dumb terminal.  This was fixed in later
versions.  

<sect1>Color ls Corruption
<p> If <tt/ls/ is corrupting your terminal emulation with the color
feature, turn it off.  <tt/ls --color/, and <tt/ls --colour/ all use
the color feature.  Some installations have <tt/ls/ set to use color
by default.  Check <tt>/etc/profile</tt>, etc.  for <tt/ls/ aliases.
See <ref id="ls_color" name="Example for ls Function"> for how to
have <tt/ls/ do color for the console and do monochrome for terminals.

<sect1> Display Freezes (hung terminal) <label id="display_freezes">
<p> The symptom of a hung terminal is where what you type doesn't display
on the terminal (or in some cases displays but doesn't do anything).
If what you type is invisible (or does nothing) type ^Q to restart flow
(if flow control stopped it).  Hanging may also be due to:<newline>
<ref id="sent_bin" name="Sent terminal binary"> or
<ref id="abnormal_exit" name="Abnormally exited a program"><newline>
If you didn't do any of these two, then the program you're running
could by buggy or you interaction with it fatally illegal.

If you want to quit the program you were running and you can't do it
by the usual methods (some programs have special keys you must hit to
exit) then try killing it from another terminal using "top" or "kill".
If the process refuses to die, then kill it with signal 9 from top (or
use "kill" on the command line). The "9" type of forced exit may leave
some temporary files lying around as well as a corrupted interface.
If this doesn't work, killing the login shell should result in a
startup of getty with a new login prompt.  If all else fails, you may
need to reboot the computer or even power it down.  Just rebooting may
not alter the possibly corrupted content of the serial port hardware
registers.

<label id="ctrl_s">
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No
Scroll" key) which mysteriously freezes the screen (although that is
what this key is supposed to do if you use software flow-control).  To
restore normal screen interaction, press Ctrl-Q (^Q).  Note that
everything typed during the "freeze" gets executed but you don't see
any report of this until you hit ^Q.  Thus when it's frozen, don't
type anything drastic that might destroy files, etc.  One argument for
using hardware flow-control is to prevent such freezes.

<sect1> Corrupted Terminal Interface <label id="corrupt_interface">
<p> This includes the case of a "frozen display" = "hung terminal" of
the previous section.

<sect2> Symptoms and some fixes <label id="symptoms_">
<p> When the display doesn't look right, or when what you type doesn't
display correctly (if at all), or nothing happens when you type a
command, you may have a corrupted terminal interface.  In rare cases,
when the serial port hardware gets itself corrupted, the only fix may
be to cycle power (turn off the PC and reboot).  In some cases just
cycling power for the terminal will fix it.  Sometimes logging in again
will solve the problem.  To do this, kill the shell process running on
the terminal (or kill getty if it's running).  You may do this from
another terminal.  Once killed, a new getty process respawns which
hopefully will end the corruption.  Recycling power (or resetting) for
the terminal may help too.

The corruption may be due to things such as:
<itemize>
<item>A bug in the program you're using (including a program which
 erroneously assumes that you are using a terminal of type "linux")
<item>A hardware failure (including an obscure hardware defect that
 you can normally live with)
<item>Incorrect configuration (including an error in the terminfo or
 the terminal type)
</itemize>
If everything was working normally but it suddenly goes bad, it may be
that the interface got corrupted by something you did.  Three mistakes
you might have made to corrupt the interface are:

<itemize>
<item> <ref id="sent_bin" name="Sent terminal binary">
<item> <ref id="abnormal_exit" name="Abnormally exited a program">
<item> <ref id="ctrl_s" name="Typed ctrl-S by mistake">
</itemize>

<sect2> Sent terminal binary characters <label id="sent_bin">
<p> Your terminal will change its characteristics if sent certain
escape sequences or control characters.  It you inadvertently try to
display a binary file, it might by chance contain such sequences which
may put your terminal into some strange mode of operation or even make
it unusable.  Always view or edit a binary file with programs designed
for that purpose so that this doesn't happen.  Most editors and pagers
will handle binary OK so as not to corrupt the interface.  Some may
display a message telling you that they can't edit binary.  But you're
likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or
run a program which sends binary output to "standard output" (unless
you redirect such output with >, etc.).

Corruption can also happen when using a communications program where
a remote computer may send binary to your screen.  There are numerous
other ways it can happen so be prepared for it.  Even a supposedly
text file could contain unwanted control codes.

To fix this problem reset the terminal.  Type either just "reset" or
"tset" or "setterm -reset" (followed by a &lt;return&gt of course --
what you type will likely not be readable on the screen).  This will
send the reset string from the terminfo entry to the terminal.  As an
alternative to this, if the correct set-up has been saved inside the
terminal then pressing a special key(s) (perhaps in setup mode) may
restore the settings.  Then you might still need to use "reset" to send
the init string if you use it to set up your terminal.

<sect2> Reset command was broken but now fixed
<p>Note that in 2000 the "reset" command appeared to be broken for
terminals that needed "clocal" set since "reset" seemed to unset
"clocal".  In 2001 it appears to be fixed so you may not need to read
the rest of this paragraph.  If you have this problem, using "reset"
will only make the situation worse by disabling communication between
the terminal and computer.  You will likely need to log in again and
hope the getty sets "clocal".  If you see a login prompt without
asking for it, you're in luck.  Otherwise see <ref id="symptoms_"
name="Symptoms and some fixes"> for how to get a login prompt.  You
should try out "reset" before you need it and use "setterm -reset" if
"reset" logs you out or otherwise doesn't work right.  I submitted a
bug report in Mar. 2000 but never got a "fixed" notice.

<sect2> Character corruption
<p>For the case where you see strange "graphic" characters instead of
the normal ones, pressing ^O may switch back to the normal letters.
The "reset" command also does this but it resets everything else too.

There's the case where all letters have the wrong attribute (too dim,
bright, blinking, or even invisible :-) but the whitespace created by
tab characters is normal.  This was caused by an escape sequence which
set this attribute but the attribute doesn't apply to the whitespace
created by tab characters.  Fix by resetting, etc.

<sect2> Abnormally exited a program <label id="abnormal_exit">
<p> Large application programs (such as editors) often use the stty
command (or the like) in their code to temporarily change the stty
configuration when you are running the program.  This may put the
device driver into "raw" mode so that every character you type goes
directly thru to the application program.  Echoing by the driver is
disabled so that everything you see on the screen comes directly from
the application program.  Thus many control commands (such as ^C) may
not work within such applications.

When you tell such an application to quit, the application program
first restores the stty settings to what they were before the
application program started.  If you abnormally exit the program then
you may still be in "raw mode" on the command line.  You should
suspect this has happened when what you type no longer displays on the
screen.

To get out of raw mode and restore the normal stty settings type "stty
sane".  However, you must type this just after a "return" and end it
with a "return".   But hitting the "return" key doesn't do the job
since the "return" code no longer gets translated to the new-line
characters that the shell is waiting for.  So just type new-line (^J)
instead of "return".  The "sane" terminal interface may not be exactly
the same as the normal one but it usually works.  "stty sane" may also
be useful to get out of a corrupted interface due to other causes.

<sect1> Special (Control) Characters <label id="stty_chars">
<p> A number of control characters which you may type at the keyboard
are "caught" by the terminal driver and perform various tasks.  To see
these control commands type: stty -a and look at lines 2-4.  They are
tersely explained in the stty manual pages.  They may be changed to
different control characters or disabled using the stty command.  Thus
your control characters might be different than those described below.
They are used for command-line editing, interrupting, scrolling, and
to pass the next character thru transparently.

<sect2> Command-Line Editing
<p> While the terminal driver has a few commands for command-line
editing, some shells have a built-in real editor (such as "readline"
in the Bash shell).  Such an editor is normally on by default so you
don't need to do anything to enable it.  If it's available you don't
need to learn many of the following commands although they often still
work along with the command-line editor.  The most important to learn
are ^C (interrupt), ^D, and how to stop scrolling.

<itemize>
<item> Delete-key (shown by stty as ^?) erases the last character
<item> ^U kills (deletes) the line
<item> ^W deletes a word backwards
<item> ^R reprints the line.  Useful mainly on hard copy terminals ??
</itemize>

<sect2> Interrupting (& Quit, Suspend, EOF, Flush)
<p> <itemize>
<item> ^C interrupts.  Exits the program and returns you to the
 command-line prompt.
<item> ^\ quits.  Same as interrupt.  Also may dump a "core" file
 (which you likely have no use for) into your working directory.
<item> ^Z suspends.  Stops the program and puts it in the background.
 Type fg to restart it.
<item> ^D end of file.  If typed at the command-line prompt, exits the
 shell and goes to where you were before the shell started.
<item> ^O flush (or discard).  Not yet implemented in Linux (but
 proposed).  Sends output to /dev/null.
<item> ^T display driver status.  Not yet implemented in Linux (but
 proposed).  Displays a status line for the interface (number of bytes
 sent, etc.).
</itemize>

<sect2> Stop/Start Scrolling
<p> If what you want to see scrolls off the bottom of the screen,
you may prevent this by sending a "stop" signal (^S or Xoff) to the
host (provided Xon-Xoff <ref id="flow_control" name="Flow Control"> is
enabled).  Send a "start signal to resume (^Q or Xon).  Some terminals
have a "No Scroll" key which will alternately send Xoff and Xon or
possibly send the hardware flow control signals ??   Here's what
ctrl-S (^S) and ctrl-Q (^Q) do:

<itemize>
<item> ^S stops scrolling (Xoff)
<item> ^Q resume scrolling (Xon)
</itemize>

If you want to both stop scrolling and quit, use ^C.  If you want to
stop scrolling to do something else but want to keep the program that
was generating the output in memory so you can resume scrolling later,
use ^Z suspend.

An alternative scrolling method is to pipe the output thru a pager
such as more, less, or most.  However, the output might not be
standard output but could be error output which the pager doesn't
recognize.  To fix this you may need to use redirection "2>&1" to get
the pager to work OK.  It is often simpler to just use ^S and ^Q
unless you need to scroll backwards.

At a PC console (emulating a terminal) you may scroll backwards by
using Shift-PageUp.  This is frequently needed since the scrolling is
often too fast to stop using ^S.  Once you've scrolled backwards
Shift-PageDown will scroll forward again.

<sect2> Take next character literally
<p> ^V sends the next character typed (usually a control character)
directly thru the device driver with no action or interpretation.
Echoed back are two ASCII characters such as ^C.

<sect1> Viewing Latin1 Files on a non-Latin1 terminal
<p> Some "text" files are 8-bit Latin1 (=ISO-8859-1).  See <ref
id="char_sets" name="Character-Sets">.  If you have a terminal that
will not display Latin1 (or don't have the Latin1 character set
installed), then certain symbols (such as a bullet) will display wrong.
When viewing manual pages (they are Latin1) you may give the option -7
to man so as to translate everything to ASCII.  Are there some pagers
that make these translations ??

<sect1> Eliminating Overstriking in Files
<p>If one uses the "man" command to view a manual page but instead
redirects the output to a file, that file will have overstrikes in it.
Overstrikes are where some printed characters appear bold by printing
them twice in the same location.  Thus to print an overstrike
character the file contains a backspace after the character and then
the same character repeated.  If this is in a file, it's fine if you
are going to print it on a printer (unless the normal output from the
printer is so darks that overstriking makes little improvement).   But
it's not so good if you want to use the file to email or edit.

One way to get rid of the overstrikes is to use the "ul" (underline)
command.  You type: ul -t dumb my_overstruck_file > output_file
The ul command converts overstrikes to bold for whatever terminal is
specified and adds escape sequences to the output_file to generate the
bold.  But the terminal of type "dumb" has no escape sequences so you
get the desired result.  There are other ways to do this but this is a
possible use for a terminal of type "dumb".

<sect1> Inspecting the Interface
<p> These utility programs will provide information about the terminal
interface:
<itemize>
<item> gitkeys: shows what byte(s) each key sends to the host.
<item> tty: shows what tty port you are connected to.
<item> set: shows the value of TERM (the terminfo entry name)
<item> stty -a: shows all stty settings.
<item> setserial -g /dev/tty?? (you fill in ??) shows UART type, port
	address and IRQ number.
<item> infocmp: shows the current terminfo entry (less comments)
</itemize>

<sect1> Changing the Terminal Settings <label id="term_settings">
<p> The terminal settings are normally set once when the terminal is
installed using the setup procedures in the terminal manual.  However,
some settings may be changed when the terminal is in use.  You
normally would not give any "stty" or "setserial" commands when the
terminal is in use as they are likely to corrupt the terminal
interface.  However, there are changes you may make to the appearance
of the terminal screen or to its behavior without destroying the
integrity of the interface.  Sometimes these changes are made
automatically by application programs so you may not need to deal with
them.

One direct method of making such changes is to use the setup key (or
the like) at the terminal and then use menus (or the like) to make the
changes.  To do this you may need to be familiar with the terminal.
<label id="setterm_"> <label id="tput"> The other 3 methods send an
escape sequence from the computer to the terminal to make the changes.
These 3 examples show different methods of doing this to set reverse
video:

<enum>
<item> setterm -reverse
<item> tput -rev
<item> echo ^&lsqb&lsqb;7m
</enum>

<sect2> setterm
<p> This is the easiest command to use.  It uses long options (but
doesn't use the normal -- before them).  It consults the terminfo
database to determine what code to send.  You may change the color,
brightness, linewrap, keyboard repeat, cursor appearance, etc.

<sect2> tput
<p> The "tput" command is similar to "setterm" but instead of using
ordinary words as arguments, you must use the abbreviations used by
terminfo.  Many of the abbreviations are quite terse and hard to
remember.

<sect2> echo
<p> In the example "echo ^&lsqb&lsqb;7m" to set reverse video, the
^&lsqb is the escape character.  To type it type ^V^&lsqb (or ^V
followed by the escape key).  To use this "echo" method you must find
out what code to use from a terminal manual or from terminfo or
termcap.  It's simpler to use setterm or tput if you are typing on the
command line.  Since "echo ..." will execute faster (since it doesn't
do any lookups) it's good for using in shell scripts which run at
start-up, etc.

<sect2> Saving changes
<p> When you turn off the terminal the changes you made will be lost
(unless you saved them in non-volatile terminal memory by going into
set-up mode and saving it).  If you want to use them again without
having to retype them, put the commands in a shell script or make it a
shell function.  Then run it when you want to make the changes.  One
way to make the changes semi-permanent is to put the commands in a
file that runs each time you login or start up the computer.

<sect1> Multiple Sessions
<p> The "<tt/screen/" package runs multiple sessions something like
virtual terminals on the console: See <ref id="console_dev" name="The
Console: /dev/tty?">.  You can switch back and forth between the
sessions.  The non-free Facet Term software also does this.  See <url
url="http://www.facetcorp.com/ft_overview.html" name="FacetTerm">

<sect1> Logging Out
<p> To log out type either "logout" or "exit".   Under some
circumstances your request will be refused, but you should be told why.
One reason for refusal is if you are not in the same shell that
you logged into.  Another way to log out is to press ^D.  Since ^D is
also used for other purposes, you may not want it to log you out.  If
you set IGNOREEOF in the Bash shell then ^D will no longer log you
out.

<sect1> Chatting between Terminals, Spying
<p> If two persons logged into terminals on the same host computer
want to chat with each other they may use the "write" or the "talk"
(better) program.  One may prevent anyone (except the superuser) from
writing (sending messages) to their terminal by using the "mesg"
command.

For spying on what someone else is doing at their terminal use the
"ttysnoop" program.  In "ttysnoop" the two terminals have the same
status and anything typed on either keyboard appears on both screens
(in the same location).  So if you're really spying and don't want to
be detected, you shouldn't type anything.

"ttysnoop" can be used for training with instructor and trainee
sitting side-by-side, each at their own terminal.  The instructor may
watch what the trainee is typing and can correct any mistakes by
typing it correctly.  The trainee can watch what the instructor types
and then try typing it.  It's just like they used one terminal with
both people having their hands on the keyboard at the same time.

There's one shortcoming to "ttysnoop" and that is that the terminals
involved should all be (or emulate) the same type of terminal (such as
vt100).  Since the "Linux" emulation done by a console (monitor) and
the "minicom" (or "picocom") emulation are close to vt100 one may use
ttysnoop using two PCs, one running "minicom" which emulates a
terminal.

There's a non-free program called "DoubleVision" that is something
like ttysnoop but does much more.  Terminals may be of different types
and it can remember and playback sessions on terminals so you can
observe what happened in the past.  The webpage is at <url
url="http://www.tridia.com">.

<sect1> Sharing the Serial Port
<p> It's possible to use the same serial port for both a text-terminal
and another serial device such as a printer or modem.  Making the
physical connection is easy using one of these methods: 
<itemize>
<item> Just unplug the terminal cable and plug in the other device
<item> Use an AB switch to switch between the terminal and other
device (uses 3 cables)
<item> Use the printer (or aux) port on the terminal for the other
device
</itemize>

When you are not using the serial port for a terminal, then you need
to make sure that no characters intended for the terminal are sent to
the other device by mistake.  One unsafe way to do this is to let the
programs running on the terminal keep running, provided they don't
send out anything for the terminal when you are using the other
device.  This sometimes works since a terminal running on a serial
port doesn't prevent another program (process) from opening the same
port.  This sometimes works if the other device is a printer.  But if
the other device should send bytes to the serial port on the computer,
then the program(s) for the terminal which are still running on the
port will often send back some bytes for the terminal which will
actually go to the other device as garbage.

To avoid this, it's best to kill all programs (processes) running on
the terminal before using the other device.  This is not quite as easy
as it sounds.  You normally have a shell (such as Bash) running on the
port and if you kill Bash (by logging out for example) then the
program "getty" will start up on the port to try to log you in again.
If you kill getty, it will respawn and start up again.  So at first
glance it seems impossible to kill all processes on the terminal's
serial port.

One way to work around this problem is to switch runlevels so that no
getty program or shell is running on the port.  For the runlevel fix,
you may create another runlevel in which no getty program runs on the
port.  Then you enter this new runlevel and use the serial port for
something else.  To set this up you need to edit <tt>/etc/inittab</tt>
and check and/or set the runlevels at which getty runs.  For example
the line: <tt>"S1:23:respawn:/sbin/getty</tt> ..." means that getty
will run (on ttyS1) in runlevels 2 and 3.  Now you could have it only
run in level 2 (by deleting "3") and then go to runlevel 3 when you
want to use the other serial device.  Thus to use the serial port for
something else, the super-user would type "init 3" to switch to
runlevel 3.  Type "init 2" to get back to runlevel 2.  Note that each
runlevel may have a different set of initialization scripts but you
can change this if you want, so that the same scripts are run in both
runlevels.  How the scripts and runlevels work are distribution
dependent.  For the Debian distribution, the explanation of this is in
<tt>/usr/doc/sysvinit</tt>, but also look in <tt>/usr/share/doc.</tt>

There's also the problem of the stty configuration of the port.  When
the port is being used for the terminal it has certain configurations but
when say "init 3" is used to switch runlevels and disable getty on the
port, the original (boot-time) configuration of the port is not
restored.  You are likely to wind up with the port configured in a
"raw" mode.  This means that the serial port likely needs to be fully
reconfigured by stty, either by a script you write or by the next
application which runs on the port.  Some applications such as
printing from the serial port may not capable of fully reconfiguring.
The obsolete version of /etc/printcap could only partially reconfigure
(but the new one under "lprng" can).  Thus you might need to write a
script to do it.  The stty configuration of a terminal will be
different depending on whether a shell is running on it, whether it's
at the "login" prompt, etc.  Thus the stty configuration after
switching runlevels may vary.

<sect1>Browsers for Text-Terminals
<p>See <url url="http://www.linuxjournal.com/article/8148" name="2005 
Text Mode Browser Roundup"> for a review of text browsers.

The "lynx" browser works correctly with all text terminals.  There
are some other text browsers: "w3m", "links2" (formerly "links",  and
"elinks" that only work perfectly with the Linux console, xterm, or
vt100 terminals.  But links2 and elinks will work with any terminal by
classifying the type as dumb like the <ref id="early_terms"
name="first terminals">.  However, such an interface is slower.

The "netrik" browser requires a color terminal.  For "links2" and
"elinks" you must set your terminal to 8-bits with no parity. (I filed
a bug report years ago for elinks since it should work with parity and
finally in 2008 I got a message that it was fixed in version 0.13
and might become fixed in 0.11 and 0.12 also).  All (including netrik
??) support ssl (secure socket layer) for encoded communication.

"w3m", "links2", and "elinks" overcome some of the "lynx" deficiencies.
"elinks" is just a more advanced "links".  They can usually display
tables better and can display frames side-by-side.  Unfortunately, the
width of what they try to display (for tables and frames) is often
wider than the terminal width so the text may run off the right side
of the screen.  This requires scrolling sideways to see everything.
Doing this may cause the names of the table rows to disappear from the
screen.  So in some cases, using "lynx" may be better.

Unfortunately "w3m", "links2", and "elinks" don't have numbered links
like lynx does, nor do they have good support for cookies.  Support
for Javascript may be a problem.  Elinks and netrik have partial
support. Links2 also has support (full ?).  Both netrik and links2 has a
graphic mode for use in X Window. 

There are still other text browser projects.  Some of them seem to be
dead.

<sect> Special Uses for a Terminal
<sect1>Make a Serial Terminal the Console <label id="term_as_console">

<p> This will turn a text-terminal (or emulator PC) into a "serial
console".  Many messages from the system are normally only sent to the
console (the PC monitor).  Some of the messages sent to the console at
boot-time may also be seen on any terminal after the boot succeeds by
typing the command: dmesg.  If the boot failed this will not be of any
use since the terminal can't work without an operating system.  It's
possible to modify the Linux kernel so as to make a terminal serve as
the console and receive all the messages from Linux intended for the
console.  Unfortunately, the messages from the BIOS (which display on
the monitor when a PC is first started) will not display on this
terminal (but still display on the monitor).

There's a Remote-Serial-Console-HOWTO on this topic.  Some people use
a serial console when they run a PC without a monitor or keyboard.
Normally, a PC will not start up without a keyboard and video card but
some BIOSs permit it.  If you are lucky enough to have such a BIOS
that supports "console re-direct" you will likely then need to setup
the BIOS using the CMOS menus when you start your PC.

The method of creating a "serial console" depends on your kernel
version.  In any case serial support needs to be compiled into the
kernel and not supplied as a module.

<sect2> For Kernels 2.2 or higher
<p> The instructions for creating a serial-console are included with
the kernel documentation in: Documentation/serial-console.txt.
Kernel 2.4+ has better documentation and mentions the need to run
getty on the serial port.  Normally, the device /dev/console is linked
to tty0 (the PC console).  For a serial-console you create a new
/dev/console by
<tscreen><verb>
mknod -m 622 console c 5 1
</verb></tscreen>
You must also put statements regarding the serial-console into
/etc/lilo.conf and then run lilo.  This is because the equivalent of
"setserial" needs to be run early before the kernel is loaded so that
the serial-console can display the booting.  See the above mentioned
kernel documentation and the man page for lilo.conf for more details.

Here is an example <tt>/etc/lilo.conf</tt> file contents (for ttyS0):
<tscreen><verb>
prompt
timeout=50
boot = /dev/sda
vga = normal # force sane state
install = /boot/boot.b
message = /boot/message
image = /vmlinuz
root = /dev/sda1
label = console
serial = 0,9600n8
append = "console=ttyS0"
</verb></tscreen>

The same PC may have more than one serial console but the last console
mentioned in the "append" statement becomes the main console that you
interact with ??  See the kernel docs (but it's not too clear).

<sect2> Serial-Console For Kernels before 2.2
<p> The Linux Journal in April 1997 had an article on patching
the Linux kernel.  You add a couple of #defines at the start of
src/linux/drivers/char/console.c:

<tscreen><verb>
#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x2f8  /* Serial port address  */

The following was not in the Linux Journal article.
In kernel 2.+ (and earlier ??) you need to also set the baud
rate (unless 9600 is OK).  Find these 2 lines:

serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
serial_echo_outb(0x0c, UART_DLL);

Change 0x0c in the line above (depending on the baud rate you want):

115200 baud: 0x01	19200 baud: 0x06	2400 baud: 0x30
57600 baud: 0x02	 9600 baud: 0x0c	1200 baud: 0x60
38400 baud: 0x03	 4800 baud: 0x18
</verb></tscreen>

If you currently use the console to select which operating system to
boot (using LILO), but would like to do this from a terminal, then you
need to add a line to the /etc/lilo.conf file.   See the manual page
for lilo.conf and search for "serial=".

<sect1> Run Linux without a Monitor
<p> One way to do this is to just use a terminal (serial console) for
the monitor See <ref id="term_as_console" name="Make a Serial Terminal
the Console">.  You may still need a video card since many BIOSs
require one to get the PC started.  Your BIOS may also require a
keyboard to get started or it may have an option where you can set the
BIOS not to require a keyboard.

If you boot without a monitor, make sure that the boot loader (such as
LILO or GRUB) doesn't try to present any image on the screen.  A
text-terminal can't display it and the booting may hang.

If you have a keyboardless terminal, it can also be used as a monitor
by use of the ttysnoop program.  As of yet, it doesn't work like a
console since it doesn't get all the initial boot-time messages.  See
<ref id="keyboardless_terminal" name="Use a Keyboardless Terminal as
the Monitor">

<sect1> Use a Keyboardless Terminal as the Monitor <label
id="keyboardless_terminal">
<sect2> How it works
<p> While you might think that a terminal without a keyboard is
useless it is possible to use it as the monitor and type on the PC's
own keyboard.  This may be done by using the spy program
<tt/ttysnoop/.  This program permits a person at one terminal to spy
on (or snoop) what someone else is typing at another terminal (or the
PC console-monitor).

Now suppose you are typing away at the monitor tty1.  Imagine that
someone with a terminal on ttyS2 is spying on you (with ttysnoop) and
has a screen that looks just like your screen.  Everything you type
at tty1 also displays on ttyS2.  Now move the spy terminal (on ttyS2)
so it is side-by-side with your monitor (on tty1).  Everything you
type on the PC keyboard will now display on the two screens in front
of you: the monitor and the spy terminal.  Now just look only at the
spy terminal as you type.  Disconnect both the monitor and the
terminal keyboard since you're not using either.  Thus you are now
using a keyboardless terminal as a monitor.  What a simple but clever
solution!

One possible problem (which turns out to be no problem at all) is
that normally, the type of spy terminal should be the same as the type
of terminal being spied upon.  Since the monitor is normally declared
as a terminal of type "linux" (which is close to vt100), you might
think that the real terminal should also be (or at least emulate) a
vt100.  Not necessarily so!  For example, if you have a wyse60
terminal you simply falsely declare that you have a wyse terminal on
tty1 (tell the getty program for tty1 that it's a wyse60).

Here's why you can get away with this.  Go back the scenario where
you have both the monitor and the wyse60 terminal in front of you,
both displaying the same thing (or trying to).  Ttysnoop will be
sending the wyse60 the same bytes as are going to the monitor.  If
you've falsely claimed that the monitor is a wyse60, then you'll have
wyse60  escape sequences going to both the monitor and the wyse60
terminal (via ttysnoops).  The display on the wyse60 is fine but the
display on the monitor is corrupted since it's getting wyse60 escape
sequences.  Since you will not use the monitor (and are about to
disconnect it) this corruption is never a problem (you simply don't
see it).

<sect2> Example configuration
<p> This is not the ideal setup since ttysnoop runs so late that the
login prompt doesn't appear.  This example is for a wyse60 terminal on
ttyS2 and the missing monitor/PC-keyboard on tty1.  It uses the agetty
program for getty as supplied by the Debian distribution.   Your getty
may require a different format.

In <tt>/etc/inittab:</tt>
<tscreen><verb>
1:2345:respawn:/sbin/getty 38400 tty1 wyse60 -ln /usr/sbin/ttysnoops
</verb></tscreen>

Note that <tt>ttysnoop/ttysnoops</tt> is a client-server combo so the
"s" is not a typo.  If you don't use -n you may not see a login prompt
on the terminal.  With no -n, agetty issues the prompt before the
ttysnoop is activated.  With -n, agetty doesn't issue the prompt (but
login does instead).  If you use -n, agetty will no longer
automatically detect parity but if you don't use parity all is OK.

In <tt>/etc/snooptab:</tt>
<tscreen><verb>
# tty	    snoopdev	  type	  execpgm
tty1	    /dev/ttyS3	  init	  /usr/local/bin/sterm
</verb></tscreen>
In the above, a script named sterm is used to run the stty program.
You may not need this or may want to use it for another purpose.
Here's the example sterm script in <tt>/usr/local/bin/sterm:</tt>

<tscreen><verb>
#!/bin/sh
stty rows 24
/bin/login $@
</verb></tscreen>

<sect> Trouble-Shooting <label id="trouble_shoot">

<p> If you suspect that the problem is a hardware problem, see the <ref
id="repair_" name="Repair and Diagnose"> section.  If it's the
keyboard see <ref id="keyboards_" name="Keyboards">.  If it responds
incorrectly (if at all) to what you type. see <ref
id="corrupt_interface" name="Corrupted Terminal Interface">.  If the
problem involves the serial port itself see the Serial-HOWTO.

Here is a list of possible problems:
<itemize>
<item><ref id="term_OK" name="Is the Terminal OK ?">
Suspect the terminal is defective.
<item><ref id="display_freezes" name="Display Freezes (hung
terminal)">
<item><ref id="displays_foreign" name="Displays Foreign/Weird
Characters/Symbols">
<item><ref id="displays_esc-seqs" name="Displays Escape Sequences">
<item><ref id="flow_ctrl_ng" name="Missing Text"> Either skips
over some text or displays some text OK and hangs.
<item><ref id="keys_erratic" name="All Keys Work Erratically; Must Hit
a Key a Few Times">
<item><ref id="stopped_" name="If getty run from command line: Programs
get stopped">  with message "Stopped"
<item><ref id="rapid_respawn" name="Getty Respawning Too Rapidly">
(console error message)
<item><ref id="after_login" name="Fails Just After Login">
<item><ref id="cant_login" name="Can't Login"> but login prompt is
OK.
<item><ref id="garbled" name="Garbled Login Prompt">
<item><ref id="no_login_prompt" name="No Login Prompt">
<item><ref id="cursor_jumps" name="Cursor Jumps">
</itemize>

There are two cases where the terminal goes bad.  One is when it's
been recently working OK and suddenly goes bad.  This is discussed in
the next sub-section.  The other case is where things don't work right
just after you install a terminal.  For this case you may skip over
the next section.

<sect1> Terminal Was Working OK <label id="term_was_ok">
<p> When a formerly working terminal suddenly goes bad it is often
easy to find the problem.  That's because (except for hardware
failures) the problem is likely due to something that you did (or
something the software that you used did).

The problem may be obvious such as an error message when the terminal
is first turned on.  If it makes a strange noise it likely needs
repair.  See <ref id="repair_" name="Repair & Diagnose">.  First,
think about what has been done or changed recently as it's likely the
cause of the problem.  Did the problem happen just after new system
software was installed or after a change in the configuration?

If the terminal isn't responding correctly (if at all) to what you
type to it, you may have a <ref id="corrupt_interface" name="Corrupted
Terminal Interface">.

<sect1> Terminal Newly Installed <label id="trouble_shoot_new">
<p> If you've just connected up a terminal to a computer per
instructions and it doesn't work this section is for you.  If a
terminal that formerly worked OK doesn't work now then see <ref
id="term_was_ok" name="Terminal Was Working OK"> If you suspect
that the serial port on your computer may be defective you might try
running a diagnostic test program on it.  At present (June 1998) it
seems that Linux doesn't yet have such a diagnostic program so you may
need to run diagnostics under MS DOS/Windows.  There are some programs
to monitor the various serial lines such at DTR, CTS, etc. and this
may help.  See <ref id="serial_mon" name="Serial
Monitoring/Diagnostics">

One approach is to first see if the terminal will work by trying
to copy a file to the terminal (cp my_file /dev/ttyS?) under the most
simple situation.  This means with the modem control lines disabled
and at a show speed that doesn't need flow control (make sure that any
hardware flow control is disabled).  If this copy works, then make the
situation a little more complicated and see if it still works, etc.,
etc.  When the trouble appears just after you made a change, then that
change is likely the source of the trouble.  Actually, its more
efficient (but more complex) to jump from the simple situation to
about half way to the final configuration so that the test eliminates
about half of the remaining possible causes of the problem.  Then
repeat this methodology for the next test.  This way it would only
take about 10 tests to find the cause out of a thousand possible
causes.  You should deviate a little from this method based on hunches
and clues.

<sect1> Is the Terminal OK ? <label id="term_OK">
<p> Many terminals will start up with some words on the screen.  If
these words convey no error message, it's probably OK.  If there is no
sign of power (a dark screen, etc.) re-plug in the computer power cord
at both ends.  Make sure there is power at the wall jack (or at the
extension cord end).  Try another power cord if you have one.  Make
sure the terminal is turned on and that its fuse is not blown.  A
blank (or dim) screen may sometimes be fixed by just turning up the
brightness and contrast using knobs or a keyboard key in set-up mode.

A terminal that's been stored for a long time may take a while to
"warm up" as the electrolytic capacitors heal themselves under
voltage.  If it still won't work See <ref id="repair_" name="Repair &
Diagnose"> for tips on repairing it.

If the terminal starts up OK, but you suspect that something may be
wrong with it, go into "local mode" where is works like a typewriter
and try typing on it.  See <ref id="local_mode" name="Local Mode">.
Before you have trouble, you should find out if your terminal displays
error messages if the hardware is bad.  One way to test a terminal
for this is to turn it on with the keyboard unplugged and see if it
displays an error message.

<sect1> Missing Text <label id="flow_ctrl_ng">
<p>  If several lines or text displays on the terminal OK and then it
stops without finishing (in the middle of a word, etc.) or if big
chunks of text are missing, you likely have a problem with flow
control.  If you can't figure out right away what's causing it,
decrease the speed.  If that fixes it, it's likely a flow control
problem.  It may be that flow control is not working at all due to
failure to configure it correctly, or due to incorrect cable wiring
(for hardware flow control).  See <ref id="flow_control" name="Flow
Control">

If you can type OK at the terminal but when text is sent to the
terminal, only about 1 in every 16 characters sent gets thru, then you
may have given the wrong UART to setserial.  This will happen if the
port is an obsolete 16550 (or lower) but you've told setserial it's a
16550A or higher.

If single characters are missing, perhaps the serial port is being
overrun by too fast a speed.  Try a slower baud rate.

If your device is under 1200 baud (probably a very slow old hard-copy
terminal or printer) and the text gets truncated, then the problem may
be in the serial device driver.  See Printing-HOWTO under "Serial
devices" on how to fix this.

<sect1> All Keys Work Erratically; Must Hit a Key a Few Times
<label id="keys_erratic">
<p> This is where you need to hit a key a few times before it works
(and see the letter you typed on the screen).  If you type a word,
some (or even all) of the letters may be missing on the screen.  If
letters are missing from a command it doesn't work and even if all
letters are present you may need to hit the return-key several times
to get the command to execute.

This may be due to two different processes opening the serial port.  Both
try to read what you type.  Sometimes one process (the right one
--perhaps the shell) reads what you type and at other times the other
process reads what you type.  An example is where the other process is
for a serial mouse (such as gpm) which doesn't echo what you type.
So another process running on the same ttySx is eating some of what
you type.  To fix this, use "ps -alx" to see what else is running on
your ttySx and kill that process.

You might think that lockfiles would prevent two programs from using
the same serial port at the same time.  But neither the terminal nor
the gpm mouse program uses lockfiles.  Since others may need to write
to your terminal, it's reasonable not to use lockfiles.  See
Lock-Files in the Serial-HOWTO.

<sect1> ... respawning too fast: disabled for 5 minutes
<label id="rapid_respawn">

<sect2>What's happening
<p>You see a message on the console like: "Getty respawning too fast:
disabled for 5 minutes".  Instead of "Getty" it may display a label
(such as: Id "S2") where S2 is the label for the line in /etc/inittab
from where from where getty was called.

When getty starts up, it tries to send a login message to the serial
port.  But if there is something seriously wrong, getty will be
immediately killed.  Since the /etc/inittab file line for getty says
to "respawn", getty is started again, only to be killed again, etc.
Thus getty rapidly respawns over and over.  But the operating system
intervenes and stops this nonsense (for 5 minutes).  The following
sections show possible causes and fixes.

<sect2>Getty line in /etc/inittab file incorrect
<p>Make sure the line which calls getty in /etc/inittab is
correct.  A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty"
may cause this problem.  

<sect2> No modem control signal
<p> If the terminal doesn't send the PC a CD signal on one of the pins
of the serial port, getty will be killed unless the "local" option has
been used with getty.  So a quick fix is to just use a "local" option
(-L for agetty, "CLOCAL" in /etc/gettydefs for getty_ps).

Another approach is to determine why CD is not being asserted.  In
many cases the cable to the terminal simply doesn't have a wire for
the CD pin so you must use the "local" option.  If there is a wire for
the CD pin then there may not be any signal on it until the terminal
is powered on.  Note that the CD pin signal is sometimes supplied by
the DTR pin of the terminal (or the PC) by using jumper wires inside
the connector.

<sect2> No such serial device
<p>If the device (such as /dev/ttyS2) is bogus (doesn't physically
exist or has been disabled), then getty will be killed.  You may use
"scanport" (Debian only ??) and/or "setserial" to probe for the device
or try another ttyS.  Perhaps the device has been disabled in the
CMOS.  See "Serial-HOWTO".

<sect2> No serial support
<p> Linux provides serial support either by selecting it when
compiling the kernel or by loading the serial module: serial.o.  This
"respawning" error happens if serial support has neither been built
into the kernel nor provided by a serial module.  You many use the
"lsmod" command to see if the serial module is loaded.  To see if
serial support is built into the kernel, check a kernel configuration
file (in /boot, in the source tree, etc.)

<sect2> Key shorted <label id="key_shorted_getty">
<p> Another possible cause of getty respawning too rapidly is if a
keyboard key is shorted.  This can happen if the key gets stuck in the
down position.  With auto-repeat enabled, this "types" thousands of
characters to the login prompt.  Look for a screen filled with all the
same character (in some cases, with 2 or more different characters).

<sect1> Fails Just After Login <label id="after_login">
<p> If you can login OK but then you can't use the terminal it may be
because the starting of the login shell has reconfigured the terminal
(to an incorrect setting) by a command which someone put into one of
the files that are run when you login and a shell starts.  These files
include /etc/profile and &tilde;/.bashrc.  Look for a command starting with
"stty" or "setserial" and make sure that it's correct.  Even if it's
done OK in one initialization file, it may be reset incorrectly in
another initialization file that you are not aware of.  Ways to get
into the systems to fix it are to use another terminal or console, use
a rescue diskette, or type: "linux single" at the lilo prompt which
puts you into single user mode without running startup files.

<sect1> Can't Login <label id="cant_login">
<p> If you get a login prompt but get no response (or perhaps a
garbled response) to your login attempts a possible cause is that the
communication is bad one-way from the terminal to the computer.  It
could be a bad or mis-wired cable/connector.  If you're not already
using the "local" option with getty, do so to disable the modem
control lines.  See <ref id="getty_" name="Getty (used in
/etc/inittab)">.  You might also disable hardware flow control (stty
-crtscts) if it was enabled.  If it now works OK then your modem
control lines are likely either not wired correctly or there's a
mistake in your set-up.  Some terminals allow setting different values
(such as baud rate) for send and receive so the receive could be OK
but the send bad.

You should also try at another terminal (such as the console) "stty -F
/dev/ttyS1" (or ttyS whatever) to see that it's set up correctly.  It
will often be in raw mode (and this is probably OK) with -icanon and
-echo etc.  If the terminal incorrectly set at half-duplex (HDX), then
one set of the characters you see when you type are coming from the
terminal itself.  If the characters are doubled, then the echos from the
computer are OK and you may switch to full-duplex to fix this.  But if
half-duplex is set and you only see what looks like normal "echos", then
they are not coming from the computer as they should be.

If you get a message saying something like "login failed" then if
there is no error in typing or in the password, there may be some
restrictions on logins which will not allow you to log in.
Unfortunately, this message, may not tell you why it failed.  See <ref
id="login_restr" name="Login Restrictions">

<sect1> Garbled Login Prompt  <label id="garbled">
<p> This may be due to using the wrong character set, transmission
errors due to too high of a baud rate, incompatible baud rates,
incompatible parity, or the wrong number of bits per byte.  If it's a
variety of strange characters you have the wrong character set or a
high order bit is being set by mistake.  If words are misspelled, try
a lower baud rate.  For baud, parity, or bits/character incompatibilities
you see a lot of the same "error character" which represents a real
character that can't be displayed correctly due to an error in parity
or baud rate.  The "error character" may be an upside-down question
mark or some other strange looking character such as a rectangle.

If you are using agetty (often just named getty), the agetty program
will detect and set parity and/or bits/character if you type something.
Try it with a return to see if it fixes it.

<sect1> No Login Prompt <label id="no_login_prompt">
<p> If there's no login prompt displayed after hitting the return-key
a few times then check the following:  Use the "top" or "ps" programs
to make sure that a getty (or login) process is actually running on
the terminal.  Is the terminal getting power?  Is the null modem cable
plugged in to the correct ports on both the terminal and computer?

Check that getty isn't hanging because there is no CD signal (or no CD
wire in the cable).  If such a CD signal doesn't exist you should have
specified "local" to getty by either:
<itemize>
<item>If getty_ps (Redhat, etc.) two CLOCAL flags in /etc/gettydefs
(See <ref id="getty_ps" name="getty (part of getty_ps)">).
<item>If agetty (Debian, etc.) a -L flag in /etc/inittab (See <ref
id="agetty_" name="agetty">).
</itemize>

If getty (or login) isn't running, carefully check the format for calling getty
in /etc/inittab.  Make sure that it includes the current runlevel
(shown by typing the command "runlevel") and that it is valid for your
flavor of getty.  Sometimes killing getty or login (it will restart
automatically) helps.

<sect2> Terminal was working OK
<p> Although hardware failures are possible, the problem is likely due
to something that someone did by mistake.  Did someone do something
that might have loosened a cable?  Did someone modify /etc/inittab or
make some other change to the software so as to prevent terminal
login?  If this doesn't reveal the cause, continue reading.

<sect2> More diagnose
<p> The above should solve most cases (unless you've just installed a
terminal).  Other causes include defective hardware or cables (must be
file-transfer), terminal setup at wrong baud-rate, terminal in local
mode, etc.  At this point two different avenues of approach are (you
may pursue more than one at a time).

<itemize>
<item> <ref id="consoleD" name="Diagnose problem from the console">
<item <ref id="measure_volts" name="Measure voltages">
</itemize>

<sect2> Diagnose problem from the console <label id="consoleD">
<p> One test is to try to copy a something to the terminal (It might
be a good idea to try this near the start of the installation process
before setting up getty).  You may use the Linux copy command such as:"cp
file_name /dev/ttyS1".  Or your could use: "echo any_word >
/dev/ttySx".  If it doesn't work, use stty to make the interface as
simple as possible with everything disabled (such as hardware flow
control: -crtscts; parity, and modem control signals: clocal).  Be
sure the baud rates and the bits/byte are the same.  If nothing
happens verify that the port is alive with a voltmeter per the next
section.

<sect2> Measure voltages <label id="measure_volts">
<p> If you have a voltmeter handy check for a negative voltage (-4v to
-15v) at pin 3 or 2 (receive data) at the terminal side of the
file-transfer cable.  The positive lead of the meter should be
connected to a good ground (a metal connector on the end of the cable
may not be grounded).  If there is no such negative voltage then
check for it at the transmit pin (TxD) on the computer (see <ref
id="DB_pin-out" name="DB9-DB25"> for the pin-out).  If it's present
there but not at the receive pin (RxD) at the terminal, then the cable
is bad (loose connection, broken wire, or not a file-transfer aka
null-modem).  If this voltage is absent at the computer, then its
serial port is dead.  Test it with a software diagnostic test or
replace it.

If the serial port is alive, you may want to send a file to it (with
modem controls disabled) and watch the signal on a voltmeter (or other
electronic gadget).  To check for a transmitted signal with a voltmeter,
check for a steady negative voltage when the line is idle.  Then start
sending a file (or start getty).  On an analog meter you should see
the needle dropping to almost 0 and fluttering about 0 as it measures
short-run averages of the bit stream.  On a digital meter you will not
see the fluctuations as well but you can switch to the AC scale to see
the AC voltage created by the flow of bits.  If your meter fails to
block out DC on the AC scale (the default of most analog meters), then
you could get a false high AC reading when looking at the idle DC of
-12v (or -5v) on the AC scale.  Without a meter, you could connect a known
good device (such as another terminal or an external  modem) to the
serial port and see if it works OK.

<sect1> Displays Foreign/Weird Characters/Symbols
<label id="displays_foreign">
<p> Don't confuse this with <ref id="displays_esc-seqs" name="Displays
Escape Sequences">.  If what you type or see on the screen is not
what's expected but looks like a foreign alphabet, math symbols,
line-drawing character, etc. then it could be that the many of bytes
that are sent to your terminal have the high order bit set (when it
shouldn't be).  You are looking at the character set (or part of a
character set) which has the high order bit set.  This may happen if
you have the baud rate wrong or parity set wrong (per stty).  If you
have parity set per stty but inside the terminal it's 8-bit no-parity,
then the high order bit (= parity bit) will often be erroneously set.
Try stty -F /dev/ttyS?  from another terminal to check if the baud
rate and parity are correct.

Perhaps the wrong character set (font) has been installed.  An
erroneous escape sequence sent to the terminal could have switched
character sets.  If you are using the mapchan program to change the
keyboard mapping, it could be incorrect.

<sect1> Displays Escape Sequences <label id="displays_esc-seqs">
<p>You may see something like "5;35H22,1" or "3;4v" or "1;24r" or
"^[[21;6H", etc., etc.  Of course, the numbers and letters will be
different.  They will be scattered about (either randomly or in a
strange sense of order).  The display will look a mess and will likely
have other defects.  Some application and commands will result in
corrupted displays.

What you see are escape sequences (or fragments of them) that were
sent to your terminal in order to control it, but your terminal didn't
recognize them and passed them on to the screen.  It's likely that the
program you're using erroneously thinks you are using another type of
terminal.  Thus it sends escape sequences that your terminal doesn't
understand.  This can sometimes do strange things to your display.
Check that the TERM environment variable is set correctly (type: echo
$TERM).

<sect2>Telnet
<p>The problem of getting TERM right can be a bit more complex if you use
telnet.  Telnet doesn't emulate a terminal but passes the value of
your TERM variable to the remote computer.  If the remote computer
doesn't support your type of terminal, or changes the value of TERM to
a wrong value (on the remote) then there's trouble.  Telnet
should initially set the value of TERM correctly on the remote.  But
changes to the value of TERM (on the remote) could be caused by an
incorrect shell configuration file there.  The first thing to do is to
check the value of TERM, both on your computer and on the remote.  The
above is overly simplified since it's possible for your telnet client
to present the remote server with a list of possible TERM values which
your computer supports (if telnet knows that your computer can emulate
more than one terminal type).

<sect2>Terminal set to display escape sequences
<p>Another possible cause is that your terminal happens to be in a
special mode where it displays the escape sequences instead of
executing them.  Then you'll also see them on the screen but they will
display in an orderly fashion.  This mode is more precisely, one that
displays control codes.  But since each escape sequence starts with a
control code (the "escape" character), the whole escape sequence is
not recognized by the terminal and is passed along to the screen.  See
<ref id="control_codes" name="Control Codes">.

<sect1> Slow: pauses of several seconds between bursts of characters
<p> You likely have mis-set interrupts>  See the Serial-HOWTO section
starting with "Slow:"

<sect1>Cursor Jumps <label id="cursor_jumps">
<p>This error happens when you expect the cursor to move to the next
character but instead it seems to jump to another character.  It can
happen in the vim editor when you've selected "showmatch" to highlight
matching brackets (or parentheses).  There is nothing wrong with the
terminal and the cursor isn't jumping, but it looks like it is.

What is happening is that the cursor is reverse video and the
highlighting is also reverse video.  So suppose you highlight (or
emphasize) a character by reverse video and then put a reverse-video
cursor over it.  The cursor's reverse video will then reverse
the existing reverse video of the character and result in normal
video.  The result is that both the cursor and character highlighting
have disappeared for that character and the cursor is invisible (until
you move it to a non-highlighted character).

OK, so the cursor suddenly disappears, but what makes it jump?  For
the vim "showmatch" when you move the cursor to an opening bracket it
also highlights the closing bracket.  Thus the closing bracket
suddenly becomes reverse video and it looks just like the cursor has
jumped there, but it hasn't.  Similar "illusions" happen when you move
the cursor to a closing bracket (or parenthesis).  This illusion when
you reverse reverse-video happens in other cases besides the vim
example just presented.

<sect1> Terminal doesn't scroll <label id="no_scroll_25">
<p> One reason may be that something is wrong with terminfo.  Another
reason could be that you are outside the scrolling region set for the
terminal.  Some stupid programs just assume that your terminal has 24
lines and set the scrolling region for 24 lines (by an escape sequence
sent to the terminal) without consulting terminfo to see how many
lines there actually are.  Then when you use another program it may
leave the cursor on line 25 where it becomes trapped and the terminal
will not scroll.  To avoid this problem, create an environment
variable "export LINES=25" and also "stty -F /dev/ttySx rows 25".
Then the programs that assume 24 lines will hopefully use 25 lines set
the scrolling region accordingly.

<sect1> Serial Monitoring/Diagnostics <label id="serial_mon">
<p> A few Linux programs will monitor the modem control lines and
indicate if they are positive (1) or negative (0).
<itemize>
<item> statserial (in Debian distribution)
<item> The "file": /proc/tty/driver/serial.  Use "watch head ..." to
monitor it.  Has info on errors and byte flow.
<item> modemstat (only works on Linux PC consoles.  Will coexist with
the command line)
</itemize>
You may already have the above programs.  If not, go to <url url=
"http://ibiblio.org/pub/Linux/system/serial/" name="Serial
Software">.  When using these, bear in mind that what you see is the
state of the lines at the host computer.  The situation at the
terminal will be different since some wires are often missing from
cables while other wires cross over.  As of June 1998, I know of no
diagnostic program in Linux for the serial port.

<sect1> Local Mode <label id="local_mode">
<p> In local mode, the terminal disconnects from the computer and
behaves like a typewriter (only it doesn't type on paper but on the
screen).  Going back into on-line mode reconnects to the computer
allowing you to resume activities at the same point where you left off
when you went into "local".  This is useful both for testing the
terminal and for educational purposes.  For some terminals  there is
no "local mode" but "block mode" may substitute for it.  If there is
no "block mode", "half duplex" mode might work, except that what you
type gets sent to the computer also.  In this case the computer may
echo the characters sent to it resulting in two characters displayed
on the screen for every character you type.  To prevent this you could
shut down the computer, disconnect the RS-232 cable, etc.

When in local mode you may type escape sequences (starting with the
ESC key) and observe what they do.  If the terminal doesn't work
correctly in local mode, it's unlikely that it will work correctly
when connected to the computer.  If you're not exactly sure what an
escape sequence does, you can try it out in local mode.  You might
also use it for trying out a terminal that is for sale.  To get into
local mode on some terminals you first enter set-up mode and then
select "local" from a menu (or press a certain key).  See <ref
id="enter_setup" name="Getting Into Set-Up (Configuration) Mode">.

<sect1> Serial Electrical Test Equipment <label id="ser_elect_test">
<!-- begin ser_elect_test.D.  in Serial, Text-Terminal -->
<sect2> Breakout Gadgets, etc.
<p> While a multimeter (used as a voltmeter) may be all that you need
for just a few serial ports, simple special test equipment has been
made for testing serial port lines.  Some are called "breakout ... "
where breakout means to break out conductors from a cable.  These
gadgets have a couple of connectors which connect to serial port
connectors (either at the ends of serial cables or at the back of a
PC).  Some have test points for connecting a voltmeter.  Others have
LED lamps which light when certain modem control lines are asserted
(turned on).  The color of the light may indicate the polarity of the
signal (positive or negative voltage).  Still others have jumpers so
that you can connect any wire to any wire.  Some have switches.

Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called
"RS-232 Line Tester") Cat. #276-1401.  It checks TD, RD, CD, RTS, CTS,
DTR, and DSR.  A green light means on (+12 v) while red means off (-12
v).  They also sell a "RS-232 Serial Jumper Box" Cat.
#276-1403.  This permits connecting the pins anyway you choose.  Both
these items are under the heading of "Peripheral hookup helpers".
Unfortunately, they are not listed in the index to the printed
catalog.  They are on the same page as the D type connecters so look
in the index under "Connectors, Computer, D-Sub".  A store chain named
"Active Components" may have them.

<sect2> Measuring voltages
<p> Any voltmeter or multimeter, even the cheapest that sells for
about $10, should work fine.  Trying to use other methods for checking
voltage is tricky.  Don't use a LED unless it has a series resistor to
reduce the voltage across the LED.  A 470 ohm resistor is used for a
20 ma LED (but not all LED's are 20 ma).  The LED will only light for
a certain polarity so you may test for + or - voltages.  Does anyone
make such a gadget for automotive circuit testing??  Logic probes may
be damaged if you try to use them since the TTL voltages for which
they are designed are only 5 volts.  Trying to use a 12 V incandescent
light bulb is not a good idea.  It won't show polarity and due to
limited output current of the UART it probably will not even light up.

To measure voltage on a female connector you may plug in a bent paper
clip into the desired opening.  The paper clip's diameter should be no
larger than the pins so that it doesn't damage the contact.  Clip
an alligator clip (or the like) to the paper clip to connect up.  Take
care not to touch two pins at the same time with any metal object.

<sect2> Taste voltage
<p> As a last resort, if you have no test equipment and are willing to
risk getting shocked (or even electrocuted) you can always taste the
voltage.  Before touching one of the test leads with your tongue, test
them to make sure that there is no high voltage on them.  Touch both
leads (at the same time) to one hand to see if they shock you.  Then
if no shock, wet the skin contact points by licking and repeat.  If
this test gives you a shock, you certainly don't want to use your
tongue.

For the test for 12 V, Lick a finger and hold one test lead in it.
Put the other test lead on your tongue.  If the lead on your tongue is
positive, there will be a noticeable taste.  You might try this with
flashlight batteries first so you will know what taste to expect.
<!-- end ser_elect_test.D in Serial, Text-Terminal -->


<sect> Repair & Diagnose <label id="repair_">
<p> Repairing a terminal has much in common with repairing a monitor
and/or keyboard.  Sometimes the built-in diagnostics of the terminal
will display on the screen.   By the symptoms, one may often isolate
the trouble to one of the following: bad keyboard, CRT dead, power
electronics failure (distorted display), or digital electronics
failure.  It's best to have a service manual, but even if you don't
have one, you can often still repair it.

<sect1> Repair Books & Websites <label id="repair_info">
<sect2> Books
<p> Bigelow, Stephen J.: Troubleshooting & Repairing Computer
Monitors, 2nd edition, McGraw-Hill, 1997.  Doesn't cover the character
generation electronics nor the keyboard.

<sect2> Websites
<p> The FAQ <url url="http://www.repairfaq.org"> for the newsgroup:
sci.electronics.repair is long and comprehensive, although it doesn't
cover terminals per se.  See the section "Computer and Video
Monitors".  Much of this information is applicable to terminals as are
the sections: "Testing Capacitors", "Testing Flyback Transformers",
etc.  Perhaps in the future, the "info" on repair in this HOWTO will
consist mainly of links to the above FAQ (or the like).

<sect1> Safety
<p> CRT's use high voltage of up to 30,000 volts for color (less for
monochrome).  Be careful not to touch this voltage if the set is on
and the cover off.  It probably won't kill you even if you do since
the amount of current it can supply is limited.  But it is likely to
badly burn and shock you, etc.  High voltage can jump across air gaps
and go thru cracked insulation so keep your hands a safe distance from
it.  You should notice the well-insulated high voltage cable connected
to one side of the picture tube.  Even when the set is off, there is
still enough residual voltage on the picture tube cable connection to
give you quite a shock.  To discharge this voltage when the set is
unplugged use a screwdriver (insulated handle) with the metal blade
grounded to the picture tube ground cable with a jumper wire.  Don't
use chassis ground.

The lower voltages (of hundreds of volts) can be even more dangerous
since they are not current limited.  It is even more dangerous if your
hands are wet or if you are wearing a metal watchband, ring or the
like.  In rare cases people have been killed by it so be careful.  The
lowest voltages of only several volts on digital circuitry are fairly
safe but don't touch anything (except with a well insulated tool)
unless you know for sure.

<sect1> Appearance of Display
<p> If the display is too dim, turn up the brightness and/or contrast.
using knobs on the exterior of the unit (if they exist).  If the
width, height or centering is incorrect, there are often control knobs
for these.  For some older terminals one must press an arrow key
(or the like) in set-up mode.

You may need to remove the cover to make adjustments, especially on
older models.  You could arrange things so that a large mirror is in
front of the terminal so as to view the display in the mirror while
making adjustments.  The adjustments to turn may be on a printed
circuit board.  While a screwdriver (possibly Phillips-head) may be
all that's needed, inductors may require special TV alignment tools
(plastic hex wrenches, etc.).  The abbreviated name of the adjustment
should be printed on the circuit board.  For example, here are some
such names:

<itemize>
<item> V-Size adjusts the Vertical height (Size)
<item> H-Size adjusts the Horizontal width (Size).  It may be an inductor.
<item> V-Pos adjusts the Vertical Position
<item> H-Pos adjusts the Horizontal Position
<item> V-Lin adjusts Vertical Linearity (Use if width of scan lines
			differs at the top and bottom of the screen)
<item> V-Hold adjusts Vertical Hold (Use if screen is uncontrollable
						scrolling)
<item> Bright adjusts brightness (an external knob may also exist)
<item> Sub-Bright adjusts brightness of subdued intensity mode (often
the normal mode: dimmer than bold or bright mode).
</itemize>

Changing linearity may change the size so that it will need to be
readjusted.  A terminal that has been stored for some time may have a
small display rectangle on the screen surrounded by a large black
Before adjusting it, leave the terminal on for a while since it will
likely recover some with use (the black borders will shrink).

<sect1> Diagnose
<sect2> Terminal Made a Noise or Smoked
<p> If the terminal made some noise just before it failed (or when you
turn it on after it failed) that noise is a clue to what is wrong.  If
you hear a noise or see/smell smoke, immediately turn the terminal off
to prevent further damage.  A pop noise may be a capacitor exploding
or a fuse blowing.  A buzzing noise is likely due to arcing.  The
problem may be in the high voltage power supply of several thousand
volts.

Remove the cover.  Look for discoloration and bulging/cracked
capacitors.  If the bad spot is not evident, turn it on again for a
short time and look for smoking/arcing.  For arcing, a dimly lit room
will help find it.  The high voltage cable (runs between the flyback
transformer and the side of the picture tube) may have broken
insulation that arcs to ground.  Fix it with high-voltage insulating
dope, or special electrical tape designed say for 10,000 volts.

The flyback transformer (high voltage) may make only a faint clicking
or sparking noise if it fails.  You may not hear it until you turn the
terminal off for a while and then turn it back on again.  To track
down the noise you may use a piece of small rubber tubing (such as
used in automobiles) as a stethoscope  to listen to it.  But while you
are listening for the noise, the terminal is suffering more damage so
try find it fast (but not so fast as to risk getting shocked).

A shorted power supply may cause a fuse to blow.  Replacing a blown
fuse may not solve the problem as the same short may blow the fuse
again.  Inspect for any darkened spots due to high heat and test those
components.  Shorted power transistors may cause the fuse to blow.
They may be tested with a transistor checker or even with an
ohm-meter.  Use the low ohm scale on an ohm-meter so that the voltage
applied by the meter is low.  This will reduce the possible damage to
good components caused by this test voltage.

If the terminal has been exposed to dampness such as being stored in a
damp place or near a kitchen with steam from cooking, a fix may be to
dry out the unit.  Heating a "failed" flyback transformer with a blow
dryer for several minutes may restore it.

<sect2> Terminal Made No Noise

<p> A blank screen may be due to someone turning the brightness
control to the lowest level or to aging.  The next thing to do is to
check the cables for loose or broken connections.  If there is no sign
of power, substitute a new power cord after making sure that the power
outlet on the wall is "hot".

If the keyboard is suspected, try it on another terminal of the same
type or substitute a good keyboard.  Wiggle the keyboard cable ends
and the plug.  Wires inside cables may break, especially near their
ends.  If the break is verified by wiggling it (having the problem go
on and off in synchronization with the wiggles), then one may either
get a new cable or cut into the cable and re-solder the breaks, etc.

One of the first things to do if the keyboard works is to put the
terminal into <ref id="local_mode" name="Local Mode">.  If it works OK
in local, then the problem is likely in the connection to the host
computer (or incorrect interface) or in the UART chips of the
terminal.

<sect1> Detective work
<p>By carefully inspecting the circuitry, one may often find the cause
of the problem.  Look for discoloration, cracks, etc.  An intermittent
problem may sometimes be found by tapping on components with a
ball-point pen (not the metal tip of course).  A break in the
conductor of a printed circuit board may sometimes be revealed by
flexing the board.  Solder that looks like it formed a drop or a
solder joint with little solder may need re-soldering.  Soldering may
heat up transistors (and other components) and damage them so use a
heat sink if feasible.  One failure may cause others, so unless you
find the original cause, the failure may reoccur.

If you have a common brand of terminal, you may be able to search the
Internet (including newsgroup postings) to find out what the most
frequent types of problems are for your terminal and perhaps
information on how to fix it.  If you find that a certain component
is bad you may search for this component (for example R214 wyse) and
hopefully find a report by someone else who had the same problem.
Such a report may indicate other components that failed at the same
time.  If a component is damaged so badly that its value can't be
read, then you might find it on the Internet.  The manufacturer may
have on-line data that search engines don't index.

To see if the digital electronics work, try (using a good keyboard)
typing at the bad terminal.   Try to read this typing at a
good terminal (or the console) using the copy command or with a
terminal communication program such as picocom.  You may need to hit
the return key at the terminal in order to send a line.  One may
ask the bad terminal for its identity etc. from another terminal.
This will show if two-way communication works.

<sect1> Error Messages on the Screen
<p> You are in luck if you see an error message on the screen.  This
usually happens when you first turn the terminal on.

<sect2> Keyboard Error
<p> This usually means that the keyboard is not plugged in, or that
the connection is loose.  For more serious problems see <ref
id="keyboards_" name="Keyboards">

<sect2> Checksum Error in NVR
<p> NVR is "Non-Volatile RAM".  This means that the NVR where the
set-up information is stored has become corrupted.  The terminal will
likely still work but the configuration that was last saved when
someone last configured the terminal has likely been lost.  Try
configuring again and then save it.  It might work.  On very old
terminals (early 1980's) there was a battery-powered CMOS to save the
configuration so in this case the problem could be just a dead
battery.  Sometimes the EEPROM chip (no battery needed) goes bad after
too many saves.  It may be hard to find.  If you can't fix it you are
either stuck with the default configuration or you may have escape
sequences sent to the terminal when you start it up to try to
configure it.

<sect1> Capacitors

<p> Electrolytic capacitors have a metal shell and are may become weak
or fail if they set for years without being used.  Sometimes just
leaving the terminal on for a while will help partially restore them.
If you can, exercise any terminals you have in storage by turning them
on for a while every year or so.

Note that cheap electrolytic capacitors designed for use in audio
circuits may fail if used in high frequency horizontal circuitry.  For
this, you need low resistance (low ESR) capacitors.  Replace
non-polarized capacitors (NP) with the same (or with "bi-polar").

If the terminal display takes several minutes of warmup before it's 
OK then it's likely that you have one or more bad electrolytic
capacitors.  One trick to find the bad one is to parallel each
suspected bad one with a good one (of at least the same voltage rating
and capacitance of roughly the same order of magnitude).  If the
display improves a lot when you do this, then you've likely found the
bad capacitor.  Be careful not to get shocked when doing this.  The
actual voltage with respect to ground may be much higher than the
voltage rating of the capacitor.

<sect1> Keyboards <label id="keyboards_">
<sect2> Interchangeability
<p> The keyboards for terminals are not the same as keyboards for
PC's.  The difference is not only in the key layout but in the codes
generated when a key is pressed.  Also, keyboards for various brands
and models of terminals are not always interchangeable with each
other.  Sometimes one get an "incompatible" keyboard to partially work
on a terminal:  All the ASCII keys will work OK, but special keys such
as set-up and break will not work correctly.

<sect2> How They Work
<p> Most keyboards just make a simple contact between two conductors
when you press a key.  Electronics inside a chip in the keyboard
converts this contact closure into a code sent over the keyboard's
external cable.  Instead of having a separate wire (or conductor)
going from each key to the chip, the following scheme is used:
Number the conductors say from 1-10 and A-J.  For example: conductor 3
goes to several keys and conductor B goes to several keys, but only
one key has both conductors 3 and B going to it.  When that key is
pressed, a short circuit is established between 3 and B.  The chip
senses this short and knows what key has been pressed.  Such a scheme
reduces the number of conductors needed (and  reduces the number of
pins needed on the chip).  It's a similar scheme to what is called a
"crossbar switch".

<sect2> Modern vs Old Keyboards
<p> While the modern keyboard and the old fashioned type look about
the same, the mechanics of operation are different.  The old ones have
individual key switches under the key-caps with each switch enclosed
in a hard plastic case.  The modern ones use large flexible plastic
sheets (membrane) the size of the keyboard.  A plastic sheet with
holes in it is sandwiched between two other plastic sheets containing
printed circuits (including contact points).  When you press a key,
the two "printed" sheets are pressed together at a certain point,
closing the contacts printed on the sheets at that point.

<sect2> One Press Types 2 Different Characters <label id="two_chars">
<p> If, due to a defect, conductors 3 and 4 become shorted together
then pressing the 3-B key will also short 4 and B and the chip will
think that both keys 3-B and 4-B have been pressed.  This is likely to
type 2 different characters when all you wanted was one character.

<sect2> Keyboard doesn't work at all
<p> If none of the keys work try another keyboard (if you have one) to
verify that the keyboard is the problem.  One cause is a broken wire
inside the cord (cable) that connects it to the terminal.  The most
likely location of the break is at either end of the cord.  Try
wigging the ends of the cord while tapping on a key to see if it works
intermittently.  If you find a bad spot, you may carefully cut into
the cord with a knife at the bad spot and splice the broken conductor.
Sometimes just a drop of solder will splice it.  Seal up the cord with
electrical tape, glue, or caulk.  A keyboard that has gotten wet may
not work at all until it's dry.

<sect2> Typing b displays bb, etc. (doubled)
<p> If all characters appear double there is likely nothing wrong with
the keyboard.  Instead, your terminal has likely been incorrectly set
up for half-duplex (HDX or local echo=on) and every character you type
is echoed back both from the electronics inside your terminal and from
your host computer.  If the two characters are not the same, there may
be a short circuit inside your keyboard.  See <ref id="two_chars"
name="One Press Types 2 Different Characters">

<sect2> Row upon row of the same character appears
<p> This may happen when auto-repeat is enabled and a key is held
pressed down (or the like).  It may be a key that sticks down when
typed or it could be an electrical short that has the same
effect.

<sect3> Key sticks in down position (individual switches)
<p> First try tapping on it hard several times but it's not likely to
fix it.  Next, your can either remove the keycap (if it is removable)
and squirt a little cleaner on the push rod or work the key up and
down while pushing on it sideways (or both).  If this doesn`t work you
may need to take the switch apart and clean the components.

If you decide to remove the keycap see <ref id="kbd_sw"
name="Keyboards with individual switches">.  Press repeatedly on the
push rod until it works OK and also displays its character on the
screen.  At first, the cleaner may cause the key to fail to display
its character.  Some keys stick due to stickiness on the keycap bottom
surface..  If the key sticks in the fully down position this could be
the problem.  So you might need to clean this area too.

If you decide to push it sideways, use a small screwdriver to push
sideways with while pushing the key up and down with both your finger
and the screwdriver.  You should push it sideways in one of the four
directions and try different directions.  What you are doing by this
is attempting to force out a foreign particles that are rubbing on the
side of the key's push-rod and making it stick.  Again, the problem
may return later.

Always test the key just after fixing it and a short time later.  To test
the key, push it down very slowly and see if it sticks.  Also push it
sideways a little as you're pushing it down.  If you hit it fast or
push it straight down, then you may not observe the stickiness.  This
test will detect a key that seemingly  works OK but is likely to cause
trouble later on.

<sect3> Key electrically shorted
<p>If you suspect that a key is shorted out, fix it by cleaning the
contacts per <ref id="clean_keys" name="Cleaning Keyboard Contacts">.
If this problem happens at the login prompt see <ref
id="key_shorted_getty" name="Key shorted">.

<sect2> Liquid spilled on the keyboard
<p> If water or watery liquid has been spilled on the keyboard (or if
it was exposed to rain, heavy dew, or dampness) some (or all) keys may
not work right.  The dampness may cause a key to short out (like it
was pressed down all the time) and you may see the screen fill up with
that letter if auto-repeat is enabled.  If it's gotten wet and then
partially (or fully) dried out, certain keys may not work due to
deposits on the contact surfaces.  For the modern type of keyboard,
one may readily take apart the plastic sheets inside and dry/clean
them.  For the old type one may let it dry out in the sun or oven (low
temp.).  When it's dry it may still need contact cleaner on some keys
as explained below.

<sect2> Cleaning keyboard contacts  <label id="clean_keys">
<sect3> Keyboards with membranes
<p> On some newer keyboards, the plastic sheets (membranes) are easy
to remove for inspection and cleaning if needed.  You only need to
remove several screws to take apart the keyboard and get to the
sheets.  On some old IBM keyboards the sheets can't be removed without
breaking off many plastic tabs which will need to be repaired with
glue to put back (probably not worthwhile to repair).  Such a keyboard
may sometimes be made to work by flexing, twisting, and/or pounding
the assembly containing the plastic sheets.

<sect3> Keyboards with individual switches <label id="kbd_sw">
<p> What follows is for older keyboards that have separate hard
plastic switches for each key.  Before going to all the work of
cleaning electrical contacts first try turning the keyboard
upside-down and working the bad keys.  This may help dislodge dirt,
especially if you press the key hard and fast to set up vibration.
Pressing the key down and wiggling it from side to side, etc. often
helps.

If this doesn't work, you may try to clean the key switch with a
liquid contact cleaner (available at electronic supply stores) which
usually comes in a spay can.  To get to the switch, you first need to
remove the key-cap (the square that you hit with your finger while
typing).  Warning: Key-caps on modern keyboards can't be removed.
Often, the key-caps may be removed by prying them upward using a small
screwdriver with the tip placed under a key while preventing excessive
tilting of the key with a finger.  There exists a special tool known
as keycap puller but you can get by without it.  The key-cap may tilt
a bit and wobble as it comes loose.  It may even fly up into the air
and onto the floor.

Then you may have two choices on how to clean the contacts: Use
contact cleaner spray directly on top of the key switch, or take the
key switch apart and clean it (the best way if it comes apart easily).
Still another choice is to replace the key switch with a new or used
one but this is often more work (and more cost if you have to go thru
the trouble of finding a replacement.

Directly spraying contact cleaner into the top of the key switch,
without taking the switch apart, is the fastest method but the cleaner
may not reach the contacts it's supposed to clean.  Before spraying,
clean the area around it a little.  With the keyboard live (or with
the key contacts connected to an ohm-meter) use the plastic tube which
came with the spray to squirt cleaner so it will get inside the key
switch.  Try to move the key push rod up and down while spraying.
Don't let the cleaning liquid get under nearby keys where it may pick
up dust and then seep (with the dust) into adjacent key switches.  If
you make this mistake you may fix one key but damage nearby keys.  If
this should happen, immediately work (repeatedly press) the affected
nearby keys until they continue to work OK.

You might tilt the keyboard so that the cleaner flows better into the
contacts.  For the CIT101e terminal with an Alps keyboard, this means
tilting the top row of numeric keys up toward the ceiling.  While
moving the key switch up and down with a pen or small screwdriver
handle avoid getting the toxic cleaner liquid on your skin (or wear
gloves).  You might try turning the keyboard upside-down while working
the key to drain off remaining cleaner.  The more cleaner you squirt
in the more likely it will fix it but it is also more likely to do
more damage to the plastic or contaminate adjacent keys, so use what
you think is just enough to do the job.  Once the key works OK, work
it up and down a little more and test it a half minute later, etc. to
make sure it will still work OK.

Sometimes a key works fine when the contacts inside are saturated with
contact cleaner liquid.  But when the liquid dries a few minutes later
then the resulting scale deposit left from the evaporation of the
cleaning liquid on the contacts, prevents good contact.  Then the key
may work erratically (if at all).  Operating the key when the liquid
is drying inside may help.  Some switches have the contacts nearly
sealed inside so little if any contact cleaner reaches the contacts.
The cleaner that does get to the contacts may carry contamination with
it (cleaning around the tops before spraying helps minimize this).

If you want to disassemble the key switch, first inspect it to see 
if it comes apart (and if so, how).  Sometimes one may remove the cover
of the switch without removing the switch from the keyboard.  To do
this pry up (or pull up) the top of the key switch after prying apart
thin plastic tabs that retain it.  You may be able to use two small
screwdrivers for this and be able to pry up the switch while prying
apart the plastic retaining tabs.  Don't pry too hard or you may break
the plastic.  If this can't be done, you may have to unsolder the
switch and remove it in order to take it apart (or replace it).  Once
the switch has been taken apart you still may not be able to see the
contacts if the contact surfaces are sandwiched together (nearly
touching).  You may put contact cleaner on the contacts by squirting
some cleaner on an edge so it can penetrate onto the contacts.  Insert
a tiny screwdriver blade just a little so as to pry apart the edges as
you apply the cleaner.  This will help the cleaner reach the contacts.
Work the contacts open and closed with a screwdriver to help clean
them and note if the key is working by looking at the terminal screen.  

There may be some kind of clip holding the contact surfaces together
which needs to be removed so you can pry them apart.  Take care not to
loose small parts as they may fly up into the air when taking apart a
key switch.  As a last resort, you may try bending the moving part
that the push-rod pushes so as to make a stronger contact.  In my
terminal, this part looks like the electrical contact but it just
pushes the real electrical contact thru a thin insulator.

When putting the key switch back together, make sure that the spring
is in the right place.  If, after you assemble the switch, the key
pushes down too hard or too easy, the spring is likely not positioned
right.  If the spring is supposed to be recessed into a hole on the
push rod, one way to temporarily "glue" the spring into the push-rod
is to use a half-drop of water on the end of the spring.  Then insert
this end into the push rod and assemble quickly before the water
dries.  This should keep the spring from falling out of the push rod
during assembly.  Instead of using water, you may stand the keyboard on
end (or upside-down) to keep the spring from falling out during
assembly.

<sect> Appendix A: General

<sect1> List of Linux Terminal Commands

<sect2> Sending a command to the terminal
<p><itemize>
<item> <ref id="setterm_" name="setterm">: long options
<item> <ref id="tput" name="tput">: terse options
<item> reset: initializes only
<item> tset: same as reset
<item> clear: clears screen
<item> setterm -reset: sends reset string
</itemize>

<sect2> Configuring the terminal device driver
<p><itemize>
<item> <ref id="set_serial" name="Setserial">:
<item> <ref id="stty_" name="Stty">
</itemize>

<sect2> Terminfo
<p><itemize>
<item> <ref id="tic" name="Terminfo Compiler (tic)"> terminfo compiler
& translator
<item> toe: shows list of terminals for which you have terminfo
files
<item> <ref id="infocmp" name="infocmp" > compares or displays terminfo
entries
</itemize>

<sect2> Other
<p><itemize>
<item> gitkeys: shows what bytes each key sends to the host.
<item> tty: shows what tty port you are connected to.
<item> reset -q: shows the value of TERM, the terminfo entry name
<item> <ref id="reset_" name="reset">: sets TERM interactively and initializes
</itemize>

<sect1> The Internet and Books

<sect2> Terminal Info on the Internet <label id="internet_">
<p> In the first decade of the 20th century,
http://www.cs.utk.edu/~shuford/terminal_index.html was Shuford's Website
at the University of Tennessee.  It was the major sit for information
about text terminals but is now (2013) defunct.  Perhaps one can find it
archived on the "Wayback" machine.
http://www.cs.utk.edu/~shuford/terminal/repair_hints_news.txt was
Shuford's repair archive of newsgroup postings on terminal repair. See
below for the vt100 part of this website which is still on the internet.

<itemize>
<item> <url url="http://www.vt100.net" name= "vt100 section of Shuford's Website"> 
<item> <url url="http://en.wikipedia.org/wiki/Text_terminal"
name="Text-terminal - Wikipedia">
<item> <url
url="http://en.wikipedia.org/wiki/POSIX_terminal_interface"
name="Terminal Interface per Wikipedia"> 
<item> <url url="www.gnu.org/manual/glibc/html_chapter/libc_12.html"
name="Low-Level Terminal Interface"> part of "GNU C Library Reference
Manual" (in libc (or glibc) docs package).  It covers the detailed
meaning of "stty" commands, etc.
<item> <url url="http://www.boundless.com/terminals.html"
name="Boundless"> purchased the VT and Dorio terminal business from
DEC.  Boundless used to have online Specs of their ADDS, VT, and
DORIO terminals but that link (in previous versions of this HOWTO) is
now dead.  
<item> Wyse had detailed info (such as escape sequences) in it's
knowledge base.  It's not as complete as a real manual since it mainly
cover "native" personality.  It was Wyse text-terminals database" at
http://www.wyse.com/service/support/kbase/wyseterm.aspi but it's defunct.
You may still access their knowledge base (does it still cover
text-terminals) by registering.  Start at <url url="www.wyse.com">.
<item> <url url="http://dickey.his.com/ncurses/ncurses.faq.html"
name="ncurses FAQ"> <item> comp.terminals is the newsgroup for
terminals </itemize>

<sect2> Books related to terminals
<p> <itemize>
<item> EIA-232 serial port see <ref id="RS232_books"
name="EIA-232 (RS-232) Books">.
<item> Repair see <ref id="repair_info" name="Repair Books &
Websites">.
<item> Terminfo database see <ref id="termcap_docs"
name="Termcap Documents">
</itemize>

<sect2> Entire books on terminals
<p> As far as I know, there is no satisfactory book on text terminals
Although this HOWTO has been published as a book, I don't suggest that
that you buy it if you have access to the online version which I'm
improving on every few months or so.  The following are mainly of
historical interest:

<itemize>
<item> Handbook of Interactive Computer Terminals by Duane E. Sharp;
Reston Publishing Co. 1977. (mostly obsolete)
<item> Communicating with Display Terminals by Roger K. deBry;
McGraw-Hill 1985.  (mostly on IBM synchronous terminals)
</itemize>

The "HANDBOOK ... " presents brief specifications of over 100 different
models of antique terminals made in the early 1970's by over 60
different companies.  It also explains how they work physically but
has a diagram for a CRT which erroneously shows electrostatic
deflection of the electron beam (p. 36).  Terminals actually used
magnetic deflection (even in the 1970's).  This book explains a number
of advanced technical concepts such as "random scan" and "color
penetration principle".

The "COMMUNICATING ... " book in contrast to the "Handbook ... " ignores
the physical and electronic details of terminals.  It has an entire
chapter explaining binary numbers (which is not needed in a book on
terminals since this information is widely available elsewhere).  It
seems to mostly cover old IBM terminals (mainly the 3270) in block and
synchronous modes of operation.  It's of little use for the commonly
used ANSI terminals used today on Unix-like systems.  Although it does
discuss them a little it doesn't show the various wiring schemes used
to connect them to serial ports.

<sect2> Books with chapters on terminals
<p> These chapters cover almost nothing about the terminals themselves
and their capabilities.  Rather, these chapters are mostly about how
to set up the computer (and its terminal driver) to work with
terminals.  Due to the differences of different Unix-like systems,
much of the information does not apply to Linux.

<itemize>
<item> Unix Power Tools by Jerry Peck et. al.  O'Reilly 1998.
Ch. 5 Setting Up Your Terminal, Ch. 41: Terminal and Serial Line
Settings, Ch. 42: Problems With Terminals
<item> Advanced Programming in the Unix Environment by W. Richard Stevens
Addison-Wesley, 1993.  Ch. 11: Terminal I/O, Ch. 19: Pseudo Terminals
<item> Essential System Administration by Aleen Frisch, 2nd ed.
O'Reilly, 1998.  Ch. 11: Terminals and Modems.
</itemize>

The "UNIX POWER TOOLS" book has 3 short chapters on text terminals.
It covers less ground than this HOWTO but gives more examples to help
you.

The "ADVANCED PROGRAMMING ... " Chapter 11 covers only the device driver
included in the operating system to deal with terminals.  It explains
the parameters one gives to the stty command to configure the
terminal.

The "ESSENTIAL SYSTEM ..." book's chapter has more about terminals
than modems.  It seems well written.

<sect1> Non-Linux OSs <label id="non_linux">
<p>Under Microsoft's DOS one may use the DOS command "ctty COM2" so
that the DOS command line will display on a serial terminal (on COM2
in this example).  Unfortunately one can then no longer
use the computer monitor since MS DOS is not a multiuser operating
system.  Nor can more than one terminal be used.  So this capability
is of little (if any) benefit.  If you emulate DOS under Linux with
the free dosemu, it's reported that you can run several terminals
(multiuser).  But it's reported that PCTerm emulation doesn't work
with it (yet ??).

While MS didn't create a "multiuser DOS" OS, others did.  This permits
the use of many terminals on one DOS PC.  It's compatible with most
MS-DOS software.  One multiuser DOS OS is named "REAL/32".  The
terminal's "pcterm" emulation is used here.  There also may be a
"scan" (scancodes) setup mode which needs to be set.  Other OSs such
as PICK, PC-MOS, and Concurrent DOS were/are multiuser and support
terminals.

There are 3 programs for Linux which let you run Windows applications
on a Linux PC: free: Wine, non-free: VMware and NeTraverse.  Can they
use text-terminals under DOS?  Wine can't since it doesn't have a DOS
mode.  The other two require you to run the MS Windows OS software as
a "guest OS".  The guest MS Windows OS has a DOS mode but it's not of
much use for text-terminals since it's not multiuser.

For other unix-like OSs, the configuration of the host computer for
terminals is usually significantly different than for Linux.  Here are
some links to on-line manuals for non-linux systems.

<itemize>
<item> <url url=
"http://docsrv.sco.com:507/en/HANDBOOK/serial_terminal_adding.html"
name="Adding Serial Terminals"> in SCO OpenServer Handbook.
<item> Hewlett-Packard's HP-UX <url 
 url="http://docs.hp.com/en/B2355-90675/ch03.html" name="Configuring 
 Terminals and Modems">
</itemize>

<sect> Appendix B: Escape Sequence Commands Terminology <label
  id="esc" >

<p> These are sometimes called "control sequences".  This section of
Text-Terminal-HOWTO is incomplete (and may never be complete as there
are such a huge number of control sequences).  This section is for
reference and perhaps really belongs in something that would be called
"Text-Terminal-Programming-HOWTO".

An example of an ANSI standard escape sequence is ESC[5B which moves
the cursor down 5 lines.  ESC is the Escape character.  The parameter
5 is included in the sequence.  If it were 7 the cursor would move
down 7 lines, etc.  A listing for this sequence as "move cursor down x
lines: ESC[xB" is easy to understand.  But command jargon such as:
"tertiary device attribute request" is less comprehensible.  This
section will try to explain some of the more arcane jargon used for
escape sequence commands.  A full listing (including the escape
sequence codes for the ANSI standard) is a "wish list" project.  Since
many escape sequences do the same thing as is done when setting up the
terminal with <ref id="set_up_pars" name="Set-Up Options">, such
escape sequences options will not be repeated here.

<sect1> Esc Sequence Lists <label id="esc_seq_lists">
<p>See url url= "http://www.neoware.com/docs/teemtalk/t2k17pro.pdf"
name="TeemTalk.2000 Programmer's Guide v 1.7"> in pdf format.   But
there are some sites that have info for certain terminals.  For VT
terminals see <url url="http://www.vt100.net/" name="VT Manuals">.
Other lists have disappeared from the internet. 

<sect1> 8-bit Control Codes
<p> Table of 8-bit DEC control codes (in hexadecimal).  Work on VT2xx or
later.  CSI is the most common.
<tscreen><verb>
ACRONYM  FULL_NAME	 		HEX	REPLACES
IND Index (down one line)		84	ESC D
NEL Next Line				85	ESC E
RI  Reverse Index (one line up)		8D	ESC M
SS2 Single Shift 2			8E	ESC N
SS3 Single Shift 3			8F	ESC O
DCS Device Control String		90	ESC P
CSI Control Sequence Introducer)	9B	ESC [
ST  String Terminator			9C	ESC \
</verb></tscreen>

<sect1> Printer Esc <label id="printer_esc">
<p> <itemize>
<item> Auto Print on/off: When on, data from the host is also teed
 (sent) to the printer port of the terminal (and also shows on the
 terminal screen).
<item> Print Controller on/off: When on, data from the host is sent
 only to the printer (nothing shows on the terminal screen).
</itemize>

<sect1> Reports
<p> These sequences are usually a request sent from the host to
request a report from the terminal.  The terminal responds by sending
a report (actually another escape sequence) to the host which has
embedded in it certain values telling the host about the current state
of the terminal.  In some cases a report may be sent to the host even
if it wasn't asked for.  This sometimes happens when set-up is exited.
By default no unsolicited reports should be sent.

<itemize>
<item> Request for Status (Report Operating Status):  Meaning of
replies for VT100 is either "I'm OK" or "I'm not OK"
<item> Request for Device Attributes:  The "device" is usually the
 printer.  Is there a printer?  Is it ready?
<item> Reqest for Tertiary Device Attributes (VT):  Reply is report that
 was entered during set-up.  The tertiary device is the 3rd device
 (the printer or auxiliary port device ??).  The 1st device may
 be the host computer and the 2nd device the terminal.
<item> Request for Terminal Parameters:  What is the parity, baud
 rate, byte width, etc.  This request doesn't seem to make much sense,
 since if the host didn't already know this it couldn't communicate
 with the terminal or send a reply.
</itemize>

<sect1> Cursor Movements
<p> The cursor is where the next character received from the host will
be displayed.  Most of the cursor movements are self-explanatory.
"index cursor" means to move the cursor down one line.  Cursor
movements may be relative to the current position such as "move 4
spaces left" or absolute such as "move to row 3, column 39".  Absolute
is called "Direct Cursor Positioning" or "Direct Cursor Addressing".

The home position is row 1 col. 1 (index origin is 1).  But where this
home position is on the physical screen is not completely clear.  If
"Cursor Origin Mode" = "Relative Origin Mode" is set, then home is at
the top of the scrolling region (not necessarily the top of the
screen) at the left edge of the screen.  If "Absolute Origin Mode" is
set (the same as unsetting any of the two modes in the previous
sentence) then home is at the upper left corner of the screen.  On
some old terminals if "Cursor Origin Mode" is set it means that it's
relative.

<sect1> Pages (definition) <label id="pages_def">
<p> See <ref id="pages_" name="Pages"> for an explanation of pages.
There are a number of escape sequences to deal with pages.  Text may
be copied from one page to another and one may move the cursor from
page to page.  Switching pages may or may not be automatic: when the
screen becomes full (page 1) then more data from the host goes to page
2.  The cursor may only be on one page at a time and characters which
are sent to the terminal go there.  If that page is not being
displayed, new text will be received by the terminal and go into
display memory, but you will not see it (until the terminal is
switched to that page).

<sect> Appendix C: Serial Communications on EIA-232 (RS-232)
  <!-- keep block mode sect. -->
<sect1> Intro to Serial Communication
<p> (Much of this section is now found in Serial-HOWTO.)  Text
terminals on Unix-like systems (and on PC's) are usually connected to
an asynchronous 232 serial port of a computer.  It's usually a
RS-232-C, EIA-232-D, or EIA-232-E.  These three are almost the same
thing.  The original RS prefix became EIA (Electronics Industries
Association) and later EIA/TIA after EIA merged with TIA
(Telecommunications Industries Association).  The EIA-232 spec
provides also for synchronous (sync) communication but the hardware to
support sync is almost always missing on PC's.  The RS designation is
obsolete but is still in use.  EIA will be used in this article.

The serial port is more than just a physical connector on the back of
a computer or terminal.  It includes the associated electronics which
must produce signals conforming to the EIA-232 specification.  The
standard connector has 25 pins, most of which are unused.  An
alternative connector has only 9 pins.  One pin is used to send out
data bytes and another to receive data bytes.  Another pin is a common
signal ground.  The other "useful" pins are used mainly for signalling
purposes with a steady negative voltage meaning "off" and a steady
positive voltage meaning "on".

The UART (Universal Asynchronous Receiver-Transmitter) chip does most
of the work.  Today, the functionality of this chip is usually built
into another chip.

<sect1> Voltages
<sect2> Voltage for a bit
<p> At the EIA-232 serial port, voltages are bipolar (positive or
negative with respect to ground) and should be about 12 volts in
magnitude (newer ones are 5 volts but the 12 volt example is given
here).   For the transmit and receive pins +12 volts is a 0-bit
(sometimes called "space") and -12 volts is a 1-bit (sometimes called
"mark").  This is known as inverted logic since normally a 0-bit is
both false and negative while a one is normally both true and
positive.  Although the receive and transmit pins are inverted logic,
other pins (modem control lines) are normal logic with a positive
voltage being true (or "on" or "asserted") and a negative voltage
being false (or "off" or "negated").  Zero voltage has no meaning
(except it usually means that the PC is powered off).

A range of voltages is allowed.  The specs say the magnitude of a
transmitted signal should be between 5 and 15 volts but must never
exceed 25 V.  Any voltage received under 3 V is undefined (but some
terminals will accept a lower voltage as valid).  One sometimes saw
erroneous claims that the voltage is commonly 5 volts (or even 3
volts) but it's usually 11-12 volts on older PCs.  If you are using a
EIA-422 port on a Mac computer as an EIA-232 (requires a special
cable) or EIA-423 then the voltage will actually be only 5 V.  The
discussion here assumes 12 V.  There was much confusion about voltages
on the Internet.

Note that normal computer logic normally is just a few volts (5 volts
was once the standard) so that if you try to use test equipment
designed for testing 3-5 volt computer logic (TTL) on a 12 volt serial
port, it may damage the test equipment.

<sect2> Voltage sequence for a byte <label id="byte_seq">
<p> The transmit pin (TxD) is held at -12 V (mark) at idle when nothing
is being sent.  To start a byte it jumps to +12 V (space) for the
start bit and remains at +12 V for the duration (period) of the start
bit.  Next comes the low-order bit of the data byte.  If it's a 0-bit
nothing changes and the line remains at +12 V for another bit-period.
Then comes the next bit, etc.  Finally, a parity bit may be sent and
then a -12 V (mark) stop bit.  The line remains at -12 V (idle) until
the next start bit.  Note that there is no return to 0 volts and thus
there is no simple way (except by a synchronizing signal) to tell
where one bit ends and the next one begins for the case where 2
consecutive bits are the same polarity (both zero or both one).

A 2nd stop bit would also be -12 V, just the same as the first stop
bit.  Since there is no signal to mark the boundaries between these
bits, the only effect of the 2nd stop bit is that the line must remain
at -12 V idle twice as long.  The receiver has no way of detecting the
difference between a 2nd stop bit and a longer idle time between
bytes.  Thus communications works OK if one end uses one stop bit and
the other end uses 2 stop bits, but using only one stop bit is
obviously faster.  In rare cases 1 1/2 stop bits are used.  This means
that the line is kept at -12 V for 1 1/2 time periods (like a stop bit
50% wider than normal).

<sect1> Parity Explained <label id="parity_def">
<p> Characters are normally transmitted with either 7 or 8 bits (of
data).  An additional parity bit may (or may not) be appended to this
resulting in a byte length of 7, 8 or 9 bits.  Some terminal emulators
and older terminals do not allow 9 bits.  Some prohibit 9 bits if 2
stop bits are used (since this would make the total number of bits too
large: 12 bits total).

The parity may be set to odd, even or none (mark and space parity may
be options on some terminals).  With odd parity, the parity bit is
selected so that the number of 1-bits in a byte, including the parity
bit, is odd.  If a such a byte gets corrupted by a bit being flipped,
the result is an illegal byte of even parity.  This error will be
detected and if it's an incoming byte to the terminal an
error-character symbol will appear on the screen.  Even parity works
in a similar manner with all legal bytes (including the parity bit)
having an even number of 1-bits.  During set-up, the number of bits
per character usually means only the number of data bits per byte (7
for true ASCII and 8 for various ISO character sets).

A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
0).  For mark parity, the parity bit is always a one-bit.  For space
parity it's always a zero-bit.  Mark or space parity only wastes
bandwidth and should be avoided when feasible.  "No parity" means that no
parity bit is added.   For terminals that don't permit 9 bit bytes,
"no parity" must be selected when using 8 bit character sets since
there is no room for a parity bit.

<sect1> Forming a Byte (Framing)
<p> In serial transmission of bytes via EIA-232 ports, the low-order
bit is always sent first.  Serial ports on PC's use asynchronous
communication where there is a start bit and a stop bit to mark the
beginning and end of a byte.  This is called framing and the framed
byte is sometimes called a frame.  As a result a total of 9, 10, or 11
bits are sent per byte with 10 being the most common.   8-N-1 means 8
data bits, No parity, 1 stop bit.  This adds up to 10 bits total when
one counts the start bit.  One stop bit is almost universally used.
At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
used but today the 2nd stop bit is used only in very unusual
situations (or by mistake since it seemingly still works OK that way).

<sect1> Limitations of EIA-232
<sect2> Low Speed & Short Distance
<p> The conventional EIA-232 serial port is inherently low speed and
is severely limited in distance.  Ads often read "high speed" but it
can only work at high speed over very short distances such as to a
modem located right next to the computer.  All of the wires use a
common ground return so that twisted-pair technology (needed for high
speeds) can't be used without additional hardware.  However some
computers have more modern interfaces.  See <ref id="non_232"
name="Successors to EIA-232">.

It is somewhat tragic that the RS-232 standard from 1969 did not use
twisted pair technology which could operate about a hundred times
faster.  Twisted pairs have been used in telephone cables since the
late 1800's.  In 1888 (over 110 years ago) the "Cable Conference"
reported its support of twisted-pair (for telephone systems) and
pointed out its advantages.  But over 80 years after this approval by
the "Cable Conference", RS-232 failed to utilize it.   Since RS-232
was originally designed for connecting a terminal to a low speed modem
located nearby, the need for high speed and longer distance
transmission was apparently not recognized.

<sect2> Successors to EIA-232 <label id="non_232">
<p> See the Serial-HOWTO section "Other Serial Devices" for a longer
discussion about non-EIA-232 ports.  A number of EIA standards have
been established for higher speeds and longer distances using
twisted-pair (balanced) technology.  Balanced transmission can
sometimes be a hundred times faster than unbalanced EIA-232.  For a
given speed, the distance (maximum cable length) may be many times
longer with twisted pair.  Few terminals seem to support them.  While
many terminals also support EIA-423 is almost like EIA-232 but is
only 5 volts and somewhat higher speeds (without using twisted pair).
Twisted pair includes EIA-422, EIA-530-A, HSSI (High Speed Serial
Interface), USB (Universal Serial Bus), and of course ethernet.

<sect2> Line Drivers
<p> For a text terminal, the EIA-232 speeds are fast enough but the
usable cable length is often too short.  Balanced technology could
fix this.  The common method of obtaining balanced communication with
a text terminal is to install 2@ line drivers in the serial line to
convert unbalanced to balanced (and conversely).  They are a
specialty item and are expensive if purchased new.

<sect1> Synchronization & Synchronous <label id="sync">
<sect2> How "Asynchronous" is Synchronized

<p> Per EIA-232 there are only two states of the transmit (or receive)
wire: mark (-12 V) or space (+12 V).  There is no state of 0 V.  Thus
a sequence of 1-bits is transmitted by just a steady -12 V with no
markers of any kind between bits.  For the receiver to detect
individual bits it must always have a clock signal which is in
synchronization with the transmitter clock.  Such clocks generate a
"tick" in synchronization with each transmitted (or received) bit.

For asynchronous transmission, synchronization is achieved by framing
each byte with a start bit and a stop bit (done by hardware).  The
receiver listens on the line for a start bit and when it detects one
it starts its clock ticking.  It uses this clock tick to time the
reading of the next 7, 8 or 9 bits.  (It actually is a little more
complex than this since several samples of a bit are often taken and
this requires additional timing ticks.)  Then the stop bit is read, the
clock stops and the receiver waits for the next start bit.  Thus async
is actually synchronized during the reception of a single byte but
there is no synchronization between one byte and the next byte.

<sect2> Defining Asynchronous vs Synchronous

<p> Asynchronous (async) means "not synchronous".  In practice, an
async signal is what the async serial port sends and receives which is
a stream of bytes each delimited by a start and stop bit.  Synchronous
(sync) is most everything else.  But this doesn't explain the basic
concepts.

In theory, synchronous means that bytes are sent out at a constant
rate one after another in step with a clock signal tick.  There is
often a separate wire or channel for sending the clock signal.
Asynchronous bytes may be sent out erratically with various time
intervals between bytes (like someone typing characters at a
keyboard).

There are borderline situations that need to be classified as either
sync or async.  The async serial port often sends out bytes in a
steady stream which would make this a synchronous case but since they
still have the start/stop bits (which makes it possible to send them
out erratically) its called async.  Another case is where data
bytes (without any start-stop bits) are put into packets with possible
erratic spacing between one packet and the next.  This is called sync
since the bytes within each packet must be transmitted synchronously.

<sect2> Synchronous Communication
<p> Did you ever wonder what all the unused pins are for on a 25-pin
connector for the serial port?  Most of them are for use in
synchronous communication which is seldom implemented on PC's.  There
are pins for sync timing signals as well as for a sync reverse
channel.  The EIA-232 spec provides for both sync and async but PC's
use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
a 16450, 16550A, or 16650 and can't deal with sync.  For sync one
needs a USART chip or the equivalent where the "S" stands for
Synchronous.  Since sync is a niche market, a sync serial port is
likely to be quite expensive.

Besides the sync part of the EIA-232, there are various other EIA
synchronous standards.  For EIA-232, 3 pins of the connector are
reserved for clock (or timing) signals.  Sometimes it's a modem's task
to generate some timing signals making it impossible to use
synchronous communications without a synchronous modem (or without a
device called a "synchronous modem eliminator" which provides the
timing signals).

Although few serial ports are sync, synchronous communication
does often take place over telephone lines using modems which use
V.42 error correction.  This strips off the start/stop bits and puts
the date bytes in packets resulting in synchronous operation over the
phone line.

<sect1> Block Mode <label id="block">

<sect2> Introduction to Block Mode
<p> Block mode is seldom used with Linux and is mainly of historical
interest.  In block mode, when one types at a terminal the results are
saved in the terminal memory and are not sent just yet to the host
computer.  Such terminals often have built-in editing capabilities.
When the user presses certain keys (such as the send key) what has
been saved in the terminal memory is sent to the host computer.  Now
the Linux editors vi and emacs, must react instantly to typing certain
keys so block mode isn't feasible.  Such editors and other interactive
programs can't permit the long delay in sending a keystroke to the
computer which is inherent in block mode.  So they can't use block
mode.

The old IBM mainframe interface uses block mode (see <ref id="ibm_"
name="IBM Terminals "> so many IBM terminals are block-mode only and
also synchronous (see Section <ref id="sync" name="Synchronization &
Synchronous">).

<sect2> Types of Block Modes, Forms
<p> Block mode may itself have various sub-modes such as "page" (a
page at a time) and "line" (a line at a time).  Some terminals have
both block transmission modes and conventional character modes and may
be switched from one mode to another.  Async terminals which have
block modes include HP2622A, Wyse60, VT130, VT131, VT330, VT340, and
Visual500.  Many later model terminals can emulate block mode.  But
the Linux console can't.  Block modes may include a forms capability
where the host computer sends a form to the terminal.  Then the user
fills it out and hits the send key which sends only the data in the
form back to the host computer.  The form itself (not the data) is
displayed on the screen in protected fields which don't get
transmitted to the host.

<sect2> Efficiency
<p> Block mode takes load off the host computer, especially if the
host computer's hardware is designed for block modes (as IBM
mainframes were).  In character mode every character typed is sent
immediately to the serial port and usually causes an interrupt at the
host computer.  The host that receives the byte must stop whatever it
is doing and fetch that character from the port hardware.  Even with
UART's that have FIFO hardware buffers, the hardware timeout is
normally only the transmission time of 3 bytes so that an interrupt is
usually issued for every character typed.

In true block mode a long block of characters is received using only
one interrupt.  If block mode is used with conventional async FIFO
serial ports, an interrupt is needed only every 14 bytes since they
have 16-byte hardware buffers.  Thus much of the load and overhead of
interrupt handling is eliminated and the computer has more time to do
other tasks when block mode is used.

A significant savings for block mode occurs if the terminal is
connected to its host via a network.  Without block mode, every
character (byte) typed is sent in its own packet including all the
overhead bytes (40 in a TCP/IP packet as used on the Internet).  With
block mode, a large number of characters are sent in a single packet.

<sect2> Problems with block mode
<p>While block mode is more efficient, it is nearly extinct, and for
good reason.  Faster and cheaper computers made the higher efficiency
less important.  For example, a 56k modem results in hundreds of
interrupts per second (every 14 characters) while typing at a terminal
only causes a few interrupts per second (one for each character
typed).  So the number of interrupts caused by typing at a terminal
is not very significant (unless you have hundred of terminals
connected to the same computer).

Another point is that the efficiency is not of much significance where
the user doesn't type in very much.  Editors are a primary example of
where the user types in a lot.   But if you use block mode for
editing, you must then use the crude editor built into terminal.  Modern
editors like vim and emacs are much better but can't use block mode.
Even in the days of mainframes with terminals, block mode wasn't used
much except by IBM.  A major reason was that software to utilize it
was not widely available (except for IBM).  The terminfo data base
doesn't seem to include it and this would complicate writing software
for it.

<sect1> EIA-232 (RS-232) Books <label id="RS232_books">
<p> (Note: The first book covers much more than just EIA-232.)
<itemize>
<item> Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE
	Computer Society Press, Los Alamitos, CA, 1996.
<item> Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
<item> Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
<item> Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall,
	1991.
</itemize>

<sect1> Serial Software
<p> See <url url="ftp://ibiblio.org/pub/Linux/system/serial/"
name="Serial Software"> for Linux software for the serial ports
including getty and port monitors.

<sect> Appendix D: Notes by Brand/Model

<p> Here are notes by brand name that were too specific to a certain
terminal to be put elsewhere in this HOWTO.  If you have some info to
contribute on a certain terminal that is not covered elsewhere, it
could go here.  Various models often have much in common so such
common information need only be written about once.  It would be
nice if for each terminal model, there were a set of links linking to
most of the documentation relevant to that model (including escape
codes).  But it hasn't been done.  Note that some VT (DEC) manuals are
now available on the Internet.  See and <ref id="dec_" name="VT
(DEC)">.  Wyse put the information from its manuals on the
Internet but it can't be readily found now (2013).  

<sect1> Adds
<p>The Adds terminal menu incorrectly used "Xon/Xoff" to mean any kind
of flow control.  True for which models ??

Adds, which made the Adds Viewpoint terminal, was taken over by
Boundless Technologies in 1994 but they continued to use the "Adds"
name.

<sect1> CIT
<p> CIT terminals were made in Japan in the 1980's for CIE Terminals.
They ceased to be imported in the late 1980's.  The company, CIE,
still made CItoh printers (in 1997) but has no parts for its
abandoned terminals.  Ernie at (714) 453-9555 in Irvine CA sold (in
1997) some parts for models 224, 326, etc. but has nothing for the 80
and 101.

To save the Set-Up parameters press ^S when in Set-Up mode.
cit80: Contrast: knob on rear of terminal,
cit101e: Brightness: use up/down arrow keys in Set-Up mode.

<sect1> IBM Terminals <label id="ibm_">

<p> Don't confuse IBM terminals with IBM PC monitors.  Many IBM
terminals don't use ASCII but instead use an 8-bit EBCDIC code.  It's
claimed that in EBCDIC the bit order of transmission is reversed from
normal with the high-order bit going first.  The IBM mainframe
communication standards are a type of synchronous communication in
block mode (sends large packets of characters).  Two standards are
"BISYNC" and "SNA" (which includes networking standards).  Many of
their terminals connect with coax cable (RG62A/U) and naive persons
may think the "BNC" connecter on the terminal is for ethernet (but
it's not).

While this IBM system is actually  more efficient than what is
normally used in Linux, terminals meeting this IBM standard will not
currently work with Linux.  However, some IBM terminals are
asynchronous ASCII terminals and should work with Linux on PC's.  The
numbers 31xx may work with the exception that 317x and 319x are not
ASCII terminals.  Before getting an IBM terminal, make sure there is a
termcap (terminfo) for it.  If their isn't, it likely will not work
with Linux.  Even if there is a terminfo, it may not work.  For
example, there is a termcap for 327x but the 3270 is an EBCDIC
synchronous terminal.

The 3270 series includes the 3278 (late 1970's), 3279 with color and
graphics, and the 3274 terminal controller (something like the 3174).
They may be used for both BISYNC and SNA.  The 3290 has a split screen
(splits into quarters).

The synchronous IBM terminals don't connect directly to the IBM
mainframe, but connect to a "terminal controller" (sometimes called
"cluster controller" or "communication controller").  Some of these
controllers can convert a synchronous signal to asynchronous so that in
this case a synchronous terminal could indirectly connect to a
Unix-like host computer via its serial port.  But there is still a
major problem and that is block transmission.  See section <ref
id="block" name="Block Mode">.

<sect2> IBM 3153
<p> It's claimed that the Aux port is DCE and uses a straight-thru
cable.

<sect1> Teletypes <label id="teletype">
<p> These are antiques and represent the oldest terminals.  They are
like remotely controlled typewriters but are large and noisy.  Made by
the Teletype Corp., the first models were made in the 1920's and
predate the computer by over 30 years.  Early models used
electro-mechanical relays and rotating distributors instead of
electronics.  Their Baudot code was only 5-bits per character as
compared to 7-bit ASCII.  See the book "Small Computer Systems
Handbook" by Sol Libes, Hayden Books, 1978: pp. 138-141 ("Teletypes").

<sect1> VT (originally DEC, now Boundless) <label id="dec_">
<p> Digital Equipment Corporation (DEC) made the famous VT series of
terminals including the commonly emulated VT100.  

In 1995 DEC sold their terminal business to Boundless Technologies.
Boundless went bankrupt in 2003 but emerged from bankruptcy in 2006 as
a division of "Visual Technologies".  Then in 2008 they were acquired
by Video Display Corporation and given to their Z-AXIS subsidiary
located near Rochester, New York.  The <url
url="http://www.boundless.com/terminals.html" name="Boundless"> name
and url have been retained.

Detailed VT terminal information, some manuals, and
history is at <url url="http://www.vt100.net/">.

VT220: Some have a BNC connector for video output (not for input).
Sometimes people erroneously think this is for an ethernet connection.

VT510, 520, 525: Supports full DTR/DSR flow control.  Some are "low
emissions" models. The 520 is multi-session and the 525 has colors for
highlighting.

Dorio is a lower quality model which can emulate many other terminals.
The "sco unix console" is claimed to be a powerful emulation using the
"scoansi" terminfo.

<sect1> Links
<p> The terminal maker Links was taken over by Wyse.

<sect1> Qume
<p> Qume was taken over by Wyse in the early 1990s.

<sect1> Wyse Terminals <label id="wyse_">
<p> detailed manual-like information on old terminals see <url
url="http://www.wyse.com/service/support/kbase/wyseterm.asp">.  This
information includes specs, lists of escape sequences, part lists,
FAQs, setup info, etc.   Thanks to Wyse for providing this even though
as of 2006 they are no longer making text terminals.

Wyse terminals were lower in cost than other brands and they captured
a major share of the market.  There were concerns about the quality of
these terminals, especially the Wyse 50.  But the large number of
failure reports (other than Wyse 50) may be due in part to the large
number of Wyse terminals in use.

See <url url="en.wikipedia.org/wiki/Dell_Wyse"> for a history of Wyse.

<sect2> Wyse 50
<p>Reported not to last very long.

<sect2> Wyse 60
<p> Display adjustments (must remove cover): Brightness VR202, Height
VR302, Width VR101 (also affects height).  If you want to use it in
Native Personality, then the arrow-key codes will conflict with the
codes used in vi (such as ^L).  To fix this set "Application key mode"
with ESC &tilde; 3.  This results in the arrow keys sending 0xd0 - 0xd3.
Due to a bug in the readline interface of the Bash shell, you need to
edit /etc/inputrc so that the arrow keys will work in Bash.  See <ref
id="bash_bug" name="Bugs in Bash">

<sect2> Wyse 85
<p> Can emulate VT52/VT100/VT200.  Press F3 for setup.  After moving
left/right to go a menu "icon", press space to select it.  Scroll
thru setup menus with up/down keys.  Press F3 at any time to reenter
setup (without loosing any settings).

<sect2> Wyse 99-GT
<p> Here is the setup Menus of the Wyse99GT (late 1980's).  Note that
TERM means "termination" (character) and not "terminal".

<tscreen><verb>  WYSE 99-GT Terminal Set-Up as used at the University of CA, Irvine

		by David Lawyer, April 1990

			F1 DISP:
COLUMNS=80		LINES=24		CELL SIZE=10 X 13
STATUS LINE=STANDARD	BACKGROUND=DARK		SCROLL SPEED=JUMP
SCREEN SAVER=OFF	CURSOR=BLINK BLOCK	DISPLAY CURSOR=ON
ATTRIBUTE=CHAR		END OF LINE WRAP=ON	AUTO SCROLL=ON
----------------------------------------------------------------------------
			F2  GENERAL:
PERSONALITY=VT 100	ENHANCE=ON		FONT LOAD=OFF
COMM MODE=FULL DUPLEX	RCVD CR=CR		SEND ACK=ON
RESTORE TABS=ON		ANSWERBACK MODE=OFF	ANSWERBACK CONCEAL=OFF
WIDTH CHANGE CLEAR=OFF	MONITOR=OFF		TEST=OFF
----------------------------------------------------------------------------
			F3 KEYBRD:
KEYCLICK=OFF		KEYLOCK=CAPS		KEY REPEAT=ON
RETURN=CR		ENTER=CR		FUNCT KEY=HOLD
XMT LIMIT=NONE		FKEY XMT LIMIT=NONE	BREAK=170MS
LANGUAGE=US		MARGIN BELL=OFF		PRINTER RCV=OFF
----------------------------------------------------------------------------
			F4 COMM:
DATA/PRINTER=AUX/MODEM	  MDM RCV BAUD RATE=9600  MDM XMT BAUD RATE=9600
MDM DATA/STOP BITS=8/1	  MDM RCV HNDSHAKE=NONE	  MDM XMT HNDSHAKE=NONE
MDM PARITY=NONE		  AUX BAUD RATE=9600	  AUX DATA/STOP BITS=8/1
AUX RCV HNDSHAKE=NONE	  AUX XMT HNDSHAKE=NONE	  AUX PARITY=NONE
(There is a main port (Modem=MDM) and an Auxiliary Port (AUX)
----------------------------------------------------------------------------
			F5 MISC 1:
WARNING BELL=ON		FKEY LOCK=OFF		FEATURE LOCK=ON
KEYPAD=NUMERIC		DEL=DEL/CAN		XFER TERM=EOS
CURSOR KEYS=NORMAL	MARGIN CTRL=0		DEL FOR LOW Y=ON
GIN TERM=CR		CHAR MODE=MULTINATIONAL
----------------------------------------------------------------------------
			F6 MISC 2:
LOCAL=OFF		SEND=ALL		PRINT=NATIONAL
PORT=EIA DATA		SEND AREA=SCREEN	PRINT AREA=SCREEN
DISCONNECT=60 MSEC	SEND TERM=NONE		PRINT TERM=NONE
PRINT MODE=NORMAL	VT100 ID=VT100		POUND=US
----------------------------------------------------------------------------
F7 TABS: You should see several "T" characters spaced 8 dots apart.
    If you don't, hit backspace.
F8 F/KEYS: Normally you will see no definitions for the Function Keys
    here (unless someone has set them up and saved them).  This means that
    they will normally generate their default settings (not displayed here).
    <ctrl><F5> shows the "user defined definition" of the F5 key, etc.
F9 A/BACK: Normally not defined: ANSWERBACK =
F10 EXIT: Selecting "DEFAULT ALL" will make the factory default settings
    the default.
</verb></tscreen>

HINTS on use of WY-99GT User's Guide:
Note that much that is missing from this Guide may be found in the
WY-99GT Programmer's Guide.  The VT100 emulation (personality) is
known as ANSI and uses ANSI key codes per p. A-10+ even though the
keyboard may be ASCII.  A sub-heading on p. A-13 "ASCII Keyboard" also
pertains to VT100 because it has an "ANSI KEY ..." super-heading a few
pages previously.  But not all ASCII keyboard headings pertain to
VT100 since they may fall under a non-ANSI personality super-heading
which may found be a few pages previously.  Appendix H is the "ANSI
Command Guide" except for the VT52 (ANSI) personality which is found
in Appendix G.

<sect2> Wyse 150
<p> When exiting set-up using F12, hitting space changes "no" to "yes"
to save the set-up.  The sentence to the left of this no/yes is about
"vertical alignment" and has nothing to do with this no/yes for saving
the set-up (confusing menu design).

<sect2> Wyse 185
<p>Has 10x20 character cells.  Can emulate DEC VT320.  Uses 45 watts power.
Later models were 185e.

<sect2> Low Emissions: -ES
<p>ES after the model number means low emissions: low magnetic field,
etc.

END OF Text-Terminal-HOWTO
</article>