LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2013-03-10 22:21:24 +00:00
parent 90fd17aa3c
commit f5bd3f781a
3 changed files with 279 additions and 222 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml
View File

@ -4460,7 +4460,7 @@ implementation, plus auxiliary packages like Ghostscript. </Para>
Text-Terminal-HOWTO</ULink>,
<CiteTitle>Text-Terminal HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Jan 2010</CiteTitle>.
<CiteTitle>Updated: Mar 2013</CiteTitle>.
Explains what text terminals are, how they work, how to install and
configure them, and provides some info on how to repair them. </Para>
</ListItem>

2
LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml
View File

@ -276,7 +276,7 @@ a Psion palmtop. </Para>
Text-Terminal-HOWTO</ULink>,
<CiteTitle>Text-Terminal HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Jan 2010</CiteTitle>.
<CiteTitle>Updated: Mar 2013</CiteTitle>.
Explains what text terminals are, how they work, how to install and
configure them, and provides some info on how to repair them. </Para>
</ListItem>

497
LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml
View File

@ -2,10 +2,13 @@
<article>
<title> Text-Terminal-HOWTO
<author> David S. Lawyer <url url="mailto:dave@lafn.org">
<date> v1.42 January 2010
<date> v1.43 March 2013
<!--
Change log
v1.43 Mar. 2013 Putty's pterm emulation. Cleanup. Shuford's website
now defunct. Looking for a new maintainer. Wyse data missing from
Internet. Rewrote abstract. Clarity in stty raw problem. Links to Wikipedia
v1.42 Jan. 2010 PuTTY serial terminal emulator, cutecom (dumb
emulator), colors, links to wikipedia, Boundless still selling
terminals, small footprint terminals, link to art. on text browsers.
@ -124,27 +127,37 @@ v0.00 April 1998: After reading it over on hikes in Griffith Park and
-->
<abstract>
This document was originally written for real text terminals which are
seldom used anymore. It explains how they work, how to install and
configure them, and provides some info on how to repair them. Most of
this information is mainly of historical interest. But much in this
HOWTO applies to the emulation of text terminals by PC's which is used more
often than real terminals. Except that the standard text modes of
Linux are still used a lot: either the direct text mode (virtual
console) or using text windows in the X-window interface (such as
rterm). But while these standard interfaces (with no serial cables to
connect) are still emulations of a text terminal the details of these
standard emulations is not well covered in this HOWTO since it was
well covered by Keyboard-and-Console-HOWTO which was written for Linux
2.0 and likely needs updating.
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".
This HOWTO also provides an brief overview of modern GUI terminals.
But unfortunately, the main emphasis in this howto is real text
terminals and the coverage of emulation is inadequate for the first 3
methods of emulation mentioned above. The Keyboard-and-Console-HOWTO
filled much this gap but it was written for Linux 2.0 and now needs
rewriting (or merging into this Text-Terminal howto). A new author is
needed that has time to do all this.
For the seldom used real text-terminals, it explains how they work, explains how
to install and configure them, and provides some info on how to repair
them. This HOWTO also provides a brief overview of modern GUI
terminals.
</abstract>
<toc>
<sect> Introduction <label id="intro">
<p> For a quick attempt to install a terminal see <ref id="quick_install"
<p> For a quick attempt to install a text-terminal see <ref id="quick_install"
name="Quick Install">.
<sect1> Copyright, Trademarks, Disclaimer, & Credits
@ -196,13 +209,15 @@ as a console for a monitorless PC (using ttysnoop). Numerous other
people have made a suggestion or two or found a few typos. Thanks.
<sect1> Future Plans: You Can Help
<p>Real text terminals are pretty
much obsolete except for legacy applications, but GUI terminals
(variously known as thin clients, ultra-thin clients, and
zero-clients) are claimed to be the wave of the future. What is
needed today is for someone to start with the brief overview of GUI
terminals in this HOWTO and create a new and up-to-date HOWTO on thin
clients.
<p>The author is looking for someone to take over maintaining this
howto. Since real text terminals are pretty much obsolete, there is not
a lot of work to do except that links sometimes disappear and
automatically finding devices such a dumb terminals on a serial port may
not work right. One project is to rewrite this howto oriented towards
text-terminal emulation with the command line interface. Another
project would be to start with the brief overview of GUI terminals in
this HOWTO and create a new and up-to-date HOWTO on thin clients or the
like.
Please let me know of any errors in facts, opinions, logic,
spelling, grammar, clarity, links, etc. But first, if the date is
@ -212,8 +227,10 @@ 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 put
their manuals on the Internet but they never did.
way to have solved this problem would be for terminal manufacturers to
put their manuals on the Internet but they never did. Except that Wyse
made available some of their user manuals and someone scanned old VT-100
manuals.
<sect1> New Versions of this HOWTO
<p> New versions of the Text-Terminal-HOWTO should be released every
@ -222,38 +239,27 @@ couple of years. To get the latest version go to an LDP mirror sites (see:
of the latest version look at <url
url="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Text-Terminal-HOWTO.html"
name="Text-Terminal-HOWTO.html">. The version your are currently
reading is: v1.42 January 2010 .
reading is: v1.43 March 2013 .
For a full revision history going back to the first version in
1998 see the source file (in linuxdoc format):<url
url="http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml?view=markup" name="(cvs) Text-Terminal-HOWTO.sgml">
<itemize>
<item> v1.43 Mar. 2013 Putty's pterm emulation. Cleanup. Shuford's website
now defunct. Looking for a new maintainer. Wyse data missing from
Internet. Rewrote abstract. Clarity in stty raw problem. Links to Wikipedia.
<item>v1.42 Jan. 2010 PuTTY serial terminal emulator, cutecom (dumb
emulator), colors, links to wikipedia, Boundless still selling
terminals, small footprint terminals, link to art. on text browsers.
<item>v1.41 Feb. 2008" Better clarity re emulation. Illusion when
revere-video is reversed. Problem with slow scrolling. Wyse text
terminals discontinued and Boundless was bankrupt. Update on text web
browsers. gtkterm, X Window now has many terminal emulators.
Symantec no longer selling Procomm.
<item>v1.40 Dec. 2006 Picocom is like minicom. Devfs obsolete so removed
tts/1, etc. Updated pseudo terminals. More about telnet, ssh, and
non-serial port interfaces. IBM terminal emulation over telnet.
Kermit for MS does terminal emulation. Ports of minicom to Mac.
Fixed/removed broken links. "reset" is an alias for "tset"
</itemize>
<sect1> Related HOWTOs, etc. <label id="related_howtos">
<sect1> Related HOWTOs <label id="related_howtos">
<p> Go to the nearest mirror site (per above) to get HOWTOs.
<itemize>
<item> Serial-HOWTO has info on Multiport Serial Cards used for both
terminals and banks of modems. It has general technical info on the
serial port including troubleshooting it.
<item> <url url="www.gnu.org/manual/glibc/html_chapter/libc_12.html"
name="Low-Level Terminal Interface"> part of "GNU C Library Reference
Manual" (in libc (or glibc) docs package). It covers the detailed
meaning of "stty" commands, etc.
<item> NCURSES-Programming-HOWTO
<item> MacTerminal mini-HOWTO
<item> Modem-HOWTO
@ -333,7 +339,7 @@ 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 the terminal and is part
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
@ -1667,11 +1673,12 @@ may be programmed to send out a sequence of bytes (characters). See
<sect1> Mouse
<p> A few text-terminals support a mouse. When the mouse is clicked,
an escape sequence is sent to the host to tell it where the mouse is.
For a mouse on VT terminals see <url
url="http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html"> These
escape codes for mice are called "DEC Locator sequences". The FALCO
Infinity Series of terminals, model ANSI-G supports it. Do any linux
applications support this ??
An article for a mouse on VT terminals was once at
http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html but it's now a
dead link (2013). Try the "Wayback" machine." These escape codes for
mice are called "DEC Locator sequences". The FALCO Infinity Series of
terminals, model ANSI-G supports it. Did any linux applications support
this ??
<sect> Terminal Emulation (including the Console) <label id="term_emulation">
@ -1716,13 +1723,13 @@ 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, 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.
VT100/ANSI, xterm, pterm, or Wyse60 (but not fully). Since most PC's
have color monitors while VT100 and VT102 were designed for a
monochrome monitor, the emulation usually adds color capabilities
(including a choice of colors). Sometimes the emulation is not 100%
perfect but this usually causes few problems. None of them provide
programmable function keys. The non-free emulation software running
under MS Windows can emulate many more terminals than free Linux can.
<sect1> Don't Try to Use TERM Variable for Emulation
<label id="term_not_for_emulation">
@ -1731,40 +1738,43 @@ 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. 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". This should happen without you needing to
do anything.
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
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 make a mistake.
OK most of the time but once in a while will give errors.
<sect1> Serial Communication programs (mostly dialing) <p>while the
newer free PuTTY program can connect directly to a serial line but
can't dial, most of 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 one could use dialing programs to dial up some public libraries
to use their catalogs and indexes, or even read magazine articles on
line before the Internet was widely available. But today such
activity is almost always done using the Internet.
<sect1> Serial Communication programs
<p>while the newer free PuTTY and Terra-Term programs can connect
directly to a serial line but can't dial out, most of 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
@ -1798,11 +1808,13 @@ name="Ubuntu -- x-terminal-emulator"> for a brief list of such
emulators. Some are multilingual. Your Linux distribution has likely
installed one for you.
<sect2> Real terminals may be better
<p> Unless you are using X Window with a large display, a real
<sect2> Real terminals once were better
<p> Unless one was using X Window with a large display, a real
terminal was often nicer to use than emulating one. It often had
better resolution for text (since it's monochrome), and had no disk
drives to make annoying noises.
drives to make annoying noises. Today, the resolution of modern color
displays is better than that of the old text-terminals and disk drives
are quieter.
<sect1> Testing Terminal Emulation
<p> For the VT series terminals there is a test program: <tt/vttest/
@ -1870,19 +1882,24 @@ if you need to purchase software you should try to throughly check out
what other customers have to say about it.
<sect2> Make a Linux PC a serial port terminal <label
id="pc_as_terminal">
<p> Unless you want to emulate the standard vt100 (or close to it),
xterm, or a Wyse 60, there doesn't seem to be much free terminal
emulation software available for Linux. The free programs are minicom,
picocom, and for GUI: seyon and PuTTY. Both seyon and PuTTY can
emulate either xterm or vt100 (or close to it). PuTTY is much newer
but its main use is an SSH client. Seyon is much older but with more
features (some of which are seldom needed). There are also more
recent (but weaker) "emulators" for a GUI interface: gtkterm and
cutecom, neither of which can emulate any terminal except of type
"dumb" ??). Seyon can also emulate a Tektronix 4014 terminal. For
Wyse see <url url="http://gutschke.com/wy60/" name="Wyse 60
emulator">.
id="pc_as_terminal">
<p> Unless you want to emulate the standard vt100
(or close to it), xterm, or a Wyse 60, there doesn't seem to be much
free terminal emulation software available for Linux. The free
programs are minicom, picocom, and for GUI: seyon and PuTTY. Seyon
can emulate either xterm or vt100 while PuTTy uses its own termcap
(terminfo) named "putty" (put the terminal type "putty" in
/etc/inittab). Putty's "pterm" can be used as a replacement for
xterm.
PuTTY is much newer than most other emulations and a major use of it
is as an SSH client but you can set its configuration for a serial
port connection. Seyon is much older but with more features (some of
which are seldom needed). There are also more recent (but weaker)
"emulators" for a GUI interface: gtkterm and cutecom, neither of which
can emulate any terminal except of type "dumb" ??). Seyon can also
emulate a Tektronix 4014 terminal. For Wyse see <url
url="http://gutschke.com/wy60/" name="Wyse 60 emulator">.
Both gtkterm (and likely cutecom) don't use escape sequences, and
might be said to emulate a terminal of type "dumb" so they would be
@ -1917,13 +1934,12 @@ which may be found using their search engine at <url
url="http://www.symantec.com/">. And if you check the Internet (in
2008), it's still being sold here and there.
There's a specialized Linux distribution: Serial Terminal Linux. It
will 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). See <url
url="http://www.eskimo.com/~johnnyb/computers/stl/">. It will let you
have more than one session running (similar to virtual terminals), one
for each serial port you have.
There was a specialized Linux distribution: Serial Terminal Linux. It
would turn a PC to into a minicom-like terminal. It's small (fits on a
floppy) and will not let you use the PC for any other purpose (when it's
running). The link to it is broken, but one similar to it (in 2013),
but on CD, is <url url="http://www.asashi.net/pages/pitux.html"
name="ASASHI DOT NET: PITUX, micro SERIAL TERMINAL LINUX">
TERM (non-free commercial software from Century Software) <url
url="http://www.centurysoftware.com/terminal_emulator/advanced_terminal_emulator.php"
@ -1955,9 +1971,9 @@ 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 <url
url="http://www.byte.com/art/9402/sec8/art1.htm" name="DOS Serial
Communications (1994)">.
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
@ -1986,11 +2002,6 @@ 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.
One place to check terminal emulation products is Shuford's site, but
it seems to lists old products (which may still work OK). The fact
that most only run under DOS (and not Windows) indicates that this
info is dated. See <url
url="http://www.cs.utk.edu/~shuford/terminal/term_emulator_products.txt">.
<sect1>Colors on Emulated Terminals <label id="colors">
<p>Since displays used for text terminal emulation are almost always
@ -4165,13 +4176,21 @@ 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 old ISA serial port set by jumpers on the
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.
both detect and set your add-on PCI serial ports. In some cases the
setserial program may have been previously used and the wrong serial
port data has been manually given by the some past user (perhaps by
you). If setserial hasn't been configured to accept what the kernel
says, it will override the (likely correct) kernel data with what
someone previously set.
<tt/setserial/ allows you (or a shell script) to talk to the serial
software. But there's also another program, tt/stty/, that also deals
with the serial port and is used for setting the port speed, etc.
<tt/setserial/ is really a misnomer, it doesn't set any information on
the serial card. Example: it can't change the irq set on the card.
More details on this later
<tt/setserial/ deals with the lower-level configuring of the serial
port, such as dealing with IRQs (such as 5), port addresses (such as
@ -4193,7 +4212,7 @@ anymore unless you're having problems or using old hardware.
Furthermore, if the configuration file used by <tt/setserial/ is
wrong, then there's trouble. In this case, if you use <tt/setserial/
to try to find out how the port is configured, it may just repeat the
incorrect information in the configuration file.
incorrect information in the setserial configuration file.
<tt/setserial/ can sometimes be of help to find a serial port. But
it's only of use if you know the port address and use the right
@ -4205,7 +4224,7 @@ doesn't set the I/O address nor IRQ in the hardware, it just "sets"
them in the driver software. And the driver naively believes that
what <tt/setserial/ tells it, even if it conflicts with what the driver
has found by using plug-and-play methods. Too bad that it fails to
at least issue a warning message for such a conflict. Since the
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".
@ -4233,10 +4252,11 @@ driver thinks, it might be correct. Or it could be telling you what
driver. There's no way to know for sure without doing some other
checks.
The serial driver (for Linux Kernel 2.4+) looks for a few "standard"
legacy serial ports, for PnP ports on the ISA bus, and for all
supported port hardware on the PCI bus. If it finds your ports
correctly, then there's no need to use <tt/setserial/. The driver
The serial driver (for Linux Kernels 2.4 and 2.6) looks for a few
"standard" legacy serial ports, for PnP ports on the ISA bus, and for
all supported port hardware on the PCI bus. If it finds your ports
correctly, then there's no need to use <tt/setserial/ unless they have
been "set" incorrectly in the setserial configuration file. The driver
doesn't probe for the IRQs of old ISA serial ports set with jumpers on
the card and may get these wrong.
@ -4254,6 +4274,9 @@ HOWTOs such as Plug-and-Play or Serial.
<tt/setserial/ will be forgotten by the driver. But while the driver
forgets it, a script provided by the distribution may save it in a
file somewhere so that it can the restored if the module is reloaded.
Also changes made by setserial may be stored in setserial's
configuration file (see the documentation for your distribution, this
info is not in the man page).
@ -4596,22 +4619,40 @@ Feb. 2005: Put redirection info into Obsolete section
<p> <tt/stty/ does much of the configuration of the serial port but
since application programs (and the getty program) often handle this,
you may not need to use it much. It's handy if you're having problems
or want to see how the port is set up. 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. Don't try to learn all the setting 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.
or want to see how the port is set up. It also configures the terminal
interface which is not only used by the serial port but is also used
anytime you use a command-line interface in Linux. Try typing ``stty
-a'' at your terminal/console to see how it's now set. Also try typing
it without the -a (all) for a short listing which shows how it's set
different than "normal" which is how it's set using the command
<tt>"stty sane"</tt>. Don't try to learn all the settings unless you
want to become a serial historian since many of the settings are only
for slow antique dumb terminals of the 1970's. Most of the defaults
should work OK.
<tt/stty/ is documented in the man pages with a more detailed account
in the info pages. Type <tt>"man stty"</tt> or <tt>"info stty"</tt>.
Whereas <tt/setserial/ only deals with actual serial ports, stty is
used both for serial ports and for virtual terminals such as the standard
Linux text interface at a PC monitor. For the PC monitor, many of the
stty settings are meaningless. Changing the baud rate, etc. doesn't
appear to actually do anything.
Many of the stty options (or settings) start with an "o" (output) or an
"i" (input). For example: <tt/onlcr/. Output is the flow of bytes out
of the computer while input is the flow of bytes into the computer. The
"point of view" is the computer, not the serial port or the device
connected to the serial port. For example, received input data comes in
on a cable and goes to the serial port chip. This chip, after
converting the bits from the serial to parallel representation, then
sends it (via a program read) to the large serial port buffer in main
computer memory. Thus the chip has both input and output but since it's
input data to the computer, its output is considered to be input. The
situation is similar for output flowing thru this chip. The "input" and
"output" refer to the direction of flow with respect to the computer and
not the serial port hardware (the chip).
Whereas <tt/setserial/ only deals with actual serial ports, stty is used
for terminals regardless of whether they are accesses via a serial port,
network, or by a virtual terminal on Linux PC monitor, or a GUI
terminal window such as xterm. For the PC monitor, xterm, or a network
many of the stty settings are meaningless. Changing the baud rate, etc.
doesn't appear to actually do anything.
Here are some of the items stty configures: speed (bits/sec), parity,
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
@ -4679,19 +4720,23 @@ also such as dealing with tty3 from tty1, etc. See <ref
id="two_term_interfaces" name="Two interfaces at a terminal"> to
understand it.
<sect2> Two interfaces at a terminal <label id="two_term_interfaces">
<sect2> Two interface modes at a terminal <label id="two_term_interfaces">
<p> When using a shell (such as bash) with command-line-editing
enabled there are two different terminal interfaces (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 command-line-editor as you type it. Once you
hit the &lt;return&gt; key, the command-line-editor is exited and the
terminal interface is changed to the nominal "cooked" interface
(cooked mode) for the terminal. This cooked mode lasts until the next
prompt is sent to the terminal (which is only a small fraction of a
second). Note that one never gets to type any command in this cooked
mode but what was typed in raw mode on the command line gets read by
the shell while in cooked mode.
enabled there are two different terminal interfaces (or line
disciplines: what you see when you type stty -a). When you type in
modern shells at the command line you have a temporary "raw" interface
(or raw mode) where each character is read by the shell's
command-line-editor as you type it. Once you hit the &lt;return&gt;
key, the command-line-editor is exited and the terminal interface is
changed from raw to the nominal "cooked" interface (cooked mode) for the
terminal using the stty configuration that was used for the last cooked
mode (the shell has saved it and it gets restored). This cooked mode
lasts until the next prompt is sent to the terminal (which is only a
small fraction of a second) but it exists during the execution of the
command (or at least during the first stage of the command execution).
Note that one never gets to type any command into this cooked mode but
what was typed in raw mode on the command line starts execution by the
shell while in cooked mode.
When a prompt is sent to the terminal, the terminal goes from "cooked"
to "raw" mode (just like it does when you start an editor such as vim.
@ -4699,32 +4744,36 @@ 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. Thus if one uses
stty to change settings for the raw mode, such settings will be
permanently lost as soon as one hits the &lt;return&gt; key at the
terminal that has supposedly been "set".
on the settings used in the previous "raw" mode (as contrasted to
"cooked" mode which gets restored by the shell to its previous
settings). Thus if one uses stty to change settings for the raw mode,
such settings will be permanently lost as soon as one hits the
&lt;return&gt; key at the terminal.
Now when one types stty to look at the terminal interface, one may
either get a view of the cooked mode or the raw mode. You need to
figure out which one you're looking at. It you use stty from a
foreign terminal (other than the terminal you are currently typing
at) then you will see the raw mode settings. Any changes made will
only be made to the raw mode and will be lost when someone presses
&lt;return&gt; at the foreign terminal you tried to "set". But if you
type a stty command to view/change the configuration of the terminal
you are using, and then hit &lt;return&gt; it's a different story.
The &lt;return&gt; puts the terminal in cooked mode. Your changes are
saved and will still be there when the terminal goes back into raw
mode (unless of course it's a setting not allowed in raw mode).
foreign terminal (other than the terminal you are currently typing at)
then you will likely see the raw mode settings since the terminal is in raw
mode almost all the time. Any changes made will only be made to the raw
mode and will be lost when someone presses &lt;return&gt; at the foreign
terminal you tried to "set". But if you type a stty command to
view/change the configuration of the terminal you are using, and then
hit &lt;return&gt; it's a different story. The &lt;return&gt; puts the
terminal in cooked mode and your changes are saved by the shell before it
returns to raw mode. Since going into raw mode doesn't change all stty
settings, some of the changes you made via stty may still be present in
raw mode and will not get destroyed by &lt;return&gt;.
This situation can create problems. For example, suppose you corrupt
your terminal interface. To restore it you go to another terminal and
"stty -F dev/ttyS1 sane" (or the like). It will not work! 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.
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)
@ -4941,8 +4990,8 @@ are sent to the screen (output). This is nice for remapping the
keyboard for foreign language alphabets. Most distributions don't
seem to supply it (let me know if any do). Source code by Yura
Kalinichenko (Ukraine, partly in Russian ) <url
url="http://www.iceb.vc.ukrtel.net/download.html" name="download
mapchan etc.">
url="http://sourceforge.net/projects/mapchan/" name="download mapchan
etc.">
<sect>Terminfo and Termcap (detailed) <label id="termcap2">
@ -5314,14 +5363,17 @@ screen for cases where it slows down the "progress". If it just
updates progress numbers a few times per second or less, it shouldn't
be a problem.
<sect1> Bugs in Bash <label id="bash_bug">
<p> One problem still outstanding is that if certain terminal
keys send bytes with the high order bit set to 1, then Bash seems to
ignore the meaning for them as defined in a terminfo entry. I've
reported this as a bug in Bash. Other programs such as the vim editor
and the lynx browser work OK with such keys.
<sect1> Bugs in Bash ? <label id="bash_bug">
<p> One problem still outstanding is that if certain terminal keys
send bytes with the high order bit set to 1, then Bash seems to ignore
the meaning for them as defined in a terminfo entry. This may be
because, unless one is using 7-bit ASCII, bytes with the high order
bit set to 1, may represent a non-English letter. I reported this as
a bug in Bash (but years later realized that it may not have been a
bug). Other programs such as the vim editor and the lynx browser work
OK with such keys (when they are set to use 7-bit ASCII).
To work around this problem one may define what these keys should do
To work around this problem, one may define what these keys should do
in Bash by putting such definitions into <tt>/etc/inputrc.</tt> For
example, A Wyse 60 will send D0-D3 when the arrow-keys are hit
provided the terminal is in "application key mode". After modifying
@ -5330,7 +5382,7 @@ line in the Bash shell. So I explicitly defined the arrow-keys in
<tt>/etc/inputrc</tt> like this:
<tscreen><verb>
# Arrow keys in 8 bit keypad mode: Sends d0-d4. -ap means application.
# 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
@ -5343,8 +5395,8 @@ $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&tilde;3
and makes the arrow keys send D1-D3). Many other application send
this without needing to be told to do so.
and makes the arrow keys send D0-D3). Many other applications (other
than Bash) send this without needing to be told to do so.
<sect2>A fixed Bash bug
<p>There have been problems with the readline interface to the Bash
@ -6264,15 +6316,15 @@ 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 (at the console) try "stty &lt /dev/ttyS1" (if you use
ttyS1) 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.
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
@ -6352,16 +6404,17 @@ section.
<sect2> Measure voltages <label id="measure_volts">
<p> If you have a voltmeter handy check for a negative voltage (-4v to
-15v) at pin 3 (receive data) at the terminal side of the
-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 (the metal connectors on the ends of cables
are often not grounded). If there is no such negative voltage then
connected to a good ground (a metal connector on the end of the cable
may not be grounded). If there is no such negative voltage then
check for it at the transmit pin (TxD) on the computer (see <ref
id="DB_pin-out" name="DB9-DB25"> for the pin-out). If it's present
there but not at the receive pin (RxD) at the terminal, then the cable
is bad (loose connection, broken wire, or not a file-transfer aka
null-modem). If voltage is absent at the computer, then its serial
port is dead. Test it with a software diagnostic test or replace it.
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
@ -6609,10 +6662,6 @@ 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).
<url
url="http://www.cs.utk.edu/~shuford/terminal/repair_hints_news.txt"
name="Shuford's repair archive"> of newsgroup postings on terminal
repair is another source of info.
<sect1> Safety
<p> CRT's use high voltage of up to 30,000 volts for color (less for
@ -7084,24 +7133,37 @@ entries
<sect1> The Internet and Books
<sect2> Terminal Info on the Internet <label id="internet_">
<p> <itemize>
<item> <url url="http://www.cs.utk.edu/~shuford/terminal_index.html"
name= "Shuford's Website"> at the University of Tennessee has a great
deal of useful information about text terminals.
<item> <url url="http://en.wikipedia.org/wiki/Computer_terminal"
name="Computer terminal - Wikipedia">2009: Serious errors re history
<item> VT terminal information and history <url url="http://www.vt100.net/">
<p> In the first decade of the 20th century,
http://www.cs.utk.edu/~shuford/terminal_index.html was Shuford's Website
at the University of Tennessee. It was the major sit for information
about text terminals but is now (2013) defunct. Perhaps one can find it
archived on the "Wayback" machine.
http://www.cs.utk.edu/~shuford/terminal/repair_hints_news.txt was
Shuford's repair archive of newsgroup postings on terminal repair. See
below for the vt100 part of this website which is still on the internet.
<itemize>
<item> <url url="http://www.vt100.net" name= "vt100 section of Shuford's Website">
<item> <url url="http://en.wikipedia.org/wiki/Text_terminal"
name="Text-terminal - Wikipedia">
<item> <url
url="http://en.wikipedia.org/wiki/POSIX_terminal_interface"
name="Terminal Interface per Wikipedia">
<item> <url url="www.gnu.org/manual/glibc/html_chapter/libc_12.html"
name="Low-Level Terminal Interface"> part of "GNU C Library Reference
Manual" (in libc (or glibc) docs package). It covers the detailed
meaning of "stty" commands, etc.
<item> <url url="http://www.boundless.com/terminals.html"
name="Boundless"> purchased the VT and Dorio terminal business from
DEC. Boundless used to have online Specs of their ADDS, VT, and
DORIO terminals but that link (in previous versions of this HOWTO) is
now dead.
<item> Wyse has detailed info (such as escape sequences) in it's
<item> Wyse had detailed info (such as escape sequences) in it's
knowledge base. It's not as complete as a real manual since it mainly
cover "native" personality. <url
url="http://www.wyse.com/service/support/kbase/wyseterm.asp"
name="Wyse text-terminals database"> For current models see <url
url="http://www.wyse.com/products/gpt/index.asp" name="Wyse terminals">.
cover "native" personality. It was Wyse text-terminals database" at
http://www.wyse.com/service/support/kbase/wyseterm.aspi but it's defunct.
You may still access their knowledge base (does it still cover
text-terminals) by registering. Start at <url url="www.wyse.com">.
<item> <url url="http://dickey.his.com/ncurses/ncurses.faq.html"
name="ncurses FAQ"> <item> comp.terminals is the newsgroup for
terminals </itemize>
@ -7243,12 +7305,8 @@ escape sequences options will not be repeated here.
<p>See url url= "http://www.neoware.com/docs/teemtalk/t2k17pro.pdf"
name="TeemTalk.2000 Programmer's Guide v 1.7"> in pdf format. But
there are some sites that have info for certain terminals. For VT
terminals see <url url="http://www.vt100.net/" name="VT Manuals">. A
list for VT (not maintained) may be found in Appendix B of <url
url="http://www.cs.ruu.nl/wais/html/na-dir/emulators-faq/part3.html"
name="Emulators FAQ">. For Wyse see: <url
url="http://www.wyse.com/service/support/kbase/wyseterm.asp"
name="Wyse text-terminals database"> and select the terminal model.
terminals see <url url="http://www.vt100.net/" name="VT Manuals">.
Other lists have disappeared from the internet.
<sect1> 8-bit Control Codes
<p> Table of 8-bit DEC control codes (in hexadecimal). Work on VT2xx or
@ -7673,8 +7731,8 @@ nice if for each terminal model, there were a set of links linking to
most of the documentation relevant to that model (including escape
codes). But it hasn't been done. Note that some VT (DEC) manuals are
now available on the Internet. See and <ref id="dec_" name="VT
(DEC)">. Wyse has put the information from its manuals on the
Internet. See <ref id="wyse_" name="Wyse Terminals">.
(DEC)">. Wyse put the information from its manuals on the
Internet but it can't be readily found now (2013).
<sect1> Adds
<p>The Adds terminal menu incorrectly used "Xon/Xoff" to mean any kind
@ -7761,10 +7819,7 @@ url="http://www.boundless.com/terminals.html" name="Boundless"> name
and url have been retained.
Detailed VT terminal information, some manuals, and
history is at <url url="http://www.vt100.net/">. Other information is
available at <url
url="http://www.cs.utk.edu/~shuford/terminal_index.html" name=
"Shuford's Website">.
history is at <url url="http://www.vt100.net/">.
VT220: Some have a BNC connector for video output (not for input).
Sometimes people erroneously think this is for an ethernet connection.
@ -7784,7 +7839,7 @@ The "sco unix console" is claimed to be a powerful emulation using the
<p> Qume was taken over by Wyse in the early 1990s.
<sect1> Wyse Terminals <label id="wyse_">
<p> For detailed manual-like information on old terminals see <url
<p> detailed manual-like information on old terminals see <url
url="http://www.wyse.com/service/support/kbase/wyseterm.asp">. This
information includes specs, lists of escape sequences, part lists,
FAQs, setup info, etc. Thanks to Wyse for providing this even though
@ -7796,6 +7851,8 @@ these terminals, especially the Wyse 50. But the large number of
failure reports (other than Wyse 50) may be due in part to the large
number of Wyse terminals in use.
See <url url="en.wikipedia.org/wiki/Dell_Wyse"> for a history of Wyse.
<sect2> Wyse 50
<p>Reported not to last very long.
@ -7804,7 +7861,7 @@ number of Wyse terminals in use.
VR302, Width VR101 (also affects height). If you want to use it in
Native Personality, then the arrow-key codes will conflict with the
codes used in vi (such as ^L). To fix this set "Application key mode"
with ESC &tilde; 3. This results in the arrow keys sending 0xd1 - 0xd4.
with ESC &tilde; 3. This results in the arrow keys sending 0xd0 - 0xd3.
Due to a bug in the readline interface of the Bash shell, you need to
edit /etc/inputrc so that the arrow keys will work in Bash. See <ref
id="bash_bug" name="Bugs in Bash">