Text-Terminal-HOWTO
David S. Lawyer mailto:dave@lafn.org
v1.43 March 2013
-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------
1. Introduction
For a quick attempt to install a text-terminal see Quick_Install.
1.1 Copyright, Trademarks, Disclaimer, & Credits
Copyright
Copyright 1998-2010 by David S. Lawyer. mailto:dave@lafn.org
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:
1. 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.
2. 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.
3. Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a translation, it's
requested that you discuss your plans with the current maintainer.
Disclaimer
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.
Trademarks.
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.
Credits
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.
1.2 Future Plans: You Can Help
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.
1.3 New Versions of this HOWTO
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: http://
www.tldp.org/mirrors.html). To quickly check the date of the latest version
look at 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): (cvs)_Text-Terminal-HOWTO.sgml
* 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.
1.4 Related HOWTOs
Go to the nearest mirror site (per above) to get HOWTOs.
* 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.
* NCURSES-Programming-HOWTO
* MacTerminal mini-HOWTO
* Modem-HOWTO
* Serial-Programming-HOWTO
* NC mini-HOWTO
* NCD-X-Terminal mini-HOWTO
* XDM-and-X-Terminal mini-HOWTO
* Connecting-X-Terminals-to-Linux-Mini-HOWTO
* NCD-HOWTO
* Thinclient-HOWTO
* Xterminals-HOWTO
* Xterm-Title-HOWTO (only for changing the title of a window)
1.5 Terminology Used in this Document
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.
1.6 What is a Terminal ?
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.
1.7 Real Text Terminals
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..
2. Types of Terminals
2.1 Dumb Terminals
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.
2.2 Text Terminals
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 Block_Mode.
2.3 Graphic GUI Capabilities of Text Terminals
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.
Graphics GUI displays
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 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).
3. Thin Clients Terminals
3.1 Introduction
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 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 Thin_clients_and_NCs
under_Linux
3.2 MS Window terminals
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: 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.
3.3 Network computers (NC's)
See 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.
3.4 Thin clients and NCs under Linux
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 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
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:
* JavaStation-HOWTO (by Sun)
* NC-HOWTO (IBM NetStation)
* NCD HOWTO (NCD-ThinSTAR)
* NCD-X-Terminal HOWTO
* XDM-and-X-Terminal HOWTO
3.5 Hardware hookups
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.
3.6 History and the future
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.
4. Quick Text-Terminal Install
This is a quick procedure to install a terminal without going through a 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 /etc/termcap or terminfo.src to find an
entry for it (see 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 Device_Names). As the root user, edit /etc/inittab and add a getty command
next to the other getty commands. The format of the getty command depends on
which getty program you use. agetty (called just getty in the Debian
distribution) is the easiest (no configuration file). See the "info" or "man re
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 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 Trouble-
Shooting.
5. Why Use a Terminal ?
5.1 Intro to Why Use a Terminal
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.
5.2 Lower Hardware Costs ?
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.
5.3 Control of Software
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.
5.4 Hardware Upgrades
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.
5.5 Other Advantages of Terminals
* The elimination of noise from fans and disk drives (unless you're using a PC
to emulate a terminal).
* 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.
5.6 Major Disadvantages of Text Terminals
* 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.
* 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 Problem_with_Slow_Scrolling
* 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.
5.7 Major Disadvantages of All Terminals
* If the host computer goes down, then no one can use the terminals either
(unless there is a "standby" host computer to connect to).
* 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.
5.8 Are Text Terminals Obsolete ?
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:
* 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.
* Some people don't need full screen graphics.
* 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.
6. Overview of How Text Terminals Work (in Linux)
See also section Some_Details_on_How_Terminals_Work
6.1 Device Names
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 Terminal
Special_Files for details on these and related "devices".
6.2 Login/Logout
When the host computer starts up it runs the program getty. The getty program
runs the "login" program to log people in. See 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 Login_Restrictions regarding restricting logins
(including allowing the root user to log in at terminal).
6.3 Half/Full Duplex
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.
6.4 Terminal Memory
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 Terminal_Memory_Details for more details.
6.5 Commands for the Terminal
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 Control_Codes (bytes) and 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 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 Esc_Sequence_List
6.6 Lack of Standardization Solved by Terminfo
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 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.
6.7 The Interface
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 Terminal
Set-Up_(Configure)_Details). The computer serial port has options also and
these options must be set up in a compatible way (see Computer_Set-Up_
(Configure)_Details.
6.8 Emulation
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 Terminal_Emulation.
6.9 The Console
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 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 Make_a_Serial_Terminal_the_Console.
7. Terminal Special Files such as /dev/tty
"tty" is an abbreviation for "Teletype". The first terminals were Teletypes
(like remotely controlled typewriters). See subsection 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.
7.1 Serial Port Terminals
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).
7.2 Pseudo Terminals
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:
CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
7.3 The Controlling Terminal /dev/tty
/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).
7.4 /dev/ttyIN "Terminals"
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.
7.5 The Console: ttyN or vc/N
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 The_Linux_Console.
7.6 Creating a Device with "mknod"
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 mknod
you must know the major and minor device numbers. You might be able to infer
the numbers you need by using the "ls -l" command in the /dev directory. It
will display the major and minor numbers of existing special files.
8. Some Details on How Terminals Work
If you know almost nothing about terminals, it's suggested that you first read
Introduction and also read Overview_of_How_Terminals_Work.
8.1 Terminal Memory Details
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).
8.2 Early Terminals
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 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.
8.3 Escape Sequences and Control Codes (intro)
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.
Control codes
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.
Escape sequences
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 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 Esc
Sequence_List. By searching the Internet for one sequence (such as ESC[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 Terminfo_and_Termcap_(detailed) in
this document and/or the 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.
8.4 Display Attributes & Magic Cookies
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.
9. Special Features/Types of Some Terminals
9.1 Terminal Uses a PC Monitor
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.
9.2 Color
Emulated text terminals
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 Colors
on_Emulated_Terminals
Old real text terminal
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.
9.3 Multiple Sessions
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".
9.4 Printer/Auxiliary Port
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 Printer
Esc.
There is a program called 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 vtprint. It's also included in the Debian distribution of
Linux. 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.
9.5 Pages
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.
9.6 Character-Sets
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:
* Manual pages: charsets, iso_8859-l or latin1 (covers 8859 series), ascii
* HOWTO's for various languages (often written in that language).
* ISO-8859_Alphabet_Soup More than just iso8859. Extensive.
* A_tutorial_on_character_code_issues Clearly written.
* Languages,_Countries_and_Character_Sets
* Languages_of_the_World_by_Computers_...
* ..._International_Character_Sets
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.
Graphics (Line Drawing, etc.)
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.
National Replacement Characters (obsolete)
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:
@ [ \ ] ^ ` { \ } ~
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:
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 --------
9.7 Fonts
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
http://www.ibiblio.org/pub/Linux/utils/terminal/
For mapping the keyboard (and screen) for use of various fonts see Character
Mapping:_mapchan
9.8 Keyboards & Special Keys
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).
* 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.
* NO SCROLL stops the screen from scrolling like ^S does. Depressing it again
resumes scrolling. Uses flow control signals to do this.
* 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.
* LINE FEED sends the line feed character ^J to the host. Seldom used.
* 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 Getting_Into_Set-Up_(Configuration)_Mode.
* LOCAL disconnects the terminal from the host. In local, what one types goes
directly to the screen. Useful for testing.
* 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.
* F1, F2, ... or PF1, PF2, ... are function keys which sometimes may be
programmed to send out a sequence of bytes (characters). See Function_Keys
9.9 Mouse
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 ??
10. Terminal Emulation (including the Console)
10.1 Intro to Terminal Emulation
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 Make_a_Linux_PC_a_serial_port_terminal. Emulation software for
this also available for use under MS Windows. See 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.
10.2 Don't Try to Use TERM Variable for Emulation
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.
10.3 Serial Communication programs
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 telix and procomm work just as well. The
terminal emulated is often the old VT100, VT102, or ANSI (like VT100).
Emulation under X Window
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 Ubuntu_--_x-terminal-
emulator for a brief list of such emulators. Some are multilingual. Your Linux
distribution has likely installed one for you.
Real terminals once were better
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.
10.4 Testing Terminal Emulation
For the VT series terminals there is a test program: 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:
http://www.ibiblio.org/pub/Linux/utils/console/
10.5 The Linux Console
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 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 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.
10.6 Emulation Software
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.
Make a Linux PC a serial port terminal
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 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 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 ASASHI_DOT_NET:
PITUX,_micro_SERIAL_TERMINAL_LINUX
TERM (non-free commercial software from Century Software) 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.
Make a Linux PC an IBM network terminal
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.
Make a non-Linux PC a terminal
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" 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 http://www.ttwin.com/ or http://
www.turbosoft.com.au/ (Australia). See also 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. 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.
10.7 Colors on Emulated Terminals
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 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 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 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.
11. Flow Control (Handshaking)
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:
1. Byte flow from the computer to the terminal
2. Byte flow from the terminal keyboard to the computer.
11.1 Why Is Flow Control Needed ?
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.
11.2 Padding
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
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 stty
command involve padding.
11.3 Overrunning a Serial Port
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.
11.4 Stop Sending
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.
11.5 Keyboard Lock
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.
11.6 Resume Sending
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.
11.7 Hardware Flow Control (RTS/CTS etc.)
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 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).
RTS/CTS, DTR, and DTR/DSR Flow Control
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.
Connecting up DTR or DTR/DSR Flow Control
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 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.
Old RTS/CTS handshaking is different
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.
Reverse Channel
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.
11.8 Is Hardware Flow Control Done by Hardware ?
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.
11.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control
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.
12. Physical Connection
12.1 Introduction
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).
12.2 Multiport I/O Cards (Adapters)
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.
12.3 Direct Serial Cable Connection.
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 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).
Pin numbering
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.
Null Modem cable pin-out (3, 4, or 5 conductor)
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 A_Kludge_using_Twisted-Pair
Cable. For a DB25 connector on your PC, you need:
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
If you have a DB9 connector on your PC, try the following:
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
**
If you have a DB9 connector on both your serial port and terminal:
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
**
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" ).
Standard Null Modem cable pin-out (7 conductor)
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).
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
Alternatively, a full DB9-DB25 file-transfer (null-modem) cable (will not work
with terminal hardware handshaking; see above):
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)
(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):
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)
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 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.
Overcoming length limitations
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.
Hardware Flow Control cables
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 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 Hardware_Flow_Control for a detailed explanation of it.
Older terminals may have no provision for hardware flow control.
Cable tips
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.
A kludge using twisted-pair cable
See also 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.
Cable grounding
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 ??
12.4 Modem Connection
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.
Dialing out from a terminal
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.
Terminal gets dialed into
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.
12.5 Telnet and ssh
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.
12.6 Terminal Server Connection
What is a terminal server ?
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.
Evolution of the "terminal server"
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.
12.7 Connector and Adapter Types
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.
Sex of connector/adapters
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.
Types of adapters
There are three basic types of adapters: null modem, gender changers and port
adapters. Some adapters perform more than one of these three functions.
* null modem adapter: Reroutes wires, like a null modem cable.
* gender changer: Changes the sex of a cable end. Two connectors of the same
sex can now connect (mate) with each other.
* port adapter: Goes from one type of connector to another (DB9 to DB 25, etc.)
DB connectors
(For how to install a DB connector on the ends of a cable see 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 DB9-DB25 for the pin-out. The pins are usually numbered if you
look closely enough or use a magnifying glass.
RJ modular connectors
RJ means Registered Jack. These look like modern telephone connectors but are
sometimes not compatible with telephone connectors. See also 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.
6-conductors: RJ11/14, RJ12, and MMJ
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.
Plug Jack (or socket)
(Looking at the end (Looking at the cavity
end of a cable) in a wall or PC back)
.________. .________.
| 654321 | | 123456 |
|__. .__| |__. .__|
|__| |__|
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:
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
8-conductors and 10-conductors
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:
Plug Jack (or socket)
(Looking at the end (Looking at the cavity
end of a cable) in a wall)
.__________. .__________.
| 87654321 | | 12345678 |
|__. .__| |__. .__|
|____| |____|
12.8 Making or Modifying a Cable
Buy or make ?
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.
Pin numbers of 9 and 25 pin connectors
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.
___________
________________________________________
\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/
------ --------------------------------
---
Installing DB connectors on cable ends
See 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.
Installing RJ connectors
These are telephone modular connecters one type of which is used for most
ordinary telephones. But there are many different types (see 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.
13. Set-Up (Configure) in General
13.1 Intro to Set-Up
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 Terminal_Set-Up and the computer (see
Computer_Set-Up_(Configure)_Details.
13.2 Terminal Set-Up (Configure) Overview
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 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 Terminal_Set-Up.
13.3 Computer Set-Up (Configure) Overview
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 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 Computer
Set-Up_(Configure)_Details.
13.4 Many Options
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?
13.5 Communication Interface Options
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 Getty_(used_in_/etc/inittab)
The settings for both the computer and the terminal are:
* Speed_(bits/second)
* Parity
* Bits_per_Character
* Flow_Control
Some essential settings for the terminal alone are:
* Port_Select
* Set communication to full duplex (=FDX on Wyse terminals)
If the 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 Stty_&
Setserial commands.
Speed
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.
Parity & should you use it ?
For a definition see 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.
Bits/Character
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 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.
Which Flow Control (Handshaking) ?
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 Flow_Control for an explanation of flow
control.
Port select
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).
13.6 Quick Attempt
While all the above may seem overly complex, to get a terminal working is often
fairly simple. The 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.
14. Terminal Set-Up (Configure) Details
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 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.
14.1 Send Escape Sequences to the Terminal
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 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 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 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.
14.2 Older Terminals Set-Up
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.
14.3 Getting Into Set-Up (Configuration) Mode
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.
* Wyse: First try the shifted "Select" key; then substitute Ctrl for shifted in
all of the above.
* 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.
* IBM: 3151: Ctrl-ScrollLock. 3153: Ctrl-Minus_on_Keypad (or like 3151)
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).
14.4 Communication Options
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 Communication_Interface. The following list provides some links to
that section, as well as some additional communication options set only at the
terminal.
* Speed_(bits/second) (baud rate): 9600, 19200, etc.
* Parity none, even, odd, mark, space
* Bits_per_Character {Data}: 7 or 8
* Flow_Control: or Handshake {Hndshk}: none, Xon-Xoff, or hardware (DTR, etc).
o Receiver Handshake {Rcv Hndshk} protects data being Received by the
terminal by transmitting flow-control signals to the host.
o 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".
* number of stop bits: 1 or 2. See Voltage_Sequence_for_a_Byte
* 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.
* Communication_Mode {Comm}: Full_Duplex_{FDX},_Half_Duplex_{HDX} {{Local
Echo}}, Local_Mode {{Online/Local}}
* 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.
* Function-Key Rate Limit: as above but for function key messages.
* Port_Select: Which physical connecter is for the host {Host Port} ?
14.5 Saving the Set-up
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.
14.6 Set-Up Options/Parameters
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 {{...}}.
14.7 Emulation {Personality} {{Terminal Modes}}
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 ??).
14.8 Display Options
Character Cell Size {Char Cell}
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.
Columns/Lines
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 Terminal_doesn't_scroll
Cursor
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.
Display Attributes (Magic Cookies)
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).
Display Control Characters {Monitor}
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 Control_Codes.
Double Width/Height
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.
Reverse Video {Display} (Background Light/Dark)
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).
Status Line
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.
Upon 80/132 Change: Clear or Preserve?
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.
14.9 Page Related Options
For a Wyse terminal to be able to access multiple pages of display memory
{Multipage} must be set to on.
Page Size
The terminal memory may be divided up into a number of pages. See Pages and
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.
Coupling (of cursor & display)
The terminal memory may be divided up into a number of pages. See Pages and
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".
14.10 Reporting and Answerback
The terminal will identify itself and its state, or send out a pre-recorded
message in response to certain escape sequences.
Answerback Message (String)
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).
Auto Answerback
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 ??
Answerback Concealed
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).
Terminal ID {ANSI ID}
The terminal sends this reply in answer to a request for identity.
14.11 Keyboard Options
Keyclick
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.
Caps Lock {Keylock}
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.).
Auto Repeat {Repeat}
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.
Margin Bell
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.
Remapping the Keys
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 Character_Mapping:_mapchan
Corner Key (for Wyse only)
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:
* Hold: No-Scroll. Hitting it stops the flow of data (using flow control) to
the terminal. Hitting the key again restores normal flow.
* Compose: Hitting it followed by certain other keys permits one to generate a
limited number of pre-defined non-Latin characters.
* 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 ??
* Funct: Holding it down while typing any alphanumeric key gets a header (SOH)
and trailer (CR) byte framing the ASCII byte code.
* Kpd Compose: Holding it down while typing a decimal number on the numeric
keys (followed by "enter") sends out the same number in hexadecimal ??
Numeric Keypad or Arrow Keys Sends
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.
What does shifted-del and shifted-bs send?
Depending on how they're set up, shifted-del sometimes sends the control
character CAN and shifted backspace sometimes sends DEL.
PC Scan Codes
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 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.
Alternate Characters
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.
14.12 Meaning of Received Control Codes
Auto New Line {Newline}
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.
Auto Line Feed {Rcv CR}
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.
Recognize Del (Wyse Only ??) or Null
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 Padding
14.13 Where New Text Goes
Line Wrap
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.
Scrolling
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.
New Page?
See Pages and 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.
14.14 Function Keys
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).
14.15 Block Mode Options
Some options are only for the case of 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.
Forms Display
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)
Send Entire Block ?
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}
Region to Send
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.
Block/Page terminator
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.
14.16 Locks
There are various types of Locks. One is the Locked keyboard due to flow
control. See 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.
14.17 Screen Saver {Scrn Saver}
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.
14.18 Printer
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.
15. Computer Set-Up (Configure) Details
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).
15.1 Getty (used in /etc/inittab)
Introduction to Getty
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 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:
Two gettys best for directly connected terminals are:
1. agetty (sometimes just called getty): Easy to set up with no config
required. See agetty
2. getty_(part_of_getty_ps) More advanced with config file.
Two gettys best for dial-in modems (avoid for directly connected terminals)
are:
1. mgetty: the best one for modems; works for terminals too but inferior
2. uugetty: for modems only; part of the getty_ps package
Simple gettys to use if you don't use a real text-terminal. Most Linux users
use one of these at their monitor:
1. mingetty
2. fbgetty
3. fgetty
4. rungetty
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: 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:
strings getty | grep getty
If getty is actually agetty the above will result in nothing. However if you
have agetty typing:
getty -h
should show the agetty options [-hiLmw].
The source codes for various gettys may be downloaded from 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.
Getty exits after login (and can respawn)
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).
If getty run from command line: Programs get stopped
You should normally run getty from inside /etc/inittab 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: "[1]+ Stopped" 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.
agetty (may be named getty)
agetty means "alternative getty" and it was an easier-to-use alternative to the
original getty (getty_ps).
An example line in /etc/inittab:
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
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.
Agetty's auto-detection of parity problems
The 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 8-bit_data_bytes_(plus_parity). If you use stty to set parity,
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
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, agetty starts the login program
to finish logging you in. Unfortunately, the login program can't detect parity
so if the getty program failed to determine the parity then login will not be
able to determine it either. If the first login attempt fails, 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) 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 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.
8-bit data bytes (plus parity)
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.
getty (part of getty_ps)
The name has often been misspelled as ps_getty. (Most of this is from the old
Serial-HOWTO by Greg Hankins)
For this getty one needs to both put entries in a configuration file and add an
entry in /etc/inittab. Here are some example entries to use for your terminal
that you put into the configuration file /etc/gettydefs.
# 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
Note that the DT38400, DT19200, etc. are just labels and must be the same that
you use in /etc/inittab.
If you want, you can make 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:
@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 '@@'.
When you are done editing /etc/gettydefs, you can verify that the syntax is
correct by doing:
linux# getty -c /etc/gettydefs
Make sure there is no other getty or uugetty config file for the serial port
that your terminal is attached to such as (/etc/default/{uu}getty.ttySN or /
etc/conf.{uu}getty.ttySN), as this will probably interfere with running getty
on a terminal. Remove such conflicting files if they exits.
Edit your /etc/inittab file to run getty on the serial port (substituting in
the correct information for your environment - port, speed, and default
terminal type):
S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
Restart init:
linux# init q
At this point, you should see a login prompt on your terminal. You may have to
hit return to get the terminal's attention.
mgetty
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: mgetty.texi.
Look at the last lines of /etc/mgetty/mgetty.config 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 top or ps until this happens. The logs in /
var/log/mgetty/ 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 /etc/inittab:
s1:23:respawn:/sbin/mgetty -r ttyS1
15.2 Stty & Setserial
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 setserial but seldom supply one which runs stty since on seldom need
it.
15.3 Setserial
This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There are some
minor differences, depending on which HOWTO it appears in.
Setserial problems with linmodems, laptops
If you have a Laptop (PCMCIA) don't use setserial until you read Laptops:
PCMCIA.
Introduction
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.
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. 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
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 setserial to tell the driver how these jumpers were set.
Today, when plug-and-play methods detect how the jumperless serial port is set,
setserial is not really needed anymore unless you're having problems or using
old hardware. Furthermore, if the configuration file used by setserial is
wrong, then there's trouble. In this case, if you use setserial to try to find
out how the port is configured, it may just repeat the incorrect information in
the setserial configuration file.
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 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 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 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 setserial to run at boot-time, you
may have to take some action. setserialwill 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 setserial.
While 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 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 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 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 setserial, check out info in /usr/doc/setserial.../ or
/usr/share/doc/setserial. This should tell you how setserial is handled for
your distribution of Linux. While 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.
Serial module unload
If a serial module gets unloaded, the changes previously made by 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).
Giving the setserial command
Remember, that 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 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 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:
setserial -g /dev/ttyS*
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: "UART: unknown" 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 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 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.
Configuration file
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 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:
1. 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)
2. Save what 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
setserial command on the command line and then shuts down the system.
("autosave-once" option)
3. At every shutdown, save whatever setserial detects to the configuration
file. ("autosave" option)
4. Manually edit the configuration file to set the configuration. Don't ever
do any automatic saves to it. ("manual" option)
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 setserial. See Edit_a_script_(prior_to_version_2.15).
Probing
You probe for a port with setserial only when you suspect that it has been
enabled (by PnP methods, the BIOS, jumpers, etc.). Otherwise 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, 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 Probing
The purpose of such probing is to see if there is a uart there, and if so, what
its IRQ is. Use 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 pnpdump --dumpregs, or lspci -vv. But if you want to detect
hardware with setserial use for example :
setserial /dev/ttyS2 -v autoconfig
If the resulting message shows a uart type such as 16550A, then you're OK. If
instead it shows "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 "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 /etc/
serial.conf or /etc/sysconfig/serial or /var/lib/setserial/autoserial.conf 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 setserial to give the IRQ a
fictitious value.
Boot-time Configuration
While setserial may run via an initialization script, something akin to
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 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 setserial had been run.
To correct possible errors in IRQs (or for other reasons) there may be a script
file somewhere that runs 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" setserial
command by just typing it on the command line. In some cases the results of
this use of 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 Configuration_method_using_/etc/serial.conf,_etc..
Edit a script (required prior to version 2.15)
This is how it was done prior to 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 /etc/rc.d/rc.serial was commonly used in the past. The Debian
distribution used /etc/rc.boot/0setserial. Another file once used was /etc/
rc.d/rc.local 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 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 Configuration_method_using_/etc/serial.conf,_etc..
An example line in such a script was:
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
or, if you wanted setserial to automatically determine the uart and the IRQ for
ttyS3 you would have used something like this:
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
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.
Configuration method using /etc/serial.conf, etc.
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 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 /etc/
serial.conf (or /var/lib/setserial/autoserial.conf).
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 serial.conf. 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 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 /etc/init.d/{set}serial stop.
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".
IRQs
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.
Laptops: PCMCIA
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.
15.4 Stty
Introduction
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 "stty sane".
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.
stty is documented in the man pages with a more detailed account in the info
pages. Type "man stty" or "info stty".
Many of the stty options (or settings) start with an "o" (output) or an "i"
(input). For example: 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 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 stty man or info page for more details. Also see the man
page: 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 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.
Flow control options
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".
Using stty at a "foreign" terminal
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 stty -F /dev/ttyS2 ... (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 Two_interfaces_at_a_terminal to understand it.
Two interface modes at a terminal
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 <return> 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 <return>
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
<return> 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 <return> it's a different story. The <return> 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 <return>.
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.
Where to put the stty command ?
Should you need to have stty set up the serial interface each time the computer
starts up then you need to put the 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.
Obsolete redirection method
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 ... > /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 <return>). 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 ... < /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.
15.5 Terminfo & Termcap (brief)
See 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 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 Terminfo_Compiler_(tic) for
how to update.
15.6 Setting TERM and TERMINFO
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 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 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 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 Terminfo_&_Termcap_(brief).
What is the terminfo name of my terminal ?
You need the exact name in order to set the TERM environment variable or to
give to 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 Compiled_database_locations) or try
to find the terminfo source code file (see Source-code_database_locations.
15.7 Rarely Needed /etc/ttytype File
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
15.8 Login Restrictions
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.
15.9 Run Command Only If TERM=my_term_type
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.
Example for ls Function
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 ls command display colors if the terminal is "linux" but uses 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 ls command, although a color display may
look more impressive.
-------------------------------------------------------------------------------
if [ "$TERM" = linux ]; then
eval `dircolors`;
elif [ "$TERM" = vt220 ]; then
ls () { command ls -F $* ; }# to export the function ls():
declare -xf ls
else echo "From /etc/profile: Unknown terminal type $TERM"
fi
-------------------------------------------------------------------------------
15.10 Character Mapping: mapchan
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 ) download_mapchan
etc.
16. Terminfo and Termcap (detailed)
16.1 Intro to Terminfo
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.
16.2 Terminfo Database
Introduction
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 What_is_the_terminfo_name_of
my_terminal_?
Where is the database located ?
Compiled database locations
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.
Source-code database locations
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
"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 locate command to try to find
it. It is available on the web at http://catb.org/terminfo/.
Terminfo Compiler (tic)
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.
Look at Your Terminfo
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.
Deleting Data Not Needed
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.
16.3 Bugs in Existing Terminfo Files (and Hardware)
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.
16.4 Modifying Terminfo Files
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).
16.5 Init String
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).
16.6 TERM Variable
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 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.
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).
16.7 Terminfo/Termcap Documents
* manual pages for terminfo(5) (best) and/or termcap(5). 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: Termcap_Library
* 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 http://catb.org/terminfo/
* "Termcap and Terminfo" is a book published by O'Reilly in 1988.
17. Using the Terminal
17.1 Intro to Using the Terminal
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:
* clear (to clear the screen)
* reset (to reset the terminal
* setterm -reset (alternative for "reset" in case of bug)
17.2 Starting Up the Terminal
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
Trouble-Shooting.
17.3 Terminal (Serial) Device Driver
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. Stty may be used to configure how this terminal driver behaves,
including disabling some (or all) of its functionality.
17.4 Problems with Editors
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.
emacs
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.
vi and Cursor-Keys
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.
17.5 Problem with Slow Scrolling
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 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.
17.6 Bugs in Bash ?
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 /etc/inputrc. 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 /etc/inputrc like this:
# 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
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~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.
A fixed Bash bug
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.
17.7 Color ls Corruption
If ls is corrupting your terminal emulation with the color feature, turn it
off. ls --color, and ls --colour all use the color feature. Some installations
have ls set to use color by default. Check /etc/profile, etc. for ls aliases.
See Example_for_ls_Function for how to have ls do color for the console and do
monochrome for terminals.
17.8 Display Freezes (hung terminal)
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:
Sent_terminal_binary or Abnormally_exited_a_program
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.
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.
17.9 Corrupted Terminal Interface
This includes the case of a "frozen display" = "hung terminal" of the previous
section.
Symptoms and some fixes
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:
* A bug in the program you're using (including a program which erroneously
assumes that you are using a terminal of type "linux")
* A hardware failure (including an obscure hardware defect that you can
normally live with)
* Incorrect configuration (including an error in the terminfo or the terminal
type)
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:
* Sent_terminal_binary
* Abnormally_exited_a_program
* Typed_ctrl-S_by_mistake
Sent terminal binary characters
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 <return> 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.
Reset command was broken but now fixed
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 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.
Character corruption
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.
Abnormally exited a program
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.
17.10 Special (Control) Characters
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.
Command-Line Editing
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.
* Delete-key (shown by stty as ^?) erases the last character
* ^U kills (deletes) the line
* ^W deletes a word backwards
* ^R reprints the line. Useful mainly on hard copy terminals ??
Interrupting (& Quit, Suspend, EOF, Flush)
* ^C interrupts. Exits the program and returns you to the command-line prompt.
* ^\ quits. Same as interrupt. Also may dump a "core" file (which you likely
have no use for) into your working directory.
* ^Z suspends. Stops the program and puts it in the background. Type fg to
restart it.
* ^D end of file. If typed at the command-line prompt, exits the shell and goes
to where you were before the shell started.
* ^O flush (or discard). Not yet implemented in Linux (but proposed). Sends
output to /dev/null.
* ^T display driver status. Not yet implemented in Linux (but proposed).
Displays a status line for the interface (number of bytes sent, etc.).
Stop/Start Scrolling
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
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:
* ^S stops scrolling (Xoff)
* ^Q resume scrolling (Xon)
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.
Take next character literally
^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.
17.11 Viewing Latin1 Files on a non-Latin1 terminal
Some "text" files are 8-bit Latin1 (=ISO-8859-1). See 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 ??
17.12 Eliminating Overstriking in Files
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".
17.13 Inspecting the Interface
These utility programs will provide information about the terminal interface:
* gitkeys: shows what byte(s) each key sends to the host.
* tty: shows what tty port you are connected to.
* set: shows the value of TERM (the terminfo entry name)
* stty -a: shows all stty settings.
* setserial -g /dev/tty?? (you fill in ??) shows UART type, port address and
IRQ number.
* infocmp: shows the current terminfo entry (less comments)
17.14 Changing the Terminal Settings
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. 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:
1. setterm -reverse
2. tput -rev
3. echo ^[[7m
setterm
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.
tput
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.
echo
In the example "echo ^[[7m" to set reverse video, the ^[ is the escape
character. To type it type ^V^[ (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.
Saving changes
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.
17.15 Multiple Sessions
The "screen" package runs multiple sessions something like virtual terminals on
the console: See The_Console:_/dev/tty?. You can switch back and forth between
the sessions. The non-free Facet Term software also does this. See FacetTerm
17.16 Logging Out
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.
17.17 Chatting between Terminals, Spying
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 http://www.tridia.com.
17.18 Sharing the Serial Port
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:
* Just unplug the terminal cable and plug in the other device
* Use an AB switch to switch between the terminal and other device (uses 3
cables)
* Use the printer (or aux) port on the terminal for the other device
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 /etc/inittab and check and/or set the runlevels at which getty
runs. For example the line: "S1:23:respawn:/sbin/getty ..." 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 /usr/doc/
sysvinit, but also look in /usr/share/doc.
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.
17.19 Browsers for Text-Terminals
See 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
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.
18. Special Uses for a Terminal
18.1 Make a Serial Terminal the Console
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.
For Kernels 2.2 or higher
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
mknod -m 622 console c 5 1
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 /etc/lilo.conf file contents (for ttyS0):
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"
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).
Serial-Console For Kernels before 2.2
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:
#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
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=".
18.2 Run Linux without a Monitor
One way to do this is to just use a terminal (serial console) for the monitor
See 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 Use_a_Keyboardless_Terminal
as_the_Monitor
18.3 Use a Keyboardless Terminal as the Monitor
How it works
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 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).
Example configuration
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 /etc/inittab:
1:2345:respawn:/sbin/getty 38400 tty1 wyse60 -ln /usr/sbin/
ttysnoops
Note that ttysnoop/ttysnoops 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 /etc/snooptab:
# tty snoopdev type execpgm
tty1 /dev/ttyS3 init /usr/local/bin/sterm
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 /usr/local/bin/sterm:
#!/bin/sh
stty rows 24
/bin/login $@
19. Trouble-Shooting
If you suspect that the problem is a hardware problem, see the Repair_and
Diagnose section. If it's the keyboard see Keyboards. If it responds
incorrectly (if at all) to what you type. see Corrupted_Terminal_Interface. If
the problem involves the serial port itself see the Serial-HOWTO.
Here is a list of possible problems:
* Is_the_Terminal_OK_? Suspect the terminal is defective.
* Display_Freezes_(hung_terminal)
* Displays_Foreign/Weird_Characters/Symbols
* Displays_Escape_Sequences
* Missing_Text Either skips over some text or displays some text OK and hangs.
* All_Keys_Work_Erratically;_Must_Hit_a_Key_a_Few_Times
* If_getty_run_from_command_line:_Programs_get_stopped with message "Stopped"
* Getty_Respawning_Too_Rapidly (console error message)
* Fails_Just_After_Login
* Can't_Login but login prompt is OK.
* Garbled_Login_Prompt
* No_Login_Prompt
* Cursor_Jumps
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.
19.1 Terminal Was Working OK
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 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 Corrupted_Terminal_Interface.
19.2 Terminal Newly Installed
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 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 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.
19.3 Is the Terminal OK ?
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 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 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.
19.4 Missing Text
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 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.
19.5 All Keys Work Erratically; Must Hit a Key a Few Times
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.
19.6 ... respawning too fast: disabled for 5 minutes
What's happening
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.
Getty line in /etc/inittab file incorrect
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.
No modem control signal
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.
No such serial device
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".
No serial support
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.)
Key shorted
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).
19.7 Fails Just After Login
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 ~/.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.
19.8 Can't Login
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 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 Login_Restrictions
19.9 Garbled Login Prompt
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.
19.10 No Login Prompt
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:
* If getty_ps (Redhat, etc.) two CLOCAL flags in /etc/gettydefs (See getty_
(part_of_getty_ps)).
* If agetty (Debian, etc.) a -L flag in /etc/inittab (See agetty).
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.
Terminal was working OK
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.
More diagnose
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).
* Diagnose_problem_from_the_console
* Measure_voltages
Diagnose problem from the console
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.
Measure voltages
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 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.
19.11 Displays Foreign/Weird Characters/Symbols
Don't confuse this with 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.
19.12 Displays Escape Sequences
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).
Telnet
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).
Terminal set to display escape sequences
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 Control_Codes.
19.13 Slow: pauses of several seconds between bursts of characters
You likely have mis-set interrupts> See the Serial-HOWTO section starting with
"Slow:"
19.14 Cursor Jumps
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.
19.15 Terminal doesn't scroll
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.
19.16 Serial Monitoring/Diagnostics
A few Linux programs will monitor the modem control lines and indicate if they
are positive (1) or negative (0).
* statserial (in Debian distribution)
* The "file": /proc/tty/driver/serial. Use "watch head ..." to monitor it. Has
info on errors and byte flow.
* modemstat (only works on Linux PC consoles. Will coexist with the command
line)
You may already have the above programs. If not, go to 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.
19.17 Local Mode
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 Getting_Into_Set-Up_
(Configuration)_Mode.
19.18 Serial Electrical Test Equipment
Breakout Gadgets, etc.
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.
Measuring voltages
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.
Taste voltage
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.
20. Repair & Diagnose
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.
20.1 Repair Books & Websites
Books
Bigelow, Stephen J.: Troubleshooting & Repairing Computer Monitors, 2nd
edition, McGraw-Hill, 1997. Doesn't cover the character generation electronics
nor the keyboard.
Websites
The FAQ 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).
20.2 Safety
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.
20.3 Appearance of Display
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:
* V-Size adjusts the Vertical height (Size)
* H-Size adjusts the Horizontal width (Size). It may be an inductor.
* V-Pos adjusts the Vertical Position
* H-Pos adjusts the Horizontal Position
* V-Lin adjusts Vertical Linearity (Use if width of scan lines differs at the
top and bottom of the screen)
* V-Hold adjusts Vertical Hold (Use if screen is uncontrollable scrolling)
* Bright adjusts brightness (an external knob may also exist)
* Sub-Bright adjusts brightness of subdued intensity mode (often the normal
mode: dimmer than bold or bright mode).
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).
20.4 Diagnose
Terminal Made a Noise or Smoked
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.
Terminal Made No Noise
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
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.
20.5 Detective work
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.
20.6 Error Messages on the Screen
You are in luck if you see an error message on the screen. This usually happens
when you first turn the terminal on.
Keyboard Error
This usually means that the keyboard is not plugged in, or that the connection
is loose. For more serious problems see Keyboards
Checksum Error in NVR
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.
20.7 Capacitors
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.
20.8 Keyboards
Interchangeability
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.
How They Work
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".
Modern vs Old Keyboards
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.
One Press Types 2 Different Characters
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.
Keyboard doesn't work at all
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.
Typing b displays bb, etc. (doubled)
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 One_Press_Types_2_Different_Characters
Row upon row of the same character appears
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.
Key sticks in down position (individual switches)
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 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.
Key electrically shorted
If you suspect that a key is shorted out, fix it by cleaning the contacts per
Cleaning_Keyboard_Contacts. If this problem happens at the login prompt see Key
shorted.
Liquid spilled on the keyboard
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.
Cleaning keyboard contacts
Keyboards with membranes
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.
Keyboards with individual switches
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.
21. Appendix A: General
21.1 List of Linux Terminal Commands
Sending a command to the terminal
* setterm: long options
* tput: terse options
* reset: initializes only
* tset: same as reset
* clear: clears screen
* setterm -reset: sends reset string
Configuring the terminal device driver
* Setserial:
* Stty
Terminfo
* Terminfo_Compiler_(tic) terminfo compiler & translator
* toe: shows list of terminals for which you have terminfo files
* infocmp compares or displays terminfo entries
Other
* gitkeys: shows what bytes each key sends to the host.
* tty: shows what tty port you are connected to.
* reset -q: shows the value of TERM, the terminfo entry name
* reset: sets TERM interactively and initializes
21.2 The Internet and Books
Terminal Info on the Internet
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.
* vt100_section_of_Shuford's_Website
* Text-terminal_-_Wikipedia
* Terminal_Interface_per_Wikipedia
* 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.
* 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.
* 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 www.wyse.com.
* ncurses_FAQ
* comp.terminals is the newsgroup for terminals
Books related to terminals
* EIA-232 serial port see EIA-232_(RS-232)_Books.
* Repair see Repair_Books_&_Websites.
* Terminfo database see Termcap_Documents
Entire books on terminals
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:
* Handbook of Interactive Computer Terminals by Duane E. Sharp; Reston
Publishing Co. 1977. (mostly obsolete)
* Communicating with Display Terminals by Roger K. deBry; McGraw-Hill 1985.
(mostly on IBM synchronous terminals)
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.
Books with chapters on terminals
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.
* 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
* Advanced Programming in the Unix Environment by W. Richard Stevens Addison-
Wesley, 1993. Ch. 11: Terminal I/O, Ch. 19: Pseudo Terminals
* Essential System Administration by Aleen Frisch, 2nd ed. O'Reilly, 1998. Ch.
11: Terminals and Modems.
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.
21.3 Non-Linux OSs
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.
* Adding_Serial_Terminals in SCO OpenServer Handbook.
* Hewlett-Packard's HP-UX Configuring_Terminals_and_Modems
22. Appendix B: Escape Sequence Commands Terminology
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
Set-Up_Options, such escape sequences options will not be repeated here.
22.1 Esc Sequence Lists
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 VT
Manuals. Other lists have disappeared from the internet.
22.2 8-bit Control Codes
Table of 8-bit DEC control codes (in hexadecimal). Work on VT2xx or later. CSI
is the most common.
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 \
22.3 Printer Esc
* 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).
* Print Controller on/off: When on, data from the host is sent only to the
printer (nothing shows on the terminal screen).
22.4 Reports
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.
* Request for Status (Report Operating Status): Meaning of replies for VT100 is
either "I'm OK" or "I'm not OK"
* Request for Device Attributes: The "device" is usually the printer. Is there
a printer? Is it ready?
* 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.
* 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.
22.5 Cursor Movements
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.
22.6 Pages (definition)
See 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).
23. Appendix C: Serial Communications on EIA-232 (RS-232)
23.1 Intro to Serial Communication
(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.
23.2 Voltages
Voltage for a bit
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.
Voltage sequence for a byte
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).
23.3 Parity Explained
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.
23.4 Forming a Byte (Framing)
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).
23.5 Limitations of EIA-232
Low Speed & Short Distance
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 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.
Successors to EIA-232
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.
Line Drivers
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.
23.6 Synchronization & Synchronous
How "Asynchronous" is Synchronized
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.
Defining Asynchronous vs Synchronous
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.
Synchronous Communication
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.
23.7 Block Mode
Introduction to Block Mode
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 IBM_Terminals so many IBM
terminals are block-mode only and also synchronous (see Section Synchronization
&_Synchronous).
Types of Block Modes, Forms
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.
Efficiency
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.
Problems with block mode
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.
23.8 EIA-232 (RS-232) Books
(Note: The first book covers much more than just EIA-232.)
* Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE Computer
Society Press, Los Alamitos, CA, 1996.
* Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
* Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
* Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall, 1991.
23.9 Serial Software
See Serial_Software for Linux software for the serial ports including getty and
port monitors.
24. Appendix D: Notes by Brand/Model
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 VT_(DEC). Wyse put the information from its manuals on
the Internet but it can't be readily found now (2013).
24.1 Adds
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.
24.2 CIT
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.
24.3 IBM Terminals
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
Block_Mode.
IBM 3153
It's claimed that the Aux port is DCE and uses a straight-thru cable.
24.4 Teletypes
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").
24.5 VT (originally DEC, now Boundless)
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 Boundless name and url have been retained.
Detailed VT terminal information, some manuals, and history is at 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.
24.6 Links
The terminal maker Links was taken over by Wyse.
24.7 Qume
Qume was taken over by Wyse in the early 1990s.
24.8 Wyse Terminals
detailed manual-like information on old terminals see 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 en.wikipedia.org/wiki/Dell_Wyse for a history of Wyse.
Wyse 50
Reported not to last very long.
Wyse 60
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 ~ 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 Bugs_in_Bash
Wyse 85
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).
Wyse 99-GT
Here is the setup Menus of the Wyse99GT (late 1980's). Note that TERM means
"termination" (character) and not "terminal".
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.
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.
Wyse 150
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).
Wyse 185
Has 10x20 character cells. Can emulate DEC VT320. Uses 45 watts power. Later
models were 185e.
Low Emissions: -ES
ES after the model number means low emissions: low magnetic field, etc.
END OF Text-Terminal-HOWTO