  Text-Terminal-HOWTO
  David S. Lawyer  <mailto:dave@lafn.org>
  v1.36, August 2004

  This document explains what text terminals are, how they work, how to
  install and configure them, and provides some info on how to repair
  them.  If you don't have a terminal manual, it may be of help.  While
  it's written for real terminals on a Linux system, much of it is also
  applicable to terminal emulation and may be helpful for non-Linux sys­
  tems.
  ______________________________________________________________________

  Table of Contents



  1. Introduction

     1.1 Copyright, Trademarks, Disclaimer, & Credits
        1.1.1 Copyright
        1.1.2 Disclaimer
        1.1.3 Trademarks.
        1.1.4 Credits
     1.2 Future Plans: You Can Help
     1.3 New Versions of this HOWTO
     1.4 New in Recent Versions:
     1.5 Related HOWTOs, etc.
     1.6 Terminology Used in this Document
     1.7 What is a Terminal ?

  2. Types of Terminals

     2.1 Dumb Terminals
     2.2 Text Terminals
     2.3 Graphic GUI Capabilities of Text Terminals
        2.3.1 Graphics GUI displays
     2.4 Thin Clients (Terminals ?)
        2.4.1 Introduction
        2.4.2 MS Window terminals
        2.4.3 Network computers (NCs)
        2.4.4 Thin clients and NCs under Linux
        2.4.5 Hardware hookups
        2.4.6 History and the future
     2.5 Emulation on a PC

  3. Quick Install

  4. Why Use a Terminal ?

     4.1 Intro to Why Use a Terminal
     4.2 Lower Hardware Costs ?
     4.3 Control of Software
     4.4 Hardware Upgrades
     4.5 Other Advantages of Terminals
     4.6 Major Disadvantages of Terminals
     4.7 Are Text Terminals Obsolete ?

  5. Overview of How Terminals Work (in Linux)

     5.1 Device Names
     5.2 Login/Logout
     5.3 Half/Full Duplex
     5.4 Terminal Memory
     5.5 Commands for the Terminal
     5.6 Lack of Standardization Solved by Terminfo
     5.7 The Interface
     5.8 Emulation
     5.9 The Console

  6. Terminal Special Files such as /dev/tty

     6.1 Serial Port Terminals
     6.2 Pseudo Terminals
     6.3 The Controlling Terminal /dev/tty
     6.4 /dev/ttyIN "Terminals"
     6.5 The Console: ttyN or vc/N
     6.6 Creating a Device with "mknod"

  7. Some Details on How Terminals Work

     7.1 Terminal Memory Details
     7.2 Early Terminals
     7.3 Escape Sequences and Control Codes (intro)
        7.3.1 Control codes
        7.3.2 Escape sequences
     7.4 Display Attributes & Magic Cookies

  8. Special Features of Some Terminals

     8.1 Color
     8.2 Multiple Sessions
     8.3 Printer/Auxiliary Port
     8.4 Pages
     8.5 Character-Sets
        8.5.1 Graphics (Line Drawing, etc.)
        8.5.2 National Replacement Characters (obsolete)
     8.6 Fonts
     8.7 Keyboards & Special Keys
     8.8 Mouse

  9. Terminal Emulation (including the Console)

     9.1 Intro to Terminal Emulation
     9.2 Don't Try to Use TERM Variable for Emulation
     9.3 Communication (Dialing) programs
        9.3.1 Emulation under X Window
        9.3.2 Real terminals better
     9.4 Testing Terminal Emulation
     9.5 The Linux Console
     9.6 Emulation Software
        9.6.1 Make a Linux PC a terminal
        9.6.2 Make a non-Linux PC a terminal

  10. Flow Control (Handshaking)

     10.1 Why Is Flow Control Needed ?
     10.2 Padding
     10.3 Overrunning a Serial Port
     10.4 Stop Sending
     10.5 Keyboard Lock
     10.6 Resume Sending
     10.7 Hardware Flow Control (RTS/CTS etc.)
        10.7.1 RTS/CTS, DTR, and DTR/DSR Flow Control
        10.7.2 Connecting up DTR or DTR/DSR Flow Control
        10.7.3 Old RTS/CTS handshaking is different
        10.7.4 Reverse Channel
     10.8 Is Hardware Flow Control Done by Hardware ?
     10.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control

  11. Physical Connection

     11.1 Introduction
     11.2 Multiport I/O Cards (Adapters)
     11.3 Direct Serial Cable Connection.
        11.3.1 Pin numbering
        11.3.2 Null Modem cable pin-out (3, 4, or 5 conductor)
        11.3.3 Standard Null Modem cable pin-out (7 conductor)
        11.3.4 Overcoming length limitations
        11.3.5 Hardware Flow Control cables
        11.3.6 Cable tips
        11.3.7 A kludge using twisted-pair cable
        11.3.8 Cable grounding
     11.4 Modem Connection
        11.4.1 Dialing out from a terminal
        11.4.2 Terminal gets dialed into
     11.5 Telnet
     11.6 Terminal Server Connection
        11.6.1 What is a terminal server ?
        11.6.2 Evolution of the "terminal server"
     11.7 Connector and Adapter Types
        11.7.1 Sex of connector/adapters
        11.7.2 Types of adapters
        11.7.3 DB connectors
        11.7.4 RJ modular connectors
           11.7.4.1 6-conductors: RJ11/14, RJ12,  and MMJ
           11.7.4.2 8-conductors and 10-conductors
     11.8 Making or Modifying a Cable
        11.8.1 Buy or make ?
        11.8.2 Pin numbers of 9 and 25 pin connectors
        11.8.3 Installing DB connectors on cable ends
        11.8.4 Installing RJ connectors

  12. Set-Up (Configure) in General

     12.1 Intro to Set-Up
     12.2 Terminal Set-Up (Configure) Overview
     12.3 Computer Set-Up (Configure) Overview
     12.4 Many Options
     12.5 Communication Interface Options
        12.5.1 Speed
        12.5.2 Parity & should you use it ?
        12.5.3 Bits/Character
        12.5.4 Which Flow Control (Handshaking) ?
        12.5.5 Port select
     12.6 Quick Attempt

  13. Terminal Set-Up (Configure) Details

     13.1 Send Escape Sequences to the Terminal
     13.2 Older Terminals Set-Up
     13.3 Getting Into Set-Up (Configuration) Mode
     13.4 Communication Options
     13.5 Saving the Set-up
     13.6 Set-Up Options/Parameters
     13.7 Emulation {Personality} {{Terminal Modes}}
     13.8 Display Options
        13.8.1 Character Cell Size {Char Cell}
        13.8.2 Columns/Lines
        13.8.3 Cursor
        13.8.4 Display Attributes (Magic Cookies)
        13.8.5 Display Control Characters {Monitor}
        13.8.6 Double Width/Height
        13.8.7 Reverse Video {Display} (Background Light/Dark)
        13.8.8 Status Line
        13.8.9 Upon 80/132 Change: Clear or Preserve?
     13.9 Page Related Options
        13.9.1 Page Size
        13.9.2 Coupling (of cursor & display)
     13.10 Reporting and Answerback
        13.10.1 Answerback Message (String)
        13.10.2 Auto Answerback
        13.10.3 Answerback Concealed
        13.10.4 Terminal ID {ANSI ID}
     13.11 Keyboard Options
        13.11.1 Keyclick
        13.11.2 Caps Lock {Keylock}
        13.11.3 Auto Repeat {Repeat}
        13.11.4 Margin Bell
        13.11.5 Remapping the Keys
        13.11.6 Corner Key (for Wyse only)
        13.11.7 Numeric Keypad or Arrow Keys Sends
        13.11.8 What does shifted-del and shifted-bs send?
        13.11.9 PC Scan Codes
        13.11.10 Alternate Characters
     13.12 Meaning of Received Control Codes
        13.12.1 Auto New Line {Newline}
        13.12.2 Auto Line Feed {Rcv CR}
        13.12.3 Recognize Del (Wyse Only ??) or Null
     13.13 Where New Text Goes
        13.13.1 Line Wrap
        13.13.2 Scrolling
        13.13.3 New Page?
     13.14 Function Keys
     13.15 Block Mode Options
        13.15.1 Forms Display
        13.15.2 Send Entire Block ?
        13.15.3 Region to Send
        13.15.4 Block/Page terminator
     13.16 Locks
     13.17 Screen Saver {Scrn Saver}
     13.18 Printer

  14. Computer Set-Up (Configure) Details

     14.1 Getty (used in /etc/inittab)
        14.1.1 Introduction to Getty
        14.1.2 Getty exits after login (and can respawn)
        14.1.3 If getty run from command line: Programs get stopped
        14.1.4 agetty (may be named getty)
           14.1.4.1 Agetty's auto-detection of parity problems
           14.1.4.2 8-bit data bytes (plus parity)
        14.1.5 getty (part of getty_ps)
        14.1.6 mgetty
     14.2 Stty & Setserial
     14.3 Setserial
        14.3.1 Important information
        14.3.2 Introduction
        14.3.3 Serial module unload
        14.3.4 Giving the setserial command
        14.3.5 Configuration file
        14.3.6 Probing
        14.3.7 Boot-time Configuration
        14.3.8 Edit a script (required prior to version 2.15)
        14.3.9 Configuration method using /etc/serial.conf, etc.
        14.3.10 IRQs
        14.3.11 Laptops: PCMCIA
     14.4 Stty
        14.4.1 Introduction
        14.4.2 Flow control options
        14.4.3 Using stty at a "foreign" terminal
           14.4.3.1 Old redirection method
        14.4.4 Two interfaces at a terminal
        14.4.5 Where to put the stty command ?
     14.5 Terminfo & Termcap (brief)
     14.6 Setting TERM and TERMINFO
        14.6.1 What is the terminfo name of my terminal ?
     14.7 Rarely Needed /etc/ttytype File
     14.8 Login Restrictions
     14.9 Run Command Only If TERM=my_term_type
        14.9.1 Example for ls Function
     14.10 Character Mapping: mapchan

  15. Terminfo and Termcap (detailed)

     15.1 Intro to Terminfo
     15.2 Terminfo Database
        15.2.1 Introduction
        15.2.2 Where is the database located ?
           15.2.2.1 Compiled database locations
           15.2.2.2 Source-code database locations
        15.2.3 Terminfo Compiler (tic)
        15.2.4 Look at Your Terminfo
        15.2.5 Deleting Data Not Needed
     15.3 Bugs in Existing Terminfo Files (and Hardware)
     15.4 Modifying Terminfo Files
     15.5 Init String
     15.6 TERM Variable
     15.7 Terminfo/Termcap Documents

  16. Using the Terminal

     16.1 Intro to Using the Terminal
     16.2 Starting Up the Terminal
     16.3 Terminal (Serial) Device Driver
     16.4 Problems with Editors
        16.4.1 emacs
        16.4.2 vi and Cursor-Keys
     16.5 Bugs in Bash
     16.6 Color ls Corruption
     16.7 Display Freezes (hung terminal)
     16.8 Corrupted Terminal Interface
        16.8.1 Symptoms and some fixes
        16.8.2 Sent terminal binary characters
        16.8.3 Reset command was broken but now fixed
        16.8.4 Character corruption
        16.8.5 Abnormally exited a program
     16.9 Special (Control) Characters
        16.9.1 Command-Line Editing
        16.9.2 Interrupting (& Quit, Suspend, EOF, Flush)
        16.9.3 Stop/Start Scrolling
        16.9.4 Take next character literally
     16.10 Viewing Latin1 Files on a non-Latin1 terminal
     16.11 Eliminating Overstriking in Files
     16.12 Inspecting the Interface
     16.13 Changing the Terminal Settings
        16.13.1 setterm
        16.13.2 tput
        16.13.3 echo
        16.13.4 Saving changes
     16.14 Multiple Sessions
     16.15 Logging Out
     16.16 Chatting between Terminals, Spying
     16.17 Sharing the Serial Port
     16.18 Browsers for Terminals

  17. Special Uses for a Terminal

     17.1 Make a Serial Terminal the Console
        17.1.1 For Kernels 2.2 or higher
        17.1.2 For Kernels before 2.2
     17.2 Run Linux without a Monitor
     17.3 Use a Keyboardless Terminal as the Monitor
        17.3.1 How it works
        17.3.2 Example configuration

  18. Trouble-Shooting

     18.1 Terminal Was Working OK
     18.2 Terminal Newly Installed
     18.3 Is the Terminal OK ?
     18.4 Missing Text
     18.5 All Keys Work Erratically; Must Hit a Key a Few Times
     18.6 ... respawning too fast: disabled for 5 minutes
        18.6.1 What's happening
        18.6.2 Getty line in /etc/inittab file incorrect
        18.6.3 No modem control signal
        18.6.4 No such serial device
        18.6.5 No serial support
        18.6.6 Key shorted
     18.7 Fails Just After Login
     18.8 Can't Login
     18.9 Garbled Login Prompt
     18.10 No Login Prompt
        18.10.1 Terminal was working OK
        18.10.2 More diagnose
        18.10.3 Diagnose problem from the console
        18.10.4 Measure voltages
     18.11 Displays Foreign/Weird Characters/Symbols
     18.12 Displays Escape Sequences
        18.12.1 Telnet
        18.12.2 Terminal set to display escape sequences
     18.13 Slow: pauses of several seconds between bursts of characters
     18.14 Terminal doesn't scroll
     18.15 Serial Monitoring/Diagnostics
     18.16 Local Mode
     18.17 Serial Electrical Test Equipment
        18.17.1 Breakout Gadgets, etc.
        18.17.2 Measuring voltages
        18.17.3 Taste voltage

  19. Repair & Diagnose

     19.1 Repair Books & Websites
        19.1.1 Books
        19.1.2 Websites
     19.2 Safety
     19.3 Appearance of Display
     19.4 Diagnose
        19.4.1 Terminal Made a Noise or Smoked
        19.4.2 Terminal Made No Noise
     19.5 Detective work
     19.6 Error Messages on the Screen
        19.6.1 Keyboard Error
        19.6.2 Checksum Error in NVR
     19.7 Capacitors
     19.8 Keyboards
        19.8.1 Interchangeability
        19.8.2 How They Work
        19.8.3 Modern vs Old Keyboards
        19.8.4 One Press Types 2 Different Characters
        19.8.5 Keyboard doesn't work at all
        19.8.6 Typing b displays bb, etc. (doubled)
        19.8.7 Row upon row of the same character appears
           19.8.7.1 Key sticks in down position (individual switches)
           19.8.7.2 Key electrically shorted
        19.8.8 Liquid spilled on the keyboard
        19.8.9 Cleaning keyboard contacts
           19.8.9.1 Keyboards with membranes
           19.8.9.2 Keyboards with individual switches

  20. Appendix A: General

     20.1 List of Linux Terminal Commands
        20.1.1 Sending a command to the terminal
        20.1.2 Configuring the terminal device driver
        20.1.3 Terminfo
        20.1.4 Other
     20.2 The Internet and Books
        20.2.1 Terminal Info on the Internet
        20.2.2 Books related to terminals
        20.2.3 Entire books on terminals
        20.2.4 Books with chapters on terminals
     20.3 Non-Linux OSs

  21. Appendix B: Escape Sequence Commands Terminology

     21.1 Esc Sequence List
     21.2 8-bit Control Codes
     21.3 Printer Esc
     21.4 Reports
     21.5 Cursor Movements
     21.6 Pages (definition)

  22. Appendix C: Serial Communications on EIA-232 (RS-232)

     22.1 Intro to Serial Communication
     22.2 Voltages
        22.2.1 Voltage for a bit
        22.2.2 Voltage sequence for a byte
     22.3 Parity Explained
     22.4 Forming a Byte (Framing)
     22.5 Limitations of EIA-232
        22.5.1 Low Speed & Short Distance
        22.5.2 Successors to EIA-232
        22.5.3 Line Drivers
     22.6 Synchronization & Synchronous
        22.6.1 How "Asynchronous" is Synchronized
        22.6.2 Defining Asynchronous vs Synchronous
        22.6.3 Synchronous Communication
     22.7 Block Mode
        22.7.1 Introduction to Block Mode
        22.7.2 Types of Block Modes, Forms
        22.7.3 Efficiency
        22.7.4 Problems with block mode
     22.8 EIA-232 (RS-232) Books
     22.9 Serial Software

  23. Appendix D: Notes by Brand/Model

     23.1 Adds
     23.2 CIT
     23.3 IBM Terminals
        23.3.1 IBM 3153
     23.4 Teletypes
     23.5 VT (DEC)
     23.6 Links
     23.7 Qume
     23.8 Wyse Terminals
        23.8.1 Wyse 50
        23.8.2 Wyse 60
        23.8.3 Wyse 85
        23.8.4 Wyse 99-GT
        23.8.5 Wyse 150


  ______________________________________________________________________

  1.  Introduction

  For a quick attempt to install a terminal see ``Quick Install''.


  1.1.  Copyright, Trademarks, Disclaimer, & Credits

  1.1.1.  Copyright

  Copyright 1998-2001 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.


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


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



  1.1.4.  Credits

  Much of the section "Physical Connection" is from Serial-HOWTO v.
  1.11 (1997) by Greg Hankins (with his permission).  His "How Do I Set
  Up A Terminal Connected To My PC?" was incorporated into v1.00 at
  various places.  v1.09 has about 25 changes (and error corrections)
  suggested by Alessandro Rubini who reviewed this HOWTO.  Jeremy Jon
  Spykerman told me about using a keyboardless terminal as a console for
  a monitorless PC (using ttysnoop).  In 2001 (v1.26) I fixed about 25
  typos, etc. found by Alain Cochard:


  1.2.  Future Plans: You Can Help

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

  Starting with version 1.00, a first attempt was made to help people
  set up terminals without recourse to a terminal manual.  Much more is
  needed in this respect.  One way to solve this problem would be for
  more terminal manufacturers put their manuals on the Internet.  Wyse
  has already done so.  I suggest that you encourage others to do so (if
  they haven't already).  The task of providing information on how to
  configure most terminals in this HOWTO is daunting.  There are so many
  different terminals, but there are far fewer models than there used to
  be in the 1980,s so the task is not totally infeasible.
  Please send me any surplus terminal manuals which you may have,
  especially on terminals made within the past 10 years (but I'll accept
  older ones also).  Also, you might want to write up something on a
  certain terminal to put in the Appendix D: Notes by Brand Name.


  1.3.  New Versions of this HOWTO

  New versions of the Text-Terminal-HOWTO should be released every few
  months or so.  They will be available to browse and/or download at LDP
  mirror sites.  For a list of mirror sites see:
  <http://tldp.org/mirrors.html>.  Various formats are available.  If
  you only want to quickly check the date of the latest version look at
  <http://tldp.org/HOWTO/Text-Terminal-HOWTO.html>.  The version your
  are currently reading is: v1.36, August 2004 .


  1.4.  New in Recent Versions:

  For a full revision history going back to the first version see the
  source file (in linuxdoc format) at
  <http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Text-
  Terminal-HOWTO.sgml.gz>.


  ·  v1.36 Aug. 2004 Typo for "quit", etc.  Should be ^\

  ·  v1.35 Mar. 2004: Wyse 60 emulator

  ·  v1.34 Dec. 2003: All   (tildes) are now in text (formatting problem
     with Linuxdoc)

  ·  v1.33 Nov. 2003: revised setserial section; using minicom with
     directly connected terminals

  ·  v1.32: September 2003: man page console_codes, name: serial
     monitor/console, "init string" rewrite, netrik text browser, new
     url for terminfo


  1.5.  Related HOWTOs, etc.

  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.

  ·  Low-Level Terminal Interface
     <www.gnu.org/manual/glibc/html_chapter/libc_12.html> part of "GNU C
     Library Reference Manual" (in libc (or glibc) docs package).  It
     covers the detailed meaning of "stty" commands, etc.

  ·  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

  ·  Xterminal-HOWTO (old and unmaintained).  It's at
     <http://ibiblio.unc.edu/pub/Linux/docs/HOWTO/unmaintained/mini/Xterminal>


  1.6.  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.7.  What is a Terminal ?

  A real terminal consists of a screen and keyboard that one uses to
  communicate remotely with a (host) computer.  One uses it just like it
  was a personal computer but the terminal is remote from its host
  computer (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.  The terminal's computational ability
  is relatively low (otherwise it would be a computer and not a
  terminal).  The terminal is generally limited to the ability to
  display what is sent to it (possibly including full-screen graphics)
  and the ability to send to the host what is typed at the keyboard.

  A text-terminal only displays text on the screen without pictures.  In
  the days of mainframes from the mid 1970's to the mid 1980's, most
  people used real text-terminals to communicate with computers.  They
  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 and the speed slow by today's standards
  due to the high cost of memory and the limited speed of the
  conventional serial port, etc.

  Today, real terminals are not as common as they once were and most
  people that use terminals use a personal computer to emulate a
  terminal.  Almost everyone who uses Linux uses terminal emulation.
  Without X Window, one uses a text interface (virtual terminal).  It's
  also called a command line interface.  In X Window one can get one or
  more terminal windows (xterm, rxvt, or zterm).  All these use software
  to emulate a real terminal.

  A real text-terminal is different from a monitor because it's a
  different electronic setup.  A text terminal is often connected to a
  serial port of the computer via a long cable.  Thus, in contrast to a
  monitor which is usually located right next to the computer, a
  terminal may be quite a distance away from its host computer.  For a
  monitor, the video card inside a computer stores the video image.  For
  a terminal, the equivalent of this video card is built right into the
  terminal but since text terminals are often monochrome without much
  graphics, the capabilities of its "video card" are rather weak.  Also,
  most text terminals do not have mice.


  In network client-server terminology, one might think that the
  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.  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 a
  terminal and use the computer simultaneously with others.


  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 in place of "smart" 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
  usually represents a printable character.  Bytes typed at the keyboard
  go to the 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 commands and most
  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.  Sometimes the connection is via modem or terminal
  server, etc.

  Other names for text terminals are "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).  The names "serial monitor" and "serial console" may
  refer to a PC that is running a program to emulate a text terminal.
  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 the send key (or the
  like) is pressed, 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

  Many text terminals can display bit-mapped images, but not in color.
  Unfortunately, the popular image formats used on the Internet are not
  supported.  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 _ and
  |.  With special graphic character sets that have a lot of special
  characters for line drawing, even 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.


  2.3.1.  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 move in any direction (at any angle and location).  True
  vector graphics draws high quality lines without 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 are sometimes used but they are translated to
  raster graphics format for display (with a resulting drop in image
  quality).


  2.4.  Thin Clients (Terminals ?)

  2.4.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. 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.  Thin-clients need
  more computing power.  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".

  Such clients may be created from an ordinary PC by using software or
  may be a stand-alone piece of hardware.  But the stand-alone hardware
  will often use a conventional PC monitor plus a small box for the
  computer part of the hardware.  Linux seems to favor the use of PCs as
  a client.
  Some claim that text-terminals are also thin clients 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.  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 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.  One even has a USB interface.

  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''


  2.4.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:
  Citrix Systems, Inc. <http://www.citrix.com/download/unix-
  downloads.asp>.  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.


  2.4.3.  Network computers (NCs)

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


  2.4.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 mini-HOWTO (NCD-ThinSTAR)

  ·  NCD-X-Terminal mini-HOWTO

  ·  XDM-and-X-Terminal mini-HOWTO


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


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



  2.5.  Emulation on a PC

  Since a PC has a screen and keyboard (as does a 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 text terminal.  This is
  called "terminal emulation".  They usually emulate text-terminals.
  See ``Terminal Emulation''


  3.  Quick 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 or tts/1), 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 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''.


  4.  Why Use a Terminal ?

  4.1.  Intro to Why Use a Terminal

  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
  with the lynx browser, etc.  So it's not exactly "centralized" either.

  Terminals have seldom been 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.  The drawback is that text terminals
  are not smart enough to support the type of graphical user interface
  (GUI) that many computer users today normally expect.


  4.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.  Here's what I wrote
  years ago when PCs were more expensive.  It's still true 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 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.


  4.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 by not
  installing the software (or by otherwise restricting access to it).
  Whether or not centralized control is desirable depends on the
  situation.


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

  4.5.  Other Advantages of Terminals



  ·  The elimination of noise from fans and disk drives (unless your
     using a PC to emulate a terminal).

  ·  The users of the terminals can share data and files and send e-mail
     to each other.  It's similar to a local network.


  4.6.  Major Disadvantages of Terminals



  ·  Text terminals have 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.

  ·  If the host computer goes down, then no one can use the terminals
     either (unless there is a "standby" host computer to connect to).


  4.7.  Are Text Terminals Obsolete ?

  Text terminals are technologically obsolete because for a slightly
  higher cost of hardware, one could 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 has a terminal emulator available.

  The reasons that text terminals are not fully obsolete are:

  ·  The resolution of characters on the screen is better on monochrome
     terminals than for monitors in text mode.

  ·  Many 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.


  5.  Overview of How Terminals Work (in Linux)

  See also section ``Some Details on How Terminals Work''


  5.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:
  tts/0 (or ttyS0), tts/1 (or ttyS1), tts/2 (or ttyS2) etc.

  These are represented by special files found in the /dev (device)
  directory.  tts/0 (or ttyS0) corresponds to COM1 in DOS or Windows.
  tts/1 (or ttyS1) is COM2, etc.  See ``Terminal Special Files'' for
  details on these and related "devices".



  5.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 log in (after giving their passwords) and then have
  access to the computer.  When it's time to shut the terminal down, one
  normally logs out and turns the terminal off.  See ``Login
  Restrictions'' regarding restricting logins (including allowing the
  root user to log in at terminal).


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


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


  5.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 the 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''


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


  5.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''.


  5.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 is a major terminal manufacturer and 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 VT012 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''.


  5.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''.


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


  6.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/tts/0
  (or /dev/ttyS0) is the special file for the serial port known as COM1
  in the DOS/Windows world.  The device filesystem notation: tts/0 is
  replacing the older ttyS0 notation.  But the older notation will be
  often used in this howto since it is still widely used and often still
  works (using symbolic links) on the newer device filesystems.

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



  6.2.  Pseudo Terminals

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

  For talking to s3 (ttyp3), any program designed to talk to a serial
  port will do.  But for the other program that talks to m3 (ptyp3) it
  must have been specially written to talk to m3.  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, the part of the telnet program handling this
  connection on your computer may wind up connected to the device m2
  (ptyp2) (a pseudo terminal port).  A getty program should be running
  on the corresponding s2 (ttyp2).  When telnet gets a character from
  the remote, it goes thru m2 to s2 to getty which then sends back
  "login:" routed to s2, m2, your telnet program, and then out to the
  network.  Here the login program and the telnet program talk to each
  other via a "pseudo terminal".  In X Window, the terminal emulator
  program, xterm (or rxvt), uses 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 m3 (ptyp3) and s3 (ttyp3), the m...
  (pty...) is the master or controlling terminal and the s... (tty...)
  is the slave.  The device filesystem notation makes this clear (m is
  for master, s is for slave).  The slave is like a serial port so also
  think of s as standing for "serial".  In the old notation, tty.. is
  like a serial port ttyS (which in olden days was just tty).

  Prior to the device filesystem a complex notation was used in order to
  get a large number of pseudo terminals.  There are only 16 ttyp's:
  ttyp0-ttypf (f is a hexadecimal digit).  To get more pairs, more
  letters such as q, r, s were used instead of p.  For example the pair
  ttys8, ptys8 was a pseudo terminal pair.  Later on, even more letters
  were added so as to allow even more pseudo terminals.  With the device
  filesystem, we may just use, for example, /dev/pty/m57 instead of
  /dev/ttys9 for the 58th pty master.  People have made the mistake of
  typing say ttys2 (which is a pseudo serial port) when they meant to
  type 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 (available on Linux) doesn't use the above but instead uses a
  "pty master" which might be, for example, /dev/ptm3.  It's slave is
  automatically created as /dev/pts/3.  It thus supplies a pty on
  demand.  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 it would be an entry in the device
  filesystem, it's really a wholly different kind of filesystem.


  While other unix-like systems have a manual page for pseudo terminals
  (may be named "pty") Linux lacks one for the general user.  But there
  is a man-page for programmers: (openpty or forkpty) which assumes that
  you already understand pseudo terminals.  There is both a Linux pty
  module and a /usr/include/pty.h file.


  6.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).


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


  6.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''.


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


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



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


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


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


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


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


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


  8.  Special Features of Some Terminals



  8.1.  Color

  While the common monochrome terminal is not a color terminal it may
  have a fixed "color" display other than white such as green or amber.
  All terminals have 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.

  Color works like the color on a computer monitor or TV screen.  The
  CRT has three colors of dots on it with each color controlled by its
  own electron beam (3 beams).  Monochrome has inherently better
  resolution since it doesn't depend on dots permanently fixed on the
  screen.  For text terminals the only use of color is to differentiate
  text and this advantage is not always worth the cost of worse
  resolution.  Thus monochrome may be better since it also costs less.


  8.2.  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".


  8.3.  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
  <http://garrett.damore.org/~garrett/software/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.


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


  8.5.  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 <http://czyborra.com/charsets/iso8859.html>
     More than just iso8859.  Extensive.

  ·  A tutorial on character code issues
     <http://www.cs.tut.fi/~jkorpela/chars.html> Clearly written.

  ·  Languages, Countries and Character Sets
     <http://www.w3.org/International/O-charset-lang.html>

  ·  Languages of the World by Computers ...
     <http://www.osk.3web.ne.jp/logos/>

  ·  Links re Internationalization
     <http://linux.monnet.ru/books/locale/locale_i.html> A long list of
     links (in Russian but most words in English).

  ·  ... International Character Sets
     <ftp://kermit.columbia.edu/kermit/e/isok7.txt>

  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.


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


  8.5.2.  National Replacement Characters (obsolete)

  These result in modified 7-bit ASCII codes.  They became obsolete in
  the 1990's but exist on some older terminals.  Many West-European
  languages only need several additional letters which are not in ASCII.
  To get them in 7-bit code, one may borrow 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 ASCII
  symbols since they now are used for the new non-ASCII letters.  Now
  that 8-bit character codes have mostly 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.

  ISO-646 (for 1972 and later) permits using National Replacement
  Characters (7-bit).  It specifies 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 them unless you
  have some old files to read.  Very old terminals may only support one
  language (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     --------



  8.6.  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 (in 1998) was at
  Europe:  <http://www.funet.fi/pub/culture/russian/comp/cyril-term/>
  N. America:  <http://ibiblio.unc.edu/pub/Linux/utils/terminal/> For
  mapping the keyboard (and screen) for use of various fonts see
  ``Character Mapping: mapchan''


  8.7.  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 usually may be
     programmed to send out a sequence of bytes (characters).  See
     ``Function Keys''


  8.8.  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.
  For a mouse on VT terminals see
  <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 ??



  9.  Terminal Emulation (including the Console)

  9.1.  Intro to Terminal Emulation

  Since a PC has a screen and keyboard (as does a 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 text terminal.  This is
  one type of terminal emulation.  Another 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 is about the first type of emulation: emulating a terminal on
  a PC.

  In emulation, one of the serial ports of the computer will be used to
  connect the emulated terminal to another computer, either with a
  direct cable connection from serial port to serial port, or via a
  modem.  Emulation provides more that just a terminal since the PC
  doing the emulation can also do other tasks at the same time it's
  emulating a terminal.  For example, 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.

  Much emulation software is available for use under the MS Windows OS.
  See ``Make a non-Linux PC a terminal''  This can be used to connect a
  Windows PC to a Linux PC (as a Text-Terminal).  Most Linux free
  software can only emulate a VT100, VT102, or VT100/ANSI.  If you find
  out about any others, let me know.  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.  For using a Mac computer to emulate a terminal
  see the mini-howto: Mac-Terminal.


  9.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.  If you're at a Linux PC monitor (command line interface)
  it's a terminal of type "Linux" and your can't change this.  So you
  must set TERM to "Linux".

  If you set it to something else you are fibbing to application
  programs.  As a result they 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 something like a vt100).  It may seeming work OK
  most of the time but once in a while will make a mistake when editing
  or the like.


  9.3.  Communication (Dialing) programs

  Dialing programs for making a PPP connection to the Internet don't
  normally include any terminal emulation.  But some other modem dialing
  programs (such as minicom or seyon) do.  Using them, one may (for
  example) dial up some public libraries to use their catalogs and
  indexes, (or even read magazine articles).  They are also useful for
  testing modems.  Seyon is only for use with X Window and can emulate
  Tektronix 4014 terminals.

  The communication program Kermit doesn't do terminal emulation as it
  is 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 on 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 escape sequences coming into your computer's serial
  port from a remote computer will get translated to the Wyse escape
  sequences before going out another serial port to your Wyse60
  terminal.  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).


  9.3.1.  Emulation under X Window

  Xterm (or uxterm which is like xterm except it supports unicode) may
  be run under X Window.  They can emulate a VT102, VT220, or Tektronix
  4014.  There is also an xterm emulation (although there is no physical
  terminal named "xterm").   If you don't need the Tektronix 4014
  emulation (a vector graphics terminal; see ``Graphics Terminals'') you
  may use eterm.  Predecessors to eterm are rxvt and xvt.  eterm
  supports pixmaps.

  For non-Latin alphabets, kterm is for Kanji terminal emulation (or for
  other non-Latin alphabets) while xcin is for Chinese.  There is also
  9term emulation.  This seems to be more than just an emulator as it
  has a built-in editor and scroll-bars.  It was designed for Plan 9, a
  Unix-like operating system from AT&T.


  9.3.2.  Real terminals better

  Unless you are using X Window with a large display, a real terminal is
  often nicer to use than emulating one.  It usually has better
  resolution for text, and has no disk drives to make annoying noises.


  9.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://ibiblio.unc.edu/pub/Linux/utils/console/>


  9.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
  (unless you want to spend weeks rewriting the kernel code) to get it
  to emulate anything else.  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.  See
  ``Don't Use TERM For Emulation''
  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.


  9.6.  Emulation Software

  Emulators often don't work quite right so before purchasing software
  you should try to throughly check out what you will get.


  9.6.1.  Make a Linux PC a terminal

  Unless you want to emulate the standard vt100 (or close to it) or a
  Wyse 60, there doesn't seem to be much free terminal emulation
  software available for Linux.  The free programs minicom and seyon
  (only for X Window) can emulate a vt100 (or close to it).   Seyon can
  also emulate a Tektronix 4014 terminal.  See Wyse 60 emulator
  <http://gutschke.com/wy60/>

  Minicom may be used to emulate a directly connected terminal by simply
  starting minicom (after configuring it for the serial port used).  Of
  course, you don't dial out and when you want to quit (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 terminal emulator "Procomm" (which is from Dos), can be used on a
  Linux PC if you run dosemu to emulate Dos.  For details see:
  <http://solarflow.dyndns.org/pcplus/>.

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

  TERM (non-free commercial software from Century Software)
  <http://www.ecc400.com/censoft/termunix.html> 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.


  9.6.2.  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 connected to a Linux-PC.  Under DOS there
  is telix and procomm.   Windows comes with "HyperTerminal" (formerly
  simply called "Terminal" in Windows 3.x and DOS).  Competing with this
  is "HyperTerminal Private Edition"
  <http://www.hilgraeve.com/htpe/index.html> which is non-free to
  business.  It can emulate vt-220.  The Windows "terminals" are
  intended for calling out with a modem but they should also work as
  directly connected terminals??  Turbosoft's TTWin can emulate over 80
  different terminals under Windows.  See  <http://www.ttwin.com/> or
  <http://www.turbosoft.com.au/> (Australia).  See also Reflection
  <http://www.wrq.com/>

  For the Mac Computer there is emulation by Carnation Software
  <http://www.carnationsoftware.com/carnation/HT.Carn.Home.html>

  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
  <http://www.cs.utk.edu/~shuford/terminal/term_emulator_products.txt>.


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

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


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


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


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


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


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


  10.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).


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


  10.7.2.  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 null modem (crossover) 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.


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


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


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


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


  11.  Physical Connection

  11.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).


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


  11.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 PC's come with a couple of serial ports,
  but one is usually used by a mouse.  For the EIA-232 port, you need a
  null modem 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).


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


  11.3.2.  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" ).


  11.3.3.  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 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 null-modem 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.


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


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


  11.3.6.  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) 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.


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


  11.3.8.  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 ??


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


  11.4.1.  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 the host computer on this modem may
  run a getty program to enable you to log in.


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


  11.5.  Telnet

  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.


  11.6.  Terminal Server Connection

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


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

  11.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. DBxx with pins (such as DB25) and 2.
  modular telephone-style connectors.

  An adapter looks about like a connector but it has two ends.  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 on each side.  It allows two incompatible
  connectors to mate with each other by going in between them.
  Sometimes the purpose of the adapter is to interchange wires.
  Obviously, one may use a special cable (perhaps homemade) as a
  substitute for an adapter.


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


  11.7.2.  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.)


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


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


  11.7.4.1.  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 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 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 null-modem 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
  null-modem cable.  Find one and wire your cable the same way.

  If you lay such a cable (or your terminal null-modem 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 null- modem 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 null-modem
  adapter.  Two null-modem devices 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



  11.7.4.2.  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 |
            |__.    .__|                   |__.    .__|
               |____|                         |____|



  11.8.  Making or Modifying a Cable

  11.8.1.  Buy or make ?

  You may try to buy a short, null modem cable.  Just a "modem cable"
  will not work.  Null modem cables are often labeled as serial printer
  cables (but serial printers are not very popular today and neither are
  the cables).  Unfortunately, they will probably not work for hardware
  flow control (until Linux supports DTR flow control, possibly in
  2001).  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.


  11.8.2.  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/
           ------                         -----------------------------------



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


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


  12.  Set-Up (Configure) in General

  12.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''.


  12.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''.


  12.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''.


  12.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?


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


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


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


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



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


  12.5.5.  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).


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


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


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


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


  13.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).


  13.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).

  ·  Receiver Handshake {Rcv Hndshk} protects data being Received by the
     terminal by transmitting flow-control signals to the host.

  ·  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} ?


  13.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.
  13.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 {{...}}.


  13.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 ??).


  13.8.  Display Options

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


  13.8.2.  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''


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



  13.8.4.  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).


  13.8.5.  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''.


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


  13.8.7.  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).


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


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


  13.9.  Page Related Options

  For a Wyse terminal to be able to access multiple pages of display
  memory {Multipage} must be set to on.


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


  13.9.2.  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".


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


  13.10.1.  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).


  13.10.2.  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 ??


  13.10.3.  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).


  13.10.4.  Terminal ID {ANSI ID}

  The terminal sends this reply in answer to a request for identity.


  13.11.  Keyboard Options

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



  13.11.2.  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.).


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


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


  13.11.5.  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''


  13.11.6.  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 ??


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


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


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


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


  13.12.  Meaning of Received Control Codes

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


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


  13.12.3.  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''


  13.13.  Where New Text Goes

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


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


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


  13.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.  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).


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


  13.15.1.  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)


  13.15.2.  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}


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


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


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


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


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


  14.  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).


  14.1.  Getty (used in /etc/inittab)

  14.1.1.  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): Very easy to set up. No
     config files.  See ``agetty''

  2. ``getty (part of getty_ps)''

     Two gettys best for 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

  Your Linux distribution may come with either ps_getty or agetty for
  text-terminals.  Some distributions supply neither.  Unfortunately,
  they often just call it "getty" so you may need to determine which one
  you have since the arguments you put after it in /etc/inittab differ.
  Debian uses agetty (in the util-linux package).  RedHat uses ps_getty
  which was found at:
  <http://www.redhat.com/swr/i386/getty_ps-2.0.7j-12.i386.html>

  As a last resort to try to determine which getty you have, you might
  check out its executable code (usually in /sbin).  ps_getty 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:
  -h

  If you don't have the getty you want check other distributions and the
  alien program to convert between RPM and Debian packages.  The source
  code may be downloaded from Getty Software
  <http://ibiblio.unc.edu/pub/Linux/system/serial/getty/>.

  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.


  14.1.2.  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).



  14.1.3.  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 tty11.  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.


  14.1.4.  agetty (may be named getty)

  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 hard­
  ware flow control (same as stty crtscts).  19200 is the baud rate.
  ttyS1 means /dev/ttyS1 (COM2 in MS-DOS).  vt102 is the type of termi­
  nal and this getty will set the environment variable TERM to this
  value.  There are no configuration files.  Type "init q" on the com­
  mand line after editing getty and you should see a login prompt.


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


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


  14.1.5.  getty (part of getty_ps)

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


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



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


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


  14.3.1.  Important information


  If you have a Laptop (PCMCIA) don't use setserial until you read
  ``Laptops: PCMCIA''.


  14.3.2.  Introduction

  setserial is a program which allows you (or a shell script) to talk to
  the serial device driver 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 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 configure the
  serial port hardware: It can't set the IRQ or port addresses into the
  hardware.  Furthermore, when it reports the configuration of the
  hardware, it's sometimes wrong since it doesn't acuually probe the
  hardware unless you specifically tell it to.  Actually, it's 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
  jumper-less 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 ot find out how
  the port is configured, it may just repeat the incorrect information
  in the 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 port's, there's usually better ways to look for them.

  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 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 boottime, 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 I0 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, setserial could be telling you
  what's in them, 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 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 these, then there's no need to
  use setserial.  The driver doesn't probe for legacy IRQs 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.


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



  14.3.4.  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.  Note that where it says "UART: unknown" it probably means
  that no uart exists.  In other words, you probably have no such serial
  port and the other info shown about the port is meaningless and should
  be ignored.  If you really do have such a serial port, setserial
  doesn't recognize it and that needs to be fixed.

  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.


  14.3.5.  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 the configuration file.  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)''.



  14.3.6.  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.
  Probling 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 :
  /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
  configuration file such as /etc/serial.conf 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.


  14.3.7.  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 in /etc/serial.conf (or autoserial.conf) 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.''.


  14.3.8.  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's was reported that other processes may try to open the serial port
  before rc.local ran resulting in serial communication failure.  Later
  on it's 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 as 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.


  14.3.9.  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)''.  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 don't 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.  There's an option to avoid this in Debian known
  as "AUTOSAVE-ONCE" which will be discussed later on.

  If 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".


  14.3.10.  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
  complied 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 both on 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 may be one you can use for a serial port for a modem.


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



  14.4.  Stty

  14.4.1.  Introduction

  stty does much of the configuration of the serial port but since
  application programs (and the getty program) often handle it, 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 guru.  Most of the defaults should work OK and some of
  the settings are needed only for certain obsolete dumb terminals made
  in the 1970's.

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

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

  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 is useful.  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.


  14.4.2.  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 restarts 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 the the PC's port will be overrun.  So you seldom
  actually need to enable ixoff.  But it's often enabled "just in case".



  14.4.3.  Using stty at a "foreign" terminal

  Using stty to configure the terminal that you are currently using is
  easy.  Doing it for a different (foreign) terminal or serial port may
  be impossible.  For example, let's say you are at the PC monitor
  (tty1) and want to use stty to deal with the serial port ttyS2.  Prior
  to about 2000 you needed to use the redirection operator "<".  After
  2000 (provided your version of setserial is >= 1.17 and stty >= 2.0)
  there is a better method using the -F option.  This will work when the
  old redirection method fails.  Even with the latest versions be warned
  that if there is a terminal on ttyS2 and a shell is running on that
  terminal, then what you see will likely be deceptive and trying to set
  it will not work.  See ``Two interfaces at a terminal'' to understand
  it.

  The new method is ``stty -F /dev/ttyS2 ...'' (or --file instead of F).
  If  ... is -a it displays all the stty settings.  The old redirection
  method (which still works in later versions) is to type ``stty ...
  </dev/ttyS2''.   If the new method works but the old one hangs, it
  implies that the port is hung due to a modem control line not being
  asserted.  Thus the old method is still useful for troubleshooting.
  See the following subsection for details.


  14.4.3.1.  Old redirection method

  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.

  The old redirection method 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.  Some people tried to use
  ``stty ... > /dev/ttyS2'' to set the terminal.  This will not do it.
  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.


  14.4.4.  Two interfaces at a terminal

  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
  <return> 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 anything to this cooked mode but what
  was typed in raw mode gets executed 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 since you
  are starting the command-line editor).  The settings for the "raw"
  mode are based only on the basic 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 <return> key at the terminal that has
  supposedly been "set".

  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 another
  (foreign) terminal 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 <return> at the terminal you tried to "set".  But if
  you type a stty command at your terminal (without the -F option or
  redirection) and then hit <return> it's a different story.  The
  <return> 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).

  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.

  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.


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


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


  14.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)''.


  14.6.1.  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''.


  14.7.  Rarely Needed /etc/ttytype File

  The configuration file /etc/ttytype is used to map /dev/ttySn's to
  terminal names per terminfo.  tset 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


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


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


  14.9.1.  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:



  ______________________________________________________________________
  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
  ______________________________________________________________________



  14.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, but in Russian with English manual) was at
  "http://www.kron.vinnica.ua/free/download/" but this link is dead in
  2003.


  15.  Terminfo and Termcap (detailed)

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


  15.2.  Terminfo Database

  15.2.1.  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 ?''


  15.2.2.  Where is the database located ?

  15.2.2.1.  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 needs 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.


  15.2.2.2.  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/>.


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


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


  15.2.5.  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 xterm ones if you use X Window.  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.


  15.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.  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 termcap 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 company went out of business, etc.



  15.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).


  15.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: "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).


  15.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/tty...) (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 "tset" (see the manual page).  tset 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 tset
  sends the init string and sets TERM to this terminal name (type).


  15.7.  Terminfo/Termcap Documents



  ·  manual pages for terminfo(5) (best) and/or termcap(5).  The Termcap
     Manual <http://www.delorie.com/gnu/docs/termcap/termcap_toc.html>
     (2nd ed.) by Richard M. Stallman is a GNU manual which is somewhat
     obsolete since it doesn't include terminfo.

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


  16.  Using the Terminal

  16.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)


  16.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''.

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


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


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


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


  16.5.  Bugs in Bash

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

  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-d4.  -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 D1-D3).  Many other application send this
  without needing to be told to do so.


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


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


  16.8.  Corrupted Terminal Interface

  This includes the case of a "frozen display" = "hung terminal" of the
  previous section.


  16.8.1.  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''


  16.8.2.  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" (may
  be broken) or "setterm -reset" (followed by a <return> of course).
  You may not be able to see what you're typing.  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 "tset" to send
  the init string if you use it to set up your terminal.


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


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


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


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


  16.9.1.  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 ??


  16.9.2.  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.).


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


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


  16.10.  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 ??


  16.11.  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".


  16.12.  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)


  16.13.  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" of "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



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


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


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


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


  16.14.  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
  <http://www.facetcorp.com/facetterm-overview.html>


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


  16.16.  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" 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>.


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


  16.18.  Browsers for Terminals

  The "lynx" browser works correctly with all text terminals.  There are
  two other text browsers: "w3m" and "links" that only work with the
  Linux console, xterm, or vt100 terminals.  The "netrik" browser
  requires a color terminal.  For "links", you must set your terminal to
  8-bits with no parity.  All (including netrik ??) support ssl (secure
  socket layer) for encoded communication.

  "w3m" and "links" overcome some of the "lynx" deficiencies.  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" and "links" don't have numbered links like lynx
  does, nor do they have good support for cookies.  None of the text
  browsers as yet have good support for Javascript, but some are
  allegedly working on it (as of 2003).  Links and netrik currently have
  only partial support for Javascript.

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


  17.  Special Uses for a Terminal

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


  17.1.1.  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).


  17.1.2.  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=".


  17.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''


  17.3.  Use a Keyboardless Terminal as the Monitor

  17.3.1.  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 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).


  17.3.2.  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 $@



  18.  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''

  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.


  18.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''.


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


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


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


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


  18.6.  ... respawning too fast: disabled for 5 minutes

  18.6.1.  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 respawns over and over.  But the operating system
  intervenes and stops this nonsense (for 5 minutes).  The following
  sections show possible causes and fixes.


  18.6.2.  Getty line in /etc/inittab file incorrect

  Make sure the 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.
  18.6.3.  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 ps_getty).

  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.


  18.6.4.  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".


  18.6.5.  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.)


  18.6.6.  Key shorted

  Another possible cause of getty respawning too rapidly is if a
  keyboard key is shorted.  This gives the same result as if the key was
  continuously held down.  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).


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


  18.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 (at the console) try "stty < /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.

  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''


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


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


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


  18.10.2.  More diagnose

  The above should solve most cases (unless you've just installed a
  terminal).  Other causes include defective hardware or cables (must be
  null-modem), 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''


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


  18.10.4.  Measure voltages

  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 null-modem
  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 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 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.

  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 -12 V 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.


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


  18.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).


  18.12.1.  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).


  18.12.2.  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''.


  18.13.  Slow: pauses of several seconds between bursts of characters

  You likely have mis-set interrupts>  See the Serial-HOWTO section
  starting with "Slow:"


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


  18.15.  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)

  ·  serialmon (doesn't monitor RTS, CTS, DSR but logs other functions)

  ·  modemstat (only works on Linux PC consoles.  Will coexist with the
     command line)

     You may already have them.  If not, go to Serial Software
     <http://ibiblio.unc.edu/pub/Linux/system/serial/>.  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.


  18.16.  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''.


  18.17.  Serial Electrical Test Equipment

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


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


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



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


  19.1.  Repair Books & Websites

  19.1.1.  Books

  Bigelow, Stephen J.: Troubleshooting & Repairing Computer Monitors,
  2nd edition, McGraw-Hill, 1997.  Doesn't cover the character
  generation electronics nor the keyboard.


  19.1.2.  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).  Shuford's
  repair archive
  <http://www.cs.utk.edu/~shuford/terminal/repair_hints_news.txt> of
  newsgroup postings on terminal repair is another source of info.


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


  19.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).


  19.4.  Diagnose

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


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


  19.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 minicom.  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.


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


  19.6.1.  Keyboard Error

  This usually means that the keyboard is not plugged in, or that the
  connection is loose.  For more serious problems see ``Keyboards''


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


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


  19.8.  Keyboards



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


  19.8.2.  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".


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


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


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



  19.8.6.  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''


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


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


  19.8.7.2.  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''.


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


  19.8.9.  Cleaning keyboard contacts

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


  19.8.9.2.  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 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 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 buy the
  switch).

  Directly spraying contact cleaner into the top of the key switch 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 digit row 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.  I don't usually do this.  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 need 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 to 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 get contact cleaner on the contacts by squirting a
  little cleaned on an edge where it can penetrate into the contacts as
  you work the contacts open and closed with a screwdriver.

  If the above doesn't work.  Slightly prying apart the conducting
  surfaces while applying cleaner might help.  There may be some kind of
  clip holding the contact surfaces together which needs to be removed
  before prying.  With cleaner on the contacts, work them.  Tilting the
  keyboard or inverting it may help.  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, working on the keyboard when
  it's standing on end (or upside-down) will keep the spring from
  falling out during assembly.


  20.  Appendix A: General

  20.1.  List of Linux Terminal Commands

  20.1.1.  Sending a command to the terminal


  ·  ``setterm'': long options


  ·  ``tput'': terse options

  ·  tset: initializes only

  ·  clear: clears screen

  ·  setterm -reset: sends reset string


  20.1.2.  Configuring the terminal device driver


  ·  ``Setserial'':

  ·  ``Stty''


  20.1.3.  Terminfo


  ·  ``Terminfo Compiler (tic)'' terminfo compiler & translator

  ·  toe: shows list of terminals for which you have terminfo files

  ·  ``infocmp'' compares or displays terminfo entries


  20.1.4.  Other


  ·  gitkeys: shows what bytes each key sends to the host.

  ·  tty: shows what tty port you are connected to.

  ·  set (or tset -q): shows the value of TERM, the terminfo entry name

  ·  ``tset'': sets TERM interactively and initializes


  20.2.  The Internet and Books

  20.2.1.  Terminal Info on the Internet



  ·  Shuford's Website
     <http://www.cs.utk.edu/~shuford/terminal_index.html> at the
     University of Tennessee has a great deal of useful information
     about text terminals.

  ·  VT terminal information and history  <http://www.vt100.net/>

  ·  Boundless <http://www.boundless.com/Text_Terminals/> purchased the
     VT and Dorio terminal business from DEC.  To get Specs select
     either ADDS, VT, or DORIO links.  Then select a "data sheet" link.
     Then on the data sheet select the "Go to Specs" link.

  ·  Wyse has 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.  Wyse text-terminals database
     <http://www.wyse.com/service/support/kbase/wyseterm.asp>  For
     current models see Wyse  terminals
     <http://www.wyse.com/products/gpt/index.htm>.

  ·  Teemworld Escape Sequences <http://www.ecc400.com/java/twproae.htm>
     is a list of escape sequences (and control codes) for some terminal
     emulations (including VT 100, 300, 420, and Wyse).

  ·  ncurses FAQ <http://dickey.his.com/ncurses/ncurses.faq.html>

  ·  comp.terminals is the newsgroup for terminals


  20.2.2.  Books related to terminals



  ·  EIA-232 serial port see ``EIA-232 (RS-232) Books''.

  ·  Repair see ``Repair Books &  Websites''.

  ·  Terminfo database see ``Termcap Documents''


  20.2.3.  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 month 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.


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


  20.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 unix-like systems.


  ·  SCO's OpenServer Adding Serial Terminals
     <http://osr5doc.ca.caldera.com:457/HANDBOOK/CONTENTS.html> in SCO
     OpenServer Handbook.

  ·  Hewlett-Packard's HP-UX "Configuring Terminals and Modems" (Url to
     it is dead.)


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


  21.1.  Esc Sequence List

  For a list of many (but not all) escape sequences for various
  terminals see Teemworld Escape Sequences
  <http://www.ecc400.com/java/twproae.htm>.  These are used for terminal
  emulation and are not always the same as on the corresponding real
  terminal.  A list for VT (not maintained) may be found at Emulators
  FAQ <http://www.cs.ruu.nl/wais/html/na-dir/emulators-faq/part3.html>.
  Search for "VT".  For downloading manuals see VT Manuals
  <http://www.vt100.net/>.


  21.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 \



  21.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).


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


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


  21.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).


  22.

  Appendix C: Serial Communications on EIA-232 (RS-232)

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


  22.2.  Voltages

  22.2.1.  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
  (some are 5 or 10 volts).   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 sees
  erroneous claims that the voltage is commonly 5 volts (or even 3
  volts) but it's usually 11-12 volts.  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 is 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 the 12 volts of
  a serial port, it may damage the test equipment.


  22.2.2.  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).


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


  22.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).


  22.5.  Limitations of EIA-232

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


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


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


  22.6.  Synchronization & Synchronous

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



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


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


  22.7.  Block Mode

  22.7.1.  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'').


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


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


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


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


  22.9.  Serial Software

  See Serial Software <ftp://ibiblio.unc.edu/pub/Linux/system/serial/>
  for Linux software for the serial ports including getty and port
  monitors.


  23.  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 which only
  need be written about in one place.  It would be nice if for each
  terminal model, there were a set of links linking to 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 has put the information from
  its manuals on the Internet.  See ``Wyse Terminals''.


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


  23.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 makes CItoh printers (in 1997) but has no parts for its
  abandoned terminals.  Ernie at (714) 453-9555 in Irvine CA sells (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.



  23.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''.


  23.3.1.  IBM 3153

  It's claimed that the Aux port is DCE and uses a straight-thru cable.


  23.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").


  23.5.  VT (DEC)

  Digital Equipment Corporation made the famous VT series of terminals
  including the commonly emulated VT100.  In 1995 they sold their
  terminal business to SunRiver which is now named Boundless
  Technologies.  Detailed VT terminal information, some manuals, and
  history is at  <http://www.vt100.net/>.  Other information is
  available at Shuford's Website
  <http://www.cs.utk.edu/~shuford/terminal_index.html>.  Information on
  current products is available from the Boundless website.  See
  ``Terminal Info on the Internet''.
  VT220: Some have a BNC connector for video output (not for input).
  Sometimes people erroneously think this is for an ethernet connection.

  VT520: Supports full DTR/DSR flow control.

  Dorio: Can emulate many other terminals.  The "sco unix console" is
  claimed to be a powerful emulation using the "scoansi" terminfo.


  23.6.  Links

  The terminal maker Links was taken over by Wyse.


  23.7.  Qume

  Qume was taken over by Wyse in the early 1990s.


  23.8.  Wyse Terminals

  For 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.  For the
  specs on more recent terminals see See Wyse terminals
  <http://www.wyse.com/products/gpt/index.htm>.

  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 is due in part to the large number of Wyse terminals
  in use.


  23.8.1.  Wyse 50

  Reported not to last very long.


  23.8.2.  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 0xd1 - 0xd4.
  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''


  23.8.3.  Wyse 85

  Can emulate VT52/VT100/VT200.  Press F3 for setup.  After moving
  left/right to go the 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).


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



  23.8.5.  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).

  END OF Text-Terminal-HOWTO



