9007 lines
419 KiB
Plaintext
9007 lines
419 KiB
Plaintext
Text-Terminal-HOWTO
|
|
David S. Lawyer <mailto:dave@lafn.org>
|
|
v1.43 March 2013
|
|
|
|
This document was originally written for real text terminals which
|
|
were like monitors (with keyboards), but could only display text with
|
|
a command line interface (no pictures). They were widely used to
|
|
access mainframe computers in the late 1970's and 1980's but use of
|
|
them declined in the 1990's and they are seldom used anymore. However
|
|
much of this howto also applies to command-line interfaces on Linux
|
|
PC's which are in wide use today. It's not about the user programs
|
|
one might run on the command line, but about setting up, managing, and
|
|
understanding the interface itself Such as using a monitor as a vir-
|
|
tual (text-only) console, using a text-window in a GUI such as xterm,
|
|
connecting to a remote computer over a network via ssh, telnet, etc.,
|
|
or even using software on another PC to turn it into a serial-port
|
|
text-terminal. All these 4 methods are known as "text-terminal emula-
|
|
tion". But unfortunately, the main emphasis in this howto is real
|
|
text terminals and the coverage of emulation is inadequate for the
|
|
first 3 methods of emulation mentioned above. The Keyboard-and-Con-
|
|
sole-HOWTO filled much this gap but it was written for Linux 2.0 and
|
|
now needs rewriting (or merging into this Text-Terminal howto). A new
|
|
author is needed that has time to do all this. For the seldom used
|
|
real text-terminals, it explains how they work, explains how to
|
|
install and configure them, and provides some info on how to repair
|
|
them. This HOWTO also provides a brief overview of modern GUI termi-
|
|
nals.
|
|
______________________________________________________________________
|
|
|
|
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 Related HOWTOs
|
|
1.5 Terminology Used in this Document
|
|
1.6 What is a Terminal ?
|
|
1.7 Real Text Terminals
|
|
|
|
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
|
|
|
|
3. Thin Clients Terminals
|
|
3.1 Introduction
|
|
3.2 MS Window terminals
|
|
3.3 Network computers (NC's)
|
|
3.4 Thin clients and NCs under Linux
|
|
3.5 Hardware hookups
|
|
3.6 History and the future
|
|
|
|
4. Quick Text-Terminal Install
|
|
5. Why Use a Terminal ?
|
|
5.1 Intro to Why Use a Terminal
|
|
5.2 Lower Hardware Costs ?
|
|
5.3 Control of Software
|
|
5.4 Hardware Upgrades
|
|
5.5 Other Advantages of Terminals
|
|
5.6 Major Disadvantages of Text Terminals
|
|
5.7 Major Disadvantages of All Terminals
|
|
5.8 Are Text Terminals Obsolete ?
|
|
|
|
6. Overview of How Text Terminals Work (in Linux)
|
|
6.1 Device Names
|
|
6.2 Login/Logout
|
|
6.3 Half/Full Duplex
|
|
6.4 Terminal Memory
|
|
6.5 Commands for the Terminal
|
|
6.6 Lack of Standardization Solved by Terminfo
|
|
6.7 The Interface
|
|
6.8 Emulation
|
|
6.9 The Console
|
|
|
|
7. Terminal Special Files such as /dev/tty
|
|
7.1 Serial Port Terminals
|
|
7.2 Pseudo Terminals
|
|
7.3 The Controlling Terminal /dev/tty
|
|
7.4 /dev/ttyIN "Terminals"
|
|
7.5 The Console: ttyN or vc/N
|
|
7.6 Creating a Device with "mknod"
|
|
|
|
8. Some Details on How Terminals Work
|
|
8.1 Terminal Memory Details
|
|
8.2 Early Terminals
|
|
8.3 Escape Sequences and Control Codes (intro)
|
|
8.3.1 Control codes
|
|
8.3.2 Escape sequences
|
|
8.4 Display Attributes & Magic Cookies
|
|
|
|
9. Special Features/Types of Some Terminals
|
|
9.1 Terminal Uses a PC Monitor
|
|
9.2 Color
|
|
9.2.1 Emulated text terminals
|
|
9.2.2 Old real text terminal
|
|
9.3 Multiple Sessions
|
|
9.4 Printer/Auxiliary Port
|
|
9.5 Pages
|
|
9.6 Character-Sets
|
|
9.6.1 Graphics (Line Drawing, etc.)
|
|
9.6.2 National Replacement Characters (obsolete)
|
|
9.7 Fonts
|
|
9.8 Keyboards & Special Keys
|
|
9.9 Mouse
|
|
|
|
10. Terminal Emulation (including the Console)
|
|
10.1 Intro to Terminal Emulation
|
|
10.2 Don't Try to Use TERM Variable for Emulation
|
|
10.3 Serial Communication programs
|
|
10.3.1 Emulation under X Window
|
|
10.3.2 Real terminals once were better
|
|
10.4 Testing Terminal Emulation
|
|
10.5 The Linux Console
|
|
10.6 Emulation Software
|
|
10.6.1 Make a Linux PC a serial port terminal
|
|
10.6.2 Make a Linux PC an IBM network terminal
|
|
10.6.3 Make a non-Linux PC a terminal
|
|
10.7 Colors on Emulated Terminals
|
|
|
|
11. Flow Control (Handshaking)
|
|
11.1 Why Is Flow Control Needed ?
|
|
11.2 Padding
|
|
11.3 Overrunning a Serial Port
|
|
11.4 Stop Sending
|
|
11.5 Keyboard Lock
|
|
11.6 Resume Sending
|
|
11.7 Hardware Flow Control (RTS/CTS etc.)
|
|
11.7.1 RTS/CTS, DTR, and DTR/DSR Flow Control
|
|
11.7.2 Connecting up DTR or DTR/DSR Flow Control
|
|
11.7.3 Old RTS/CTS handshaking is different
|
|
11.7.4 Reverse Channel
|
|
11.8 Is Hardware Flow Control Done by Hardware ?
|
|
11.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control
|
|
|
|
12. Physical Connection
|
|
12.1 Introduction
|
|
12.2 Multiport I/O Cards (Adapters)
|
|
12.3 Direct Serial Cable Connection.
|
|
12.3.1 Pin numbering
|
|
12.3.2 Null Modem cable pin-out (3, 4, or 5 conductor)
|
|
12.3.3 Standard Null Modem cable pin-out (7 conductor)
|
|
12.3.4 Overcoming length limitations
|
|
12.3.5 Hardware Flow Control cables
|
|
12.3.6 Cable tips
|
|
12.3.7 A kludge using twisted-pair cable
|
|
12.3.8 Cable grounding
|
|
12.4 Modem Connection
|
|
12.4.1 Dialing out from a terminal
|
|
12.4.2 Terminal gets dialed into
|
|
12.5 Telnet and ssh
|
|
12.6 Terminal Server Connection
|
|
12.6.1 What is a terminal server ?
|
|
12.6.2 Evolution of the "terminal server"
|
|
12.7 Connector and Adapter Types
|
|
12.7.1 Sex of connector/adapters
|
|
12.7.2 Types of adapters
|
|
12.7.3 DB connectors
|
|
12.7.4 RJ modular connectors
|
|
12.7.4.1 6-conductors: RJ11/14, RJ12, and MMJ
|
|
12.7.4.2 8-conductors and 10-conductors
|
|
12.8 Making or Modifying a Cable
|
|
12.8.1 Buy or make ?
|
|
12.8.2 Pin numbers of 9 and 25 pin connectors
|
|
12.8.3 Installing DB connectors on cable ends
|
|
12.8.4 Installing RJ connectors
|
|
|
|
13. Set-Up (Configure) in General
|
|
13.1 Intro to Set-Up
|
|
13.2 Terminal Set-Up (Configure) Overview
|
|
13.3 Computer Set-Up (Configure) Overview
|
|
13.4 Many Options
|
|
13.5 Communication Interface Options
|
|
13.5.1 Speed
|
|
13.5.2 Parity & should you use it ?
|
|
13.5.3 Bits/Character
|
|
13.5.4 Which Flow Control (Handshaking) ?
|
|
13.5.5 Port select
|
|
13.6 Quick Attempt
|
|
|
|
14. Terminal Set-Up (Configure) Details
|
|
14.1 Send Escape Sequences to the Terminal
|
|
14.2 Older Terminals Set-Up
|
|
14.3 Getting Into Set-Up (Configuration) Mode
|
|
14.4 Communication Options
|
|
14.5 Saving the Set-up
|
|
14.6 Set-Up Options/Parameters
|
|
14.7 Emulation {Personality} {{Terminal Modes}}
|
|
14.8 Display Options
|
|
14.8.1 Character Cell Size {Char Cell}
|
|
14.8.2 Columns/Lines
|
|
14.8.3 Cursor
|
|
14.8.4 Display Attributes (Magic Cookies)
|
|
14.8.5 Display Control Characters {Monitor}
|
|
14.8.6 Double Width/Height
|
|
14.8.7 Reverse Video {Display} (Background Light/Dark)
|
|
14.8.8 Status Line
|
|
14.8.9 Upon 80/132 Change: Clear or Preserve?
|
|
14.9 Page Related Options
|
|
14.9.1 Page Size
|
|
14.9.2 Coupling (of cursor & display)
|
|
14.10 Reporting and Answerback
|
|
14.10.1 Answerback Message (String)
|
|
14.10.2 Auto Answerback
|
|
14.10.3 Answerback Concealed
|
|
14.10.4 Terminal ID {ANSI ID}
|
|
14.11 Keyboard Options
|
|
14.11.1 Keyclick
|
|
14.11.2 Caps Lock {Keylock}
|
|
14.11.3 Auto Repeat {Repeat}
|
|
14.11.4 Margin Bell
|
|
14.11.5 Remapping the Keys
|
|
14.11.6 Corner Key (for Wyse only)
|
|
14.11.7 Numeric Keypad or Arrow Keys Sends
|
|
14.11.8 What does shifted-del and shifted-bs send?
|
|
14.11.9 PC Scan Codes
|
|
14.11.10 Alternate Characters
|
|
14.12 Meaning of Received Control Codes
|
|
14.12.1 Auto New Line {Newline}
|
|
14.12.2 Auto Line Feed {Rcv CR}
|
|
14.12.3 Recognize Del (Wyse Only ??) or Null
|
|
14.13 Where New Text Goes
|
|
14.13.1 Line Wrap
|
|
14.13.2 Scrolling
|
|
14.13.3 New Page?
|
|
14.14 Function Keys
|
|
14.15 Block Mode Options
|
|
14.15.1 Forms Display
|
|
14.15.2 Send Entire Block ?
|
|
14.15.3 Region to Send
|
|
14.15.4 Block/Page terminator
|
|
14.16 Locks
|
|
14.17 Screen Saver {Scrn Saver}
|
|
14.18 Printer
|
|
|
|
15. Computer Set-Up (Configure) Details
|
|
15.1 Getty (used in /etc/inittab)
|
|
15.1.1 Introduction to Getty
|
|
15.1.2 Getty exits after login (and can respawn)
|
|
15.1.3 If getty run from command line: Programs get stopped
|
|
15.1.4 agetty (may be named getty)
|
|
15.1.4.1 Agetty's auto-detection of parity problems
|
|
15.1.4.2 8-bit data bytes (plus parity)
|
|
15.1.5 getty (part of getty_ps)
|
|
15.1.6 mgetty
|
|
15.2 Stty & Setserial
|
|
15.3 Setserial
|
|
15.3.1 Setserial problems with linmodems, laptops
|
|
15.3.2 Introduction
|
|
15.3.3 Serial module unload
|
|
15.3.4 Giving the setserial command
|
|
15.3.5 Configuration file
|
|
15.3.6 Probing
|
|
15.3.7 Boot-time Configuration
|
|
15.3.8 Edit a script (required prior to version 2.15)
|
|
15.3.9 Configuration method using /etc/serial.conf, etc.
|
|
15.3.10 IRQs
|
|
15.3.11 Laptops: PCMCIA
|
|
15.4 Stty
|
|
15.4.1 Introduction
|
|
15.4.2 Flow control options
|
|
15.4.3 Using stty at a "foreign" terminal
|
|
15.4.4 Two interface modes at a terminal
|
|
15.4.5 Where to put the stty command ?
|
|
15.4.6 Obsolete redirection method
|
|
15.5 Terminfo & Termcap (brief)
|
|
15.6 Setting TERM and TERMINFO
|
|
15.6.1 What is the terminfo name of my terminal ?
|
|
15.7 Rarely Needed /etc/ttytype File
|
|
15.8 Login Restrictions
|
|
15.9 Run Command Only If TERM=my_term_type
|
|
15.9.1 Example for ls Function
|
|
15.10 Character Mapping: mapchan
|
|
|
|
16. Terminfo and Termcap (detailed)
|
|
16.1 Intro to Terminfo
|
|
16.2 Terminfo Database
|
|
16.2.1 Introduction
|
|
16.2.2 Where is the database located ?
|
|
16.2.2.1 Compiled database locations
|
|
16.2.2.2 Source-code database locations
|
|
16.2.3 Terminfo Compiler (tic)
|
|
16.2.4 Look at Your Terminfo
|
|
16.2.5 Deleting Data Not Needed
|
|
16.3 Bugs in Existing Terminfo Files (and Hardware)
|
|
16.4 Modifying Terminfo Files
|
|
16.5 Init String
|
|
16.6 TERM Variable
|
|
16.7 Terminfo/Termcap Documents
|
|
|
|
17. Using the Terminal
|
|
17.1 Intro to Using the Terminal
|
|
17.2 Starting Up the Terminal
|
|
17.3 Terminal (Serial) Device Driver
|
|
17.4 Problems with Editors
|
|
17.4.1 emacs
|
|
17.4.2 vi and Cursor-Keys
|
|
17.5 Problem with Slow Scrolling
|
|
17.6 Bugs in Bash ?
|
|
17.6.1 A fixed Bash bug
|
|
17.7 Color ls Corruption
|
|
17.8 Display Freezes (hung terminal)
|
|
17.9 Corrupted Terminal Interface
|
|
17.9.1 Symptoms and some fixes
|
|
17.9.2 Sent terminal binary characters
|
|
17.9.3 Reset command was broken but now fixed
|
|
17.9.4 Character corruption
|
|
17.9.5 Abnormally exited a program
|
|
17.10 Special (Control) Characters
|
|
17.10.1 Command-Line Editing
|
|
17.10.2 Interrupting (& Quit, Suspend, EOF, Flush)
|
|
17.10.3 Stop/Start Scrolling
|
|
17.10.4 Take next character literally
|
|
17.11 Viewing Latin1 Files on a non-Latin1 terminal
|
|
17.12 Eliminating Overstriking in Files
|
|
17.13 Inspecting the Interface
|
|
17.14 Changing the Terminal Settings
|
|
17.14.1 setterm
|
|
17.14.2 tput
|
|
17.14.3 echo
|
|
17.14.4 Saving changes
|
|
17.15 Multiple Sessions
|
|
17.16 Logging Out
|
|
17.17 Chatting between Terminals, Spying
|
|
17.18 Sharing the Serial Port
|
|
17.19 Browsers for Text-Terminals
|
|
|
|
18. Special Uses for a Terminal
|
|
18.1 Make a Serial Terminal the Console
|
|
18.1.1 For Kernels 2.2 or higher
|
|
18.1.2 Serial-Console For Kernels before 2.2
|
|
18.2 Run Linux without a Monitor
|
|
18.3 Use a Keyboardless Terminal as the Monitor
|
|
18.3.1 How it works
|
|
18.3.2 Example configuration
|
|
|
|
19. Trouble-Shooting
|
|
19.1 Terminal Was Working OK
|
|
19.2 Terminal Newly Installed
|
|
19.3 Is the Terminal OK ?
|
|
19.4 Missing Text
|
|
19.5 All Keys Work Erratically; Must Hit a Key a Few Times
|
|
19.6 ... respawning too fast: disabled for 5 minutes
|
|
19.6.1 What's happening
|
|
19.6.2 Getty line in /etc/inittab file incorrect
|
|
19.6.3 No modem control signal
|
|
19.6.4 No such serial device
|
|
19.6.5 No serial support
|
|
19.6.6 Key shorted
|
|
19.7 Fails Just After Login
|
|
19.8 Can't Login
|
|
19.9 Garbled Login Prompt
|
|
19.10 No Login Prompt
|
|
19.10.1 Terminal was working OK
|
|
19.10.2 More diagnose
|
|
19.10.3 Diagnose problem from the console
|
|
19.10.4 Measure voltages
|
|
19.11 Displays Foreign/Weird Characters/Symbols
|
|
19.12 Displays Escape Sequences
|
|
19.12.1 Telnet
|
|
19.12.2 Terminal set to display escape sequences
|
|
19.13 Slow: pauses of several seconds between bursts of characters
|
|
19.14 Cursor Jumps
|
|
19.15 Terminal doesn't scroll
|
|
19.16 Serial Monitoring/Diagnostics
|
|
19.17 Local Mode
|
|
19.18 Serial Electrical Test Equipment
|
|
19.18.1 Breakout Gadgets, etc.
|
|
19.18.2 Measuring voltages
|
|
19.18.3 Taste voltage
|
|
|
|
20. Repair & Diagnose
|
|
20.1 Repair Books & Websites
|
|
20.1.1 Books
|
|
20.1.2 Websites
|
|
20.2 Safety
|
|
20.3 Appearance of Display
|
|
20.4 Diagnose
|
|
20.4.1 Terminal Made a Noise or Smoked
|
|
20.4.2 Terminal Made No Noise
|
|
20.5 Detective work
|
|
20.6 Error Messages on the Screen
|
|
20.6.1 Keyboard Error
|
|
20.6.2 Checksum Error in NVR
|
|
20.7 Capacitors
|
|
20.8 Keyboards
|
|
20.8.1 Interchangeability
|
|
20.8.2 How They Work
|
|
20.8.3 Modern vs Old Keyboards
|
|
20.8.4 One Press Types 2 Different Characters
|
|
20.8.5 Keyboard doesn't work at all
|
|
20.8.6 Typing b displays bb, etc. (doubled)
|
|
20.8.7 Row upon row of the same character appears
|
|
20.8.7.1 Key sticks in down position (individual switches)
|
|
20.8.7.2 Key electrically shorted
|
|
20.8.8 Liquid spilled on the keyboard
|
|
20.8.9 Cleaning keyboard contacts
|
|
20.8.9.1 Keyboards with membranes
|
|
20.8.9.2 Keyboards with individual switches
|
|
|
|
21. Appendix A: General
|
|
21.1 List of Linux Terminal Commands
|
|
21.1.1 Sending a command to the terminal
|
|
21.1.2 Configuring the terminal device driver
|
|
21.1.3 Terminfo
|
|
21.1.4 Other
|
|
21.2 The Internet and Books
|
|
21.2.1 Terminal Info on the Internet
|
|
21.2.2 Books related to terminals
|
|
21.2.3 Entire books on terminals
|
|
21.2.4 Books with chapters on terminals
|
|
21.3 Non-Linux OSs
|
|
|
|
22. Appendix B: Escape Sequence Commands Terminology
|
|
22.1 Esc Sequence Lists
|
|
22.2 8-bit Control Codes
|
|
22.3 Printer Esc
|
|
22.4 Reports
|
|
22.5 Cursor Movements
|
|
22.6 Pages (definition)
|
|
|
|
23. Appendix C: Serial Communications on EIA-232 (RS-232)
|
|
23.1 Intro to Serial Communication
|
|
23.2 Voltages
|
|
23.2.1 Voltage for a bit
|
|
23.2.2 Voltage sequence for a byte
|
|
23.3 Parity Explained
|
|
23.4 Forming a Byte (Framing)
|
|
23.5 Limitations of EIA-232
|
|
23.5.1 Low Speed & Short Distance
|
|
23.5.2 Successors to EIA-232
|
|
23.5.3 Line Drivers
|
|
23.6 Synchronization & Synchronous
|
|
23.6.1 How "Asynchronous" is Synchronized
|
|
23.6.2 Defining Asynchronous vs Synchronous
|
|
23.6.3 Synchronous Communication
|
|
23.7 Block Mode
|
|
23.7.1 Introduction to Block Mode
|
|
23.7.2 Types of Block Modes, Forms
|
|
23.7.3 Efficiency
|
|
23.7.4 Problems with block mode
|
|
23.8 EIA-232 (RS-232) Books
|
|
23.9 Serial Software
|
|
|
|
24. Appendix D: Notes by Brand/Model
|
|
24.1 Adds
|
|
24.2 CIT
|
|
24.3 IBM Terminals
|
|
24.3.1 IBM 3153
|
|
24.4 Teletypes
|
|
24.5 VT (originally DEC, now Boundless)
|
|
24.6 Links
|
|
24.7 Qume
|
|
24.8 Wyse Terminals
|
|
24.8.1 Wyse 50
|
|
24.8.2 Wyse 60
|
|
24.8.3 Wyse 85
|
|
24.8.4 Wyse 99-GT
|
|
24.8.5 Wyse 150
|
|
24.8.6 Wyse 185
|
|
24.8.7 Low Emissions: -ES
|
|
|
|
|
|
______________________________________________________________________
|
|
|
|
1. Introduction
|
|
|
|
For a quick attempt to install a text-terminal see ``Quick Install''.
|
|
|
|
|
|
1.1. Copyright, Trademarks, Disclaimer, & Credits
|
|
|
|
1.1.1. Copyright
|
|
|
|
Copyright 1998-2010 by David S. Lawyer. <mailto:dave@lafn.org>
|
|
|
|
Please freely copy and distribute (sell or give away) this document in
|
|
any format. Send any corrections and comments to the document
|
|
maintainer. You may create a derivative work and distribute it
|
|
provided that you:
|
|
|
|
|
|
1. If it's not a translation: Email a copy of your derivative work (in
|
|
a format LDP accepts) to the author(s) and maintainer (could be the
|
|
same person). If you don't get a response then email the LDP
|
|
(Linux Documentation Project): submit@en.tldp.org.
|
|
|
|
|
|
2. License the derivative work in the spirit of this license or use
|
|
GPL. Include a copyright notice and at least a pointer to the
|
|
license used.
|
|
|
|
3. Give due credit to previous authors and major contributors.
|
|
|
|
If you're considering making a derived work other than a translation,
|
|
it's requested that you discuss your plans with the current
|
|
maintainer.
|
|
|
|
|
|
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
|
|
|
|
|
|
Greg Hankin's Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A
|
|
Terminal Connected To My PC?" was incorporated into v1.00 at various
|
|
places (with Greg's permission). v1.09 of Text-Terminal-HOWTO had
|
|
about 25 changes (and error corrections) suggested by Alessandro
|
|
Rubini. For v1.26 I fixed about 25 typos, etc. found by Alain
|
|
Cochard. Jeremy Spykerman told me about using a keyboardless terminal
|
|
as a console for a monitorless PC (using ttysnoop). Numerous other
|
|
people have made a suggestion or two or found a few typos. Thanks.
|
|
|
|
|
|
1.2. Future Plans: You Can Help
|
|
|
|
The author is looking for someone to take over maintaining this howto.
|
|
Since real text terminals are pretty much obsolete, there is not a lot
|
|
of work to do except that links sometimes disappear and automatically
|
|
finding devices such a dumb terminals on a serial port may not work
|
|
right. One project is to rewrite this howto oriented towards text-
|
|
terminal emulation with the command line interface. Another project
|
|
would be to start with the brief overview of GUI terminals in this
|
|
HOWTO and create a new and up-to-date HOWTO on thin clients or the
|
|
like.
|
|
|
|
Please let me know of any errors in facts, opinions, logic, spelling,
|
|
grammar, clarity, links, etc. But first, if the date is over a couple
|
|
of years old, check to see that you have the latest version. Please
|
|
send me any info that you think belongs in this document.
|
|
|
|
In order to fully utilize all the features of a certain real terminal,
|
|
one needs the terminal manuals that came with the terminal when it was
|
|
new. If you don't have a manual, this HOWTO may be of some help. One
|
|
way to have solved this problem would be for terminal manufacturers to
|
|
put their manuals on the Internet but they never did. Except that
|
|
Wyse made available some of their user manuals and someone scanned old
|
|
VT-100 manuals.
|
|
|
|
|
|
1.3. New Versions of this HOWTO
|
|
|
|
New versions of the Text-Terminal-HOWTO should be released every
|
|
couple of years. To get the latest version go to an LDP mirror sites
|
|
(see: <http://www.tldp.org/mirrors.html>). To quickly check the date
|
|
of the latest version look at Text-Terminal-HOWTO.html
|
|
<http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-
|
|
formats/html_single/Text-Terminal-HOWTO.html>. The version your are
|
|
currently reading is: v1.43 March 2013 .
|
|
|
|
For a full revision history going back to the first version in 1998
|
|
see the source file (in linuxdoc format):(cvs) Text-Terminal-
|
|
HOWTO.sgml <http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/Text-
|
|
Terminal-HOWTO.sgml?view=markup>
|
|
|
|
|
|
· v1.43 Mar. 2013 Putty's pterm emulation. Cleanup. Shuford's
|
|
website now defunct. Looking for a new maintainer. Wyse data
|
|
missing from Internet. Rewrote abstract. Clarity in stty raw
|
|
problem. Links to Wikipedia.
|
|
|
|
· v1.42 Jan. 2010 PuTTY serial terminal emulator, cutecom (dumb
|
|
emulator), colors, links to wikipedia, Boundless still selling
|
|
terminals, small footprint terminals, link to art. on text
|
|
browsers.
|
|
|
|
|
|
1.4. Related HOWTOs
|
|
|
|
Go to the nearest mirror site (per above) to get HOWTOs.
|
|
|
|
· Serial-HOWTO has info on Multiport Serial Cards used for both
|
|
terminals and banks of modems. It has general technical info on
|
|
the serial port including troubleshooting it.
|
|
|
|
· NCURSES-Programming-HOWTO
|
|
|
|
· MacTerminal mini-HOWTO
|
|
|
|
· Modem-HOWTO
|
|
|
|
· Serial-Programming-HOWTO
|
|
|
|
· NC mini-HOWTO
|
|
|
|
· NCD-X-Terminal mini-HOWTO
|
|
|
|
· XDM-and-X-Terminal mini-HOWTO
|
|
|
|
· Connecting-X-Terminals-to-Linux-Mini-HOWTO
|
|
|
|
· NCD-HOWTO
|
|
|
|
· Thinclient-HOWTO
|
|
|
|
· Xterminals-HOWTO
|
|
|
|
· Xterm-Title-HOWTO (only for changing the title of a window)
|
|
|
|
|
|
1.5. Terminology Used in this Document
|
|
|
|
Configuration means the same as set-up. While Linux commands take
|
|
options (using - or -- symbols), options in a broader sense include
|
|
various other types of choices. Install in the broad sense includes
|
|
setting up (configuring) software and hardware. A statement that I
|
|
suspect is true (but may not be) ends with 2 question marks: ?? If
|
|
you know for sure, let me know.
|
|
|
|
|
|
1.6. What is a Terminal ?
|
|
|
|
A terminal consists of a screen and keyboard that one uses to
|
|
communicate remotely with a computer (the host). One uses it almost
|
|
like it was a personal computer but the terminal is remote from its
|
|
host computer that it communicates with (on the other side of the room
|
|
or even on the other side of the world). Programs execute on the host
|
|
computer but the results display on the terminal screen. Originally
|
|
terminals were stand-alone devices with no computational ability and
|
|
thus they were once much cheaper in cost than computers. They had no
|
|
pictures or audio, but could only display text and were thus called
|
|
"text terminals". Today, the cost of PC computers is so low that one
|
|
may use a PC like a text terminal by running a software program to
|
|
make it behave like an old text terminal. You formerly found real
|
|
text terminals at libraries and schools.
|
|
|
|
|
|
1.7. Real Text Terminals
|
|
|
|
In the olden days of mainframes, from the mid 1970's to the mid
|
|
1980's, most communication with large computers was done by people
|
|
sitting in front of real text-terminals. And in the 1970's, before
|
|
the advent of personal computers, it was the only way to interactively
|
|
communicate with any computer. These real text-terminals were neither
|
|
computers nor emulated text-terminals. They consisted only of a
|
|
screen, keyboard, and only enough memory to store a screenfull or so
|
|
of text (a few kilobytes). Users typed in programs, ran programs,
|
|
wrote documents, issued printing commands, etc. A cable connected the
|
|
terminal to the computer (often indirectly). It was called a terminal
|
|
since it was located at the terminal end of this cable. Some text-
|
|
terminals were called "graphic" but the resolution was poor, the speed
|
|
slow, and little software was available to support such graphics.
|
|
|
|
Today, real terminals are becoming rarities for most all computer
|
|
users. But there is still some specialized uses for them as point-of-
|
|
sale devices and for access to mainframes and servers where graphics
|
|
and pictures are not needed. However, if a text terminal is needed
|
|
people will sometimes use a personal computer to emulate a terminal.
|
|
|
|
Almost everyone who uses Linux also uses terminal emulation. When you
|
|
are not using an X Window GUI at a Linux PC, you are likely using a
|
|
text interface (virtual terminal). It's also called a "command line
|
|
interface". In X Window one can also get a command line interface
|
|
using one or more terminal windows by using an x-terminal-emulator
|
|
with names such as xterm, gnome-terminal, or konsole (KDE). All these
|
|
use software to emulate a real terminal. However in these cases, one
|
|
doesn't need most of the information provided by this HOWTO since such
|
|
emulation is automatically set up for the user. However if one
|
|
emulates a terminal using a software program and then connects that
|
|
emulated terminal to another computer via a serial port cable, then
|
|
this HOWTO should be more useful (provided your PC has a serial port
|
|
on it --almost all recent PCs made after 2009 didn't have them
|
|
anymore).
|
|
|
|
A real text-terminal is different from a monitor or x-terminal-
|
|
emulator because the simple character images that get displayed on the
|
|
text-terminal are stored right inside the terminal in it's memory.
|
|
For a monitor or x-terminal-emulator, the images are stored in the
|
|
video card of the PC and/or in the PC's memory itself. The text-
|
|
terminal's keyboard plugs into the terminal and is part of the
|
|
terminal while a PC's keyboard plugs into the computer.
|
|
|
|
For a monitor, the video images are sent by a short cable running from
|
|
the video card to the monitor while for a text-terminal there is a bi-
|
|
directional flow of character bytes in a long cable between the
|
|
computer's serial port and the PC it's connected to. Most text
|
|
terminals do not have mice.
|
|
|
|
In network client-server terminology, one might think that a real
|
|
terminal is the client and that the host computer is the server. The
|
|
terminal has been called a "thin client" by some. But it is not
|
|
actually a "client" nor is the host a "server". The only "service"
|
|
the host provides is to receive every letter typed at the keyboard and
|
|
react to this just like a computer would if you typed at its own
|
|
keyboard. The terminal is like a "window" into the computer just like
|
|
a monitor (and keyboard) are. You may have already used virtual
|
|
terminals in Linux (by pressing Left Alt-F2, etc.). A real terminal
|
|
is just like running such a virtual terminal but you run it on its own
|
|
terminal screen instead of having to share the monitor screen. In
|
|
contrast to using a virtual terminal at the console (monitor), this
|
|
allows another person to sit at another real terminal and use the same
|
|
computer simultaneously with others. Such multi-user interfaces are
|
|
not "clients" and a server..
|
|
|
|
|
|
2. Types of Terminals
|
|
|
|
2.1. Dumb Terminals
|
|
|
|
There are various conflicting definitions of "dumb terminal" but as
|
|
time goes by, more and more terminals are called dumb. This document
|
|
mainly covers text terminals which display only text on the screen.
|
|
It could have been titled "Dumb-Terminal-HOWTO". But in some
|
|
magazines articles, any terminal, no matter how smart, including ones
|
|
which present a full graphical user interface (GUI), are called dumb.
|
|
If all terminals are "dumb" then there is no point of prefixing the
|
|
word "dumb" to terminal (except as a sales pitch to sell computers or
|
|
the like instead of terminals). Due to the ambiguous meaning of "dumb
|
|
terminal" it is not classified here as a type of terminal.
|
|
|
|
|
|
2.2. Text Terminals
|
|
|
|
For a text terminal, a 2-way flow of information between the computer
|
|
and the terminal takes place over the cable that connects them
|
|
together. This flow is in bytes (such as ASCII) where each byte is an
|
|
integer that usually represents a printable character. Bytes typed at
|
|
the keyboard go to the host computer and most bytes from the computer
|
|
are displayed on the terminal screen. Special control bytes (or
|
|
sequences of bytes) from the computer tell the terminal where to move
|
|
the cursor to, what to erase, where to begin and end underlining
|
|
and/or blinking and/or bold, etc. There are often hundreds of such
|
|
special coded commands and most real terminals can even change fonts.
|
|
|
|
The communication uses characters (letters) encoded using a code chart
|
|
for the character set being used. Usually, the first 128 bytes out of
|
|
256 possible bytes use ASCII codes. Terminals for Unix-like systems,
|
|
normally connect to computers via a cable running between the
|
|
asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer
|
|
and the terminal. Prior to about 2004, most new PCs had serial ports,
|
|
but today (2009) almost no new PCs come with serial ports. Sometimes
|
|
the connection is via modem or terminal server, etc.
|
|
|
|
Other names for "text terminal" are "general purpose terminal",
|
|
"general display terminal", "serial monitor", "serial console" (if
|
|
it's used like a console), "serial terminal", "dumb terminal",
|
|
"character-cell terminal", "character terminal", "ASCII/ANSI
|
|
terminal", "asynchronous terminal", "data terminal", "video terminal",
|
|
"video display terminal" (VDT), and "green terminal" (since many used
|
|
green displays). These names (especially "dumb terminal") are
|
|
sometimes used to mean emulating a text terminal on a PC with a
|
|
command line interface such as Linux. In olden days "video display
|
|
unit" (VDU) meant text terminal but strictly speaking, it excludes the
|
|
keyboard.
|
|
|
|
"Block mode" was used exclusively by old IBM mainframe terminals but
|
|
many modern terminals also have this capability (which is not used
|
|
much). In block mode, the characters you type are temporarily
|
|
retained in the terminal memory (and may possibly be edited by a
|
|
built-in editor at the terminal). Then when one presses the send key
|
|
(or the like) a block of characters (sometimes just a line of
|
|
characters) is sent to the computer all at once. Block mode (as of
|
|
late 1998) is not supported by Linux. See section ``Block Mode''.
|
|
|
|
|
|
2.3. Graphic GUI Capabilities of Text Terminals
|
|
|
|
While emulated text terminals don't display images, many real text
|
|
terminals can display bit-mapped images, but not in color.
|
|
Unfortunately, the popular image formats used on the Internet are not
|
|
supported. Thus the display of images is seldom used. The protocols
|
|
for terminal graphics include: Tektronix Vector Graphics, ReGIS (DEC),
|
|
Sixel (DEC), and NAPLPS (North American Presentation Level Protocol
|
|
Syntax).
|
|
|
|
Even without bit-mapped images, ordinary text terminals can sort of
|
|
display images. One may form arrows <--- and draw boxes with |__|,
|
|
etc. With special graphic character sets that have a lot of special
|
|
characters for line drawing, much more is possible. But even without
|
|
a graphic character set, one may produce "ascii graphics" art. The
|
|
term "graphics terminal" usually means a terminal that can display bit
|
|
mapped images. However, this term is sometimes applied also to text-
|
|
only terminals since text is a limited form of graphics.
|
|
|
|
|
|
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 continuously move in any direction (just like a pen or
|
|
pencil). True vector graphics draws high quality lines without
|
|
noticeable zig-zags but is both rare and expensive. For more details
|
|
see <http://www.cca.org/vector/>. Raster graphics is almost
|
|
universally used today for both PCs and text terminals. For PCs,
|
|
images encoded in vector graphic format can't be drawn as continuous
|
|
lines due to the electronic limitations but they can be translated to
|
|
raster graphics format for display (with a resulting drop in image
|
|
quality).
|
|
|
|
|
|
3. Thin Clients Terminals
|
|
|
|
3.1. Introduction
|
|
|
|
Since "thin clients" are not text terminals, this HOWTO only provides
|
|
a brief overview of them. There are other HOWTOs that cover them in
|
|
more detail but (as of 2010) they are unfortunately not up to date.
|
|
See ``Related HOWTOs, etc.''. Thin clients are thin (minimal) client
|
|
computers that behave something like terminals. Since text terminals
|
|
(except for very old ones) run an embedded operating system, they are
|
|
also like a computer. In contrast to text-terminals, thin clients all
|
|
display a modern high-speed GUI. They are dependent on more powerful
|
|
computers (servers) for their operation.
|
|
|
|
For a true thin client terminal, the computing work and disk storage
|
|
will all be done on the server. At the other extreme, most of this
|
|
work and storage is done at the thin client but some things such as
|
|
administration, still depend on the server. Since such a client is
|
|
not really "thin" it may more correctly be called a "fat client".
|
|
|
|
Instead of "thin client" they could have been simply called "graphic
|
|
terminals" but promoters of this technology wanted a catchy name to
|
|
get customers to believe that it was perhaps a totally different
|
|
technology. This trend of renaming what is basically just graphic
|
|
terminals (with new features) continues unabated. Some of these names
|
|
are "Virtual Desktop" and "Cloud Computing".
|
|
|
|
Thin clients may be created from an ordinary PC by using software or
|
|
may be a stand-alone piece of hardware. But such stand-alone hardware
|
|
may often be just a conventional PC monitor plus a small box for the
|
|
computer part of the hardware. Linux seems to favor the use of PCs as
|
|
clients.
|
|
|
|
Some claim that text-terminals are also a type of thin client but they
|
|
are not really since they don't conform to the client-server model.
|
|
However, connecting a terminal via telnet does invoke the client-
|
|
server model in the use of telnet as a means of transport of data.
|
|
But the relation of the text-terminal to it's host is not one of
|
|
client-server. The text-terminal is just another means of access to
|
|
the computer just like the monitor and its keyboard is to access a PC.
|
|
One could apply this same reasoning to a thin client and say that the
|
|
client-server relationship is only for the transport of data.
|
|
|
|
Thus a thin client is like a terminal. It has a GUI with a mouse that
|
|
makes it seem like you are using a computer. You are, but that
|
|
computer may be far away and have many other people using it at the
|
|
same time you are. Communication is over a high speed network
|
|
(wireless and/or cable) or even over the Internet. Some thin clients
|
|
can, in addition, emulate a text terminal and have a serial port
|
|
connector for that purpose. Recent ones also have USB interfaces as
|
|
well as ethernet.
|
|
|
|
There are various types of thin clients. One type is the "Window
|
|
Terminal" which runs under MS servers (and software). Another type is
|
|
the "network computer" which is supposed to be platform neutral. This
|
|
implies they should work with both MS Windows and Linux but early
|
|
models may not be easy to use with Linux. For Linux, the X Window
|
|
protocol is used. See ``Thin clients and NCs under Linux''
|
|
|
|
|
|
3.2. MS Window terminals
|
|
|
|
These are true terminals since all the computing work is done by a
|
|
server running Windows. They are also called "Window-based Terminals"
|
|
(WBT). These terminals (clients) are something like computers since
|
|
they often run an embedded operating system such as Linux or
|
|
Microsoft's CE, NT, or XP. It's often stored in flash memory so that
|
|
it may be updated. Also, ordinary PCs can be used as clients
|
|
(including, in some cases, Linux PCs) with the appropriate software,
|
|
Some clients can support X Window (from a Linux server) and some can
|
|
emulate text-terminals. Many so called "network computers" can also
|
|
run X Window. This will be discussed in the next section.
|
|
|
|
The server for these clients usually runs MS's Terminal Services (for
|
|
Windows 2000 servers). Prior to this there was Windows NT Terminal
|
|
Server Edition (starting mid 1998 with codename "Hydra"). MS uses RDP
|
|
(Remote Desktop Protocol) which is based on the ITU T.120 protocol.
|
|
In addition, there is an optional ICA protocol (with added features)
|
|
which can inter-operate with RDP.
|
|
|
|
Prior to this there was a modified Windows NT 3.51 (1995) called
|
|
"WinFrame" by Citrix using the proprietary ICA protocol (Independent
|
|
Computing Architecture). After MS came out with its own terminal
|
|
server, Citrix still remained on the scene. It created MetaFrame
|
|
software (formerly pICAsso) as an add-on to MS's Terminal Server (or
|
|
Services) so that it could support ICA-based terminals and provide
|
|
other additional features. Before MS got into the act, there were
|
|
other proprietary systems for terminals that could display the MS
|
|
Windows GUI but later on they all switched to support Microsoft's
|
|
system.
|
|
|
|
PCs running Linux can be turned into ICA based client terminals using
|
|
"free" (in price only) proprietary ICA client software from Citrix:
|
|
Installing the Linux Client
|
|
<http://support.citrix.com/article/CTX879408>. Unfortunately, MS
|
|
requires that you purchase a license to cover the clients, even if the
|
|
clients all run Linux. So if you want to save money on software costs
|
|
by using Linux, you'll have to go all-Linux and use both Linux servers
|
|
and clients using the free X-Window protocol.
|
|
|
|
The above is sometimes called "network computing" since the terminals
|
|
and servers connect to each other over a network (such as the common
|
|
TCP/IP based network used by both Linux and MS). Network computers
|
|
may be somewhat different as described below.
|
|
|
|
|
|
3.3. Network computers (NC's)
|
|
|
|
See Network Computer - Wikipedia
|
|
<http://en.wikipedia.org/wiki/Network_Computer> which claims that NC's
|
|
are defunct as a type of hardware, but that NC is used as a synonym
|
|
for "thin client".
|
|
|
|
These are neither true computers nor true terminals but are something
|
|
in-between. One type of network computer (NC's) is a computer with a
|
|
CPU but no hard Disk. The OS it needs to run is sent to it over a
|
|
network. NCs are full-graphics and use the services of a server
|
|
computer. They are a little different from terminals since some (or
|
|
most) of the programs they run may execute on their own CPU chip.
|
|
Running a browser was supposed to be one of their primary functions
|
|
and thus Java code applets may be sent to them for execution. Many
|
|
NCs support X Window so that one may use a Linux server to support it.
|
|
Such a server may be called a "Linux Terminal Server". IBM called
|
|
their NC a "NetStation" but now calls it "NetVista". They should work
|
|
on Intranet type networks and NetVista can run the Linux OS.
|
|
|
|
Wintel came out with a "NetPC" which, unlike the above, is almost a PC
|
|
computer. However, it has no removable disks so users can't install
|
|
their own software or obtain copies of anything.
|
|
|
|
|
|
3.4. Thin clients and NCs under Linux
|
|
|
|
There is a "Linux Terminal Server Project" (LTSP or ltsp) to use Linux
|
|
as a server for diskless thin clients. They use X Window and by
|
|
default, applications run on the server. But with additional effort,
|
|
one can set it up so that some or all applications run on the
|
|
"terminal". See <http://www.ltsp.org/>.
|
|
|
|
"Terminal" in LTSP is actually a thin (or fat) client. This project's
|
|
client can also run a telnet session and thus behave like a text-
|
|
terminal. A software package named "lts" for the LTSP is available in
|
|
the major Linux distributions.
|
|
|
|
It's claimed that if one has only a few "terminals", they will work
|
|
without the ltsp software. But if one has many "terminals", ltsp
|
|
software is needed. So use ltsp if what you want to do is to use old
|
|
PCs, etc. as diskless thin clients. It works OK on systems with over
|
|
100 thin-client workstations.
|
|
|
|
Linux provides NFS (Network File System) so that if ordinary computers
|
|
are connected to each other via a network, then a person on one
|
|
computer can run programs on another computer. Such a program sends
|
|
messages over the network so that it appears just like a program was
|
|
being run by your local computer. But such a program is actually
|
|
being run on another computer on the network. It works also with X
|
|
Window so that one may see GUI images generated on another computer.
|
|
|
|
Linux also allows a computer to be diskless and boot over a network.
|
|
See the "Terminal Server Project" above which has special software for
|
|
this purpose. Network-boot-HOWTO gives an overview. Older documents
|
|
are Diskless-HOWTO and Diskless-root-NFS-HOWTO. Thus using a diskless
|
|
computer which runs NFS enables you to run programs on another
|
|
computer (the server). This is just like using a NC (Network
|
|
Computer). It's not really a NC but it's emulating a type of NC.
|
|
It's also often called a "terminal" and in some sense it is.
|
|
|
|
Thus if you have an old PC with an ethernet card (NIC) you may be able
|
|
to use it as a NC. One source of info on this is Thinclient-HOWTO.
|
|
Even if your old PC doesn't have a NIC, you could still use it to
|
|
emulate a text-terminal. See ``Terminal Emulation''.
|
|
|
|
There are also a number of genuine Network Computers (NC) that will
|
|
work with a Linux server. Today some NCs run the Linux OS inside the
|
|
NC. Before Linux became popular, NCs didn't run the Linux OS but
|
|
required some other OS. But even if the NC uses a non-linux OS, it's
|
|
often possible to make it work with a Linux Server. The non-linux OS
|
|
is simply stored as files on the Linux Server. Then when the NC
|
|
starts up it sends a message to the Linux Server asking for the non-
|
|
linux OS files. This non-linux OS is thus sent to the NC over the
|
|
network and the NC boots.
|
|
|
|
The Linux Server runs the NFS and X Window both of which must be
|
|
supported by the NC. This enables one to use the NC as if it were an
|
|
X Window terminal.
|
|
|
|
There are some Linux HOWTOs for certain brands of NCs:
|
|
|
|
|
|
· JavaStation-HOWTO (by Sun)
|
|
|
|
· NC-HOWTO (IBM NetStation)
|
|
|
|
· NCD HOWTO (NCD-ThinSTAR)
|
|
|
|
· NCD-X-Terminal HOWTO
|
|
|
|
· XDM-and-X-Terminal HOWTO
|
|
|
|
|
|
3.5. Hardware hookups
|
|
|
|
There are 3 different types of hardware arrangements for thin clients.
|
|
The first type just uses a PC computer as a thin client by emulating a
|
|
thin client. It really isn't a thin client but it behaves like one.
|
|
The second type (no longer made ?) looks just like a text-terminal.
|
|
It just looks like a monitor, with a connector for a keyboard and
|
|
another connector for a network cable. It's a dedicated thin client
|
|
and can't be used for anything else. The third type looks like a tiny
|
|
computer. It uses a standard PC monitor and keyboard both of which
|
|
plug into a small box which is a "thin" computer. This box provides
|
|
an interface between the monitor/keyboard and the network.
|
|
|
|
|
|
3.6. History and the future
|
|
|
|
Promoters of NCs and related Window-Terminals projected that they
|
|
would soon replace millions of PCs. In 1998 about .7 million thin
|
|
clients were sold worldwide with (about 27% of them being NCs). In
|
|
1999 it dropped to .6 million but went up to .9 million in 2000 (vs.
|
|
1.3 million predicted). In 2001 it reached 1.09 million with 1.4
|
|
million predicted for 2002.
|
|
|
|
Microsoft servers (as of 2003) still dominate the market, but the
|
|
clients may run Linux for which users still have to pay license fee
|
|
for each Linux client to Microsoft. Thus free all-linux systems are
|
|
gaining ground.
|
|
|
|
A major reason why growth was not as rapid as predicted is that PCs
|
|
have come down in price in recent years so that they are often not
|
|
much more expensive than a thin client. However, it's argued that
|
|
even though thin clients may cost the same as PCs, the maintenance and
|
|
administration costs are less. Note that thin clients sometimes
|
|
replace text terminals instead of PCs.
|
|
|
|
|
|
4. Quick Text-Terminal Install
|
|
|
|
This is a quick procedure to install a terminal without going through
|
|
a ``Setup'' procedure for both the terminal and the host computer. It
|
|
probably will not work right if the terminal happens to have been set
|
|
up incompatible with the computer. If you don't understand some of it
|
|
you'll need to consult other parts of this document for more info.
|
|
|
|
To install a terminal, first look in /etc/termcap or terminfo.src to
|
|
find an entry for it (see ``Terminfo and Termcap (detailed)'').
|
|
Figure out what serial port you'll connect it to and what the tty
|
|
designation is for that port e.g. ttyS1, see ``Device Names''). As
|
|
the root user, edit /etc/inittab and add a getty command next to the
|
|
other getty commands. The format of the getty command depends on
|
|
which getty program you use. agetty (called just getty in the Debian
|
|
distribution) is the easiest (no configuration file). See the "info"
|
|
or "man re getty. For getty parameters use the terminfo (or termcap)
|
|
name (such as vt100) for your terminal. Type in a baud-rate that the
|
|
terminal supports. But if you set the baud too high you may need to
|
|
use (See``Flow Control'').
|
|
|
|
Then physically connect the main serial port of the terminal to the
|
|
chosen serial port of the computer with a file-transfer (null modem)
|
|
cable and turn on the terminal. Don't expect most ready-made cables
|
|
to be wired correctly for hardware flow control. Make sure the baud-
|
|
rate of the terminal is set the same as you gave to getty and that its
|
|
"data bits" is 8. Then at the computer console type "init q" to apply
|
|
the changes you made to the inittab file. You should now see a login
|
|
prompt at the terminal. If you don't, tap the terminal's return key.
|
|
If this doesn't work read more of this document and/or see ``Trouble-
|
|
Shooting''.
|
|
|
|
|
|
5. Why Use a Terminal ?
|
|
|
|
|
|
|
|
5.1. Intro to Why Use a Terminal
|
|
|
|
Many of these arguments apply also to GUI "thin-client" type of
|
|
terminal. The case for such terminals is frequently being made today
|
|
and promoters are devising new slogans and names in an attempt to
|
|
market the modern terminal concept under another name. For example
|
|
"Cloud Computing".
|
|
|
|
PC's are so powerful today that just one PC can often support several
|
|
persons using it at once, especially if they are doing low-load tasks
|
|
such as text editing, data entry, etc. One way to do this is to
|
|
connect a number of terminals to a single PC (or other host computer)
|
|
by modems or direct cable connection. To do this, it's usually best
|
|
to have a multi-user operating system such as Linux so that each user
|
|
at a terminal can use the computer independently. This has been
|
|
called "time sharing" but it's not good terminology today since
|
|
"distributed" computing over a network is also a type of time sharing.
|
|
It might be better described as "centralized" computing. But the
|
|
central computer may be connected to the rest of the world via a
|
|
network so that terminal users may send email, browse the Internet,
|
|
etc. So it's not exactly "centralized" either.
|
|
|
|
Prior to about 2000, terminals were seldom used with PC's because the
|
|
popular operating systems used for them (Windows, DOS, and Mac) were
|
|
not multiuser until 1998 (available for MS Windows NT) and previously
|
|
could not support terminals very well. Now that Linux, a multiuser
|
|
operating system, is freely available for PC's, the use of terminals
|
|
with PC's becomes more feasible. While text terminals are not smart
|
|
enough to support the type of graphical user interface (GUI) that most
|
|
computer users today expect, thin client type terminals are.
|
|
|
|
|
|
5.2. Lower Hardware Costs ?
|
|
|
|
When Computers (including PCs) were quite expensive, lower hardware
|
|
costs was a significant advantage of using terminals. Today with
|
|
cheap PCs, the cost savings is problematical. I wrote the next three
|
|
paragraphs years ago when PCs were more expensive. They are still
|
|
valid today but of less significance:
|
|
|
|
If several people use the same computer as the same time, there is a
|
|
reduction in the amount of hardware needed for the same level of
|
|
service. One type of savings is due to code sharing. The application
|
|
files on hard disks are shared as well as shared libraries in memory
|
|
(even when people are running different programs provided they use
|
|
some of the same functions in their code). Another type of savings is
|
|
due to reduction of peak load. The hardware of a single PC may be
|
|
idle most of the time as people slowly type in information, think,
|
|
talk, or are away from their desks. Having several people on the same
|
|
computer at once makes good use of much of this idle time which would
|
|
otherwise be wasted.
|
|
|
|
These savings are substantial. One may roughly estimate (using
|
|
statistical theory) that for 9 persons (8 terminals & 1 console) the
|
|
shared PC only needs only about 3 times as much capacity (in memory,
|
|
disk storage, CPU power, etc.) as a single PC in order to provide the
|
|
same level of service per person. Thus the computational hardware for
|
|
such a shared system should only cost about 1/3 as much per user.
|
|
However, the cost of the display hardware (CRT's, keyboards, video
|
|
electronics, etc.) is about the same for both cases. The terminals
|
|
have the added cost of requiring additional physical cable connectors
|
|
(such as serial ports) at the host computer.
|
|
|
|
For a fair comparison with PC's, the terminals should have the same
|
|
capabilities as the PC monitors. Unfortunately, color graphic
|
|
terminals for Linux (X Window) with high speed communication cost
|
|
about as much as a PC so in this case there not much (if any) savings
|
|
in hardware costs. But for text terminals there will be some savings,
|
|
especially if the terminals are obtained used at low cost.
|
|
|
|
|
|
5.3. Control of Software
|
|
|
|
For centralized computing, software (and the updates to software) only
|
|
need be installed and configured on one host computer instead of
|
|
several. The person in charge of this computer may control and
|
|
configure the software which is installed on it. This is advantageous
|
|
if the person controlling the host computer does an excellent job and
|
|
knows about the needs and preferences of the other users. Users can
|
|
be restricted in playing games or surfing the Internet, etc. Whether
|
|
or not centralized control is desirable depends on the situation.
|
|
It's in a sense depriving users of their "right" to controls what they
|
|
do with their computer including things that would improve their
|
|
efficiency at work and/or entertain them.
|
|
|
|
|
|
5.4. Hardware Upgrades
|
|
|
|
With terminals, the computer hardware upgrades take place on only one
|
|
computer instead of many. This saves installation labor effort.
|
|
While the cost of the hardware for the host computer upgrade will be
|
|
more than that for a single PC (since the host needs more computing
|
|
power than a PC), the cost will be significantly less than upgrading
|
|
the hardware of a number of PC's being used instead of terminals.
|
|
|
|
|
|
5.5. Other Advantages of Terminals
|
|
|
|
|
|
|
|
· The elimination of noise from fans and disk drives (unless you're
|
|
using a PC to emulate a terminal).
|
|
|
|
· The users of the terminals can share data and files and send e-mail
|
|
to each other. But they could also do this if the used PC on a
|
|
local network or via email over the internet.
|
|
|
|
|
|
5.6. Major Disadvantages of Text Terminals
|
|
|
|
|
|
· For the case of text terminals there is no high-speed graphic
|
|
display (or high resolution graphics) although they can often use
|
|
graphic character sets to draw boxes, etc. This lack limits the
|
|
software that may be used on it.
|
|
|
|
· A detailed display of progress will sometimes greatly increase the
|
|
time taken to do the job. For example, when copying a large number
|
|
of files and displaying the name of each, the terminal may only be
|
|
able to display the full path names of say 30 files per second so
|
|
only 30 files per second will be copied. But the computer hardware
|
|
is capable of copying at a rate many times higher. This can often
|
|
be fixed by using options of application programs for a minimal
|
|
display of progress. See ``Problem with Slow Scrolling''
|
|
|
|
· Most new computers don't have serial ports anymore, making it
|
|
difficult to use them to emulate text terminals that connect over a
|
|
serial line. One could perhaps connect by dialup using an analog
|
|
modem, but with high speed cable or DSL modems, the analog modem is
|
|
becoming obsolete.
|
|
|
|
|
|
5.7. Major Disadvantages of All Terminals
|
|
|
|
|
|
· If the host computer goes down, then no one can use the terminals
|
|
either (unless there is a "standby" host computer to connect to).
|
|
|
|
· As compared to a laptop, it's not portable. That is, you can't
|
|
easily take it around with you, unless you have some way of
|
|
connecting to your host computer where ever you go.
|
|
|
|
|
|
5.8. Are Text Terminals Obsolete ?
|
|
|
|
Text terminals are technologically obsolete because for a slightly
|
|
higher cost of hardware, one can build a smarter terminal (with the
|
|
same quality of display). This wasn't always the case since around
|
|
1980 memory cost thousands of dollars per megabyte. Today with low
|
|
costs for memory and processors, one could turn a text terminal into a
|
|
GUI graphic terminal for only about a 10% or 20% increase in hardware
|
|
cost.
|
|
|
|
Since a PC can emulate a terminal, almost everyone using computers had
|
|
a terminal emulator available until PCs started removing the serial
|
|
port from new models during the 2000-2010 decade. You might think
|
|
that now text terminals would be more in demand since emulating a
|
|
directly connected terminal is only feasible with newer PC's (with no
|
|
serial ports) only if one purchases such ports. But if one wants to
|
|
connect text terminals (including emulated ones) to a PC via the
|
|
serial port they will be out of luck if the Linux PC doesn't have a
|
|
serial port. Thus the disappearing serial port tends to make the text
|
|
terminal even more obsolete.
|
|
|
|
The reasons that text terminals are (or were) not fully obsolete are:
|
|
|
|
· The resolution of characters on the screen was better on monochrome
|
|
terminals than for cheaper PC monitors in text mode. But for high
|
|
resolution monitors the character resolution is fine.
|
|
|
|
· Some people don't need full screen graphics.
|
|
|
|
· Since running a text-terminal (in contrast to a GUI-graphics
|
|
terminal) doesn't consume much of a modern PC's resources, a large
|
|
number of terminals may be efficiently run from one PC.
|
|
|
|
|
|
6. Overview of How Text Terminals Work (in Linux)
|
|
|
|
See also section ``Some Details on How Terminals Work''
|
|
|
|
|
|
6.1. Device Names
|
|
|
|
Each terminal is connected to a serial port on the host computer
|
|
(often just a PC). The ports have names/numbers. The first few are:
|
|
ttyS0, ttyS1, ttyS2, etc.
|
|
|
|
These are represented by special files found in the /dev (device)
|
|
directory. ttyS0) corresponds to COM1 in DOS or Windows. ttyS1) is
|
|
COM2, etc. See ``Terminal Special Files'' for details on these and
|
|
related "devices".
|
|
|
|
|
|
6.2. Login/Logout
|
|
|
|
When the host computer starts up it runs the program getty. The getty
|
|
program runs the "login" program to log people in. See ``Getty (used
|
|
in /etc/inittab)''. A "login:" prompt appears on the screen. People
|
|
at the terminals and/or console log in (after giving their passwords)
|
|
and then have access to the computer. When it's time to shut the
|
|
terminal down, everyone must log off and (and power off their
|
|
terminal). See ``Login Restrictions'' regarding restricting logins
|
|
(including allowing the root user to log in at terminal).
|
|
|
|
|
|
6.3. Half/Full Duplex
|
|
|
|
If one watches someone typing at a terminal, the letters one types
|
|
simultaneously appear on the screen. A naive person might think that
|
|
what one types is being sent directly from the keyboard to the screen
|
|
with a copy going to the computer (half-duplex like, see next
|
|
paragraph). What is usually going on is that what is typed at the
|
|
keyboard is directly sent only to the host computer which in turn
|
|
echoes back to the terminal each character it receives (called full-
|
|
duplex). In some cases (such as passwords or terse editor commands)
|
|
the typed letters are intentionally not echoed back.
|
|
|
|
Full-duplex means that there are two (dual) one-way communication
|
|
links. Full-duplex is the norm for terminals. Half-duplex is half of
|
|
a duplex, meaning that there is only a single one-way communication
|
|
link. This link must be shared by communications going in both
|
|
directions and only one direction may be used at a time. In this case
|
|
the computer would not be able to echo the characters you type (and
|
|
send to it) so the terminal would need to also send each character you
|
|
type directly to the terminal screen. Some terminals have a half-
|
|
duplex mode of operation which is seldom used.
|
|
|
|
|
|
6.4. Terminal Memory
|
|
|
|
The image on a CRT tube will fade away almost instantly unless it is
|
|
frequently redrawn on the screen by a beam of electrons shot onto the
|
|
face of the tube. Since text sent to a terminal needs to stay on the
|
|
screen, the image on the screen must be stored in the memory chips of
|
|
the terminal and the electron beam must repeatedly scan the screen
|
|
(say 60 times per second) to maintain the image. See ``Terminal
|
|
Memory Details'' for more details.
|
|
|
|
|
|
6.5. Commands for the Terminal
|
|
|
|
The terminal is under the control of the computer. The computer not
|
|
only sends the terminal text to display on the screen but also sends
|
|
the terminal commands which are acted on. These are ``Control Codes''
|
|
(bytes) and ``escape sequences''. For example, the CR (carriage
|
|
return) control code moves the cursor to the left hand edge of the
|
|
screen. A certain escape sequence (several bytes where the first byte
|
|
is the "escape" control code) can move the cursor to the location on
|
|
the screen specified by parameters placed inside the escape sequence.
|
|
|
|
The ``first terminals'' had only a few such commands but modern
|
|
terminals have hundreds of them. The appearance of the display may be
|
|
changed for certain regions: such as bright, dim, underline, blink,
|
|
and reverse video. A speaker in a terminal can "click" when any key
|
|
is pressed or beep if a mistake has occurred. Function keys may be
|
|
programmed for special meanings. Various fonts may exist. The
|
|
display may be scrolled up or down. Specified parts of the screen may
|
|
be erased. Various types of flow control may be used to stop the flow
|
|
of data when bytes are being sent to the terminal faster than the
|
|
terminal can handle them. There are many more as you will see from
|
|
looking over an advanced terminal manual or from the Internet links
|
|
``Esc Sequence List''
|
|
|
|
6.6. Lack of Standardization Solved by Terminfo
|
|
|
|
While terminals made for the US all used the same ASCII code for the
|
|
alphabet (except for IBM terminals which used EBCDIC), they
|
|
unfortunately did not all use the same escape sequences. This
|
|
happened even after various ANSI (and ISO) standards were established
|
|
since these standards were never quite advanced enough. Furthermore,
|
|
older terminals often lacked the capabilities of newer terminals.
|
|
This might cause problems. For example, the computer might send a
|
|
terminal an escape sequence telling it to split the screen up into two
|
|
windows of specified size, not realizing that the terminal was
|
|
incapable of doing this.
|
|
|
|
To overcome these problems a database called "termcap" (meaning
|
|
"terminal capabilities") was established. Termcap was later
|
|
superceded by "terminfo". This database resides in certain files on
|
|
the computer and has a section of it (sometimes a separate file) for
|
|
each model of terminal. For each model (such as VT100) a list of
|
|
capabilities is provided including a list of certain escape sequences
|
|
available. For example blink=\E5m means that to make the cursor start
|
|
blinking the terminal must be sent: Escape 5 m. See Section ``Termcap
|
|
and Terminfo (detailed)'' for more details. Application programs may
|
|
utilize this database by calling certain C-Library functions. One
|
|
large set of such programs (over 200) is named "ncurses" and are
|
|
listed in the manual page for "ncurses" which comes with a developer's
|
|
ncurses package. There is also a NCURSES-programming-HOWTO.
|
|
|
|
|
|
6.7. The Interface
|
|
|
|
The environment variable TERM is the type of terminal Linux thinks you
|
|
are using. Most application programs use this to look up the
|
|
capabilities in the terminfo database so TERM needs to be set
|
|
correctly. But there is more to a correct interface than the
|
|
computer knowing about the capabilities of the terminal.
|
|
|
|
For bytes to flow from the computer to the terminal the terminal must
|
|
be set to receive the bytes at the same baud rate (bits per second) as
|
|
they are sent out from the terminal. If the terminal is set to
|
|
receive at 19,200 baud and the computer sends out characters at 9600
|
|
baud, only garbage (or perhaps nothing) will be seen on the screen.
|
|
One selects the baud rate for a terminal (as well as many other
|
|
features) from the terminals "set-up" menus at the terminal. Most
|
|
terminals have a large number of options in their "set-up" menus (see
|
|
``Terminal Set-Up (Configure) Details''). The computer serial port
|
|
has options also and these options must be set up in a compatible way
|
|
(see ``Computer Set-Up (Configure) Details''.
|
|
|
|
|
|
6.8. Emulation
|
|
|
|
Most terminals today have more than one emulation (personality or
|
|
"terminal mode"). The terminal model numbers of terminals formerly
|
|
made by DEC (Digital Equipment Corporation now Compaq) start with VT
|
|
(e.g. VT100). Many other terminals which are not VT100 may be set up
|
|
to emulate a VT100. Wyse was a major terminal manufacturer until
|
|
about 2005. Most of their terminals can emulate various DEC terminals
|
|
such at VT100 and VT220. Thus if you want to, say, use a VT320
|
|
terminal you may either use a real VT320 in "native" personality or
|
|
possibly use some other terminal capable of emulating a VT320.
|
|
|
|
The "native" personalities usually have more capabilities so, other
|
|
things being equal, "native" is usually the best to use. But other
|
|
things may not be equal. Since the Linux console emulates a VT102 it
|
|
you may want to have a terminal emulate this (or something close to it
|
|
such as VT100). This will help insure that some programs that may not
|
|
handle terminals properly will still work OK on your terminal. Some
|
|
programs will assume that you are using a VT102 if the program can't
|
|
find a terminfo for your terminal (or can't find a certain
|
|
capability). Thus the failure of a program to work correctly with
|
|
your non-vt102 terminal may well be your fault if you don't provide a
|
|
good terminfo file for your terminal. Using "native" and then
|
|
reporting any bugs will help discover and fix bugs which might not
|
|
otherwise get detected.
|
|
|
|
The most common type of emulation is to use a PC like it was a vt100
|
|
terminal (or the like). Programs loaded into the PC's memory do the
|
|
emulation. In Linux (unless you're in X Window) the PC monitor
|
|
(called the console) emulates a terminal of type "Linux" (close to
|
|
vt100). Even certain windows within X Window emulate terminals. See
|
|
``Terminal Emulation''.
|
|
|
|
|
|
6.9. The Console
|
|
|
|
On a PC, the monitor is normally the console. It emulates a terminal
|
|
of type "Linux". One logs on to it as a virtual terminal. See ``The
|
|
Console''. It receives messages from the kernel regarding booting and
|
|
shutdown progress. One may have the messages that normally go to the
|
|
console, go to the terminal. To get this you must manually patch the
|
|
kernel, except that for kernel 2.2 (or higher) it is a "make config"
|
|
option. See ``Make a Serial Terminal the Console''.
|
|
|
|
|
|
7. Terminal Special Files such as /dev/tty
|
|
|
|
"tty" is an abbreviation for "Teletype". The first terminals were
|
|
Teletypes (like remotely controlled typewriters). See subsection
|
|
``Teletypes''. A list of Linux devices (the stuff in the /dev
|
|
directory) may be found in "Linux Allocated Devices" which should be
|
|
included with kernel sources. It "describes" what each device used
|
|
for in only a word or two but doesn't tell you how to use them.
|
|
|
|
|
|
7.1. Serial Port Terminals
|
|
|
|
The computer considers each serial port to be a "device". It's
|
|
sometimes called a terminal device since at one time terminals were
|
|
the most common use for a serial port. For each such serial port
|
|
there is a special file in the /dev (device) directory. /dev/ttyS0)
|
|
is the special file for the serial port known as COM1 in the
|
|
DOS/Windows world.
|
|
|
|
To send text to a terminal you may redirect standard output of some
|
|
command-line command to the appropriate special file. For example
|
|
typing "echo test > /dev/ttyS1" at the command prompt should send the
|
|
word "test" to the terminal on ttyS1 (COM2) provided you have write
|
|
permission on /dev/ttyS1. Similarly, typing "cat my_file >
|
|
/dev/ttyS0" will send the contents of the file my_file to COM1
|
|
(ttyS0).
|
|
|
|
|
|
7.2. Pseudo Terminals
|
|
|
|
Pseudo terminals are pairs of devices such as /dev/ptyp3 and
|
|
/dev/ttyp3. There is no physical device directly associated with
|
|
either of them, not even a serial port connector. But if a program
|
|
treats ttyp3 like it was a serial port, what is read and written to
|
|
that port appears on the other member of the pair ptyp3 which another
|
|
program uses to read and write to. Thus two programs talk to each
|
|
other via this method and one program on ttyp3 thinks it's talking to
|
|
a serial port. It's something like a "pipe" between these two tty's.
|
|
For talking to ttyp3, any program designed to talk to a serial port
|
|
will do. But for the other program that talks to ptyp3, it must have
|
|
been specially written to talk to it. It's mainly programmers that
|
|
must concern themselves with pseudo terminals and most users don't
|
|
need to worry about them.
|
|
|
|
Here's an example: If someone connects via telnet to your computer
|
|
over a network (you are a telnet server), the part of the telnet
|
|
program handling this connection on your computer may wind up
|
|
connected to the pseudo terminal ptyp2. A getty program should be
|
|
running on the corresponding ttyp2. Getty thinks it's talking to a
|
|
terminal. When telnet gets a character from the remote client, it
|
|
goes thru ptyp2 to ttyp2 to getty which then sends back "login:"
|
|
routed via ttyp2, ptyp2, your server telnet program, and then out to
|
|
the network back to the client. Here the login program and the telnet
|
|
server program talk to each other via a "pseudo terminal". Note that
|
|
there is no pseudo terminal used on the client computer, just telnet.
|
|
Of course the server allocates a pseudo terminal (on the server) for
|
|
each client.
|
|
|
|
In X Window, the terminal emulator programs (such as xterm) use pseudo
|
|
terminals. Ham radio programs under Linux also use them. By using
|
|
certain application software, it is possible to have 2 or more pseudo
|
|
terminals attached to the same physical serial port.
|
|
|
|
For a pseudo terminal pair such as ptyp3 and ttyp3, the pty... is the
|
|
master or controlling terminal and the tty... is the slave.
|
|
|
|
There are only 16 ttyp's: ttyp0-ttypf (f is a hexadecimal digit). To
|
|
get more pairs, more letters such as q, r, s are used instead of p.
|
|
For example the pair ttys8, ptys8 is a pseudo terminal pair. Later
|
|
on, even more letters were added so as to allow even more pseudo
|
|
terminals. And when z was reached, they wrapped around to a. This is
|
|
confusing but old habits are difficult to change. Today Linux allow
|
|
say ttyp189 but it's not used. The device file system, which was
|
|
abandoned in 2004, would have used tty/s189. Be sure not to type say
|
|
ttys2 if you mean ttyS2 (a real serial port).
|
|
|
|
The master and slave are really the same "port" but the slave is used
|
|
by the application program and the master is used by a network program
|
|
(or the like) which supplies (and gets) data to/from the slave port.
|
|
The program using the slave port can run "as is" since it thinks it is
|
|
talking to a serial port.
|
|
|
|
Unix98 pseudo terminals (available on Linux) is more advanced than the
|
|
above but the basic concepts are the same (only the device names and
|
|
methods of creating them change). It creates pseudo terminal devices
|
|
on request so there is no need to check if the pseudo terminal you
|
|
might want to use in in use. By opening /dev/ptmx a new pseudo
|
|
terminal pair is created. The master doesn't show up as a device but
|
|
is just a file descriptor number passed to the computer program that
|
|
opened /dev/ptmx. But the slave is put into the /dev/pts directory:
|
|
for example" /dev/pts/3.
|
|
|
|
The /dev/pts directory is considered to be a file system of type
|
|
devpts and appears in the lists of mounted filesystems. While the
|
|
"file" /dev/pts/3 looks like an entry in the now obsolete device
|
|
filesystem, /dev/pts Is really a wholly different kind of filesystem.
|
|
|
|
See the Linux manual pages "pty" and "pts" (Unix 98 style) for more
|
|
details. For programmers there's the man-page openpty/forkpty (either
|
|
name displays the same man-page) which assumes that you already
|
|
understand pseudo terminals. There is a usr/include/pty.h file for
|
|
use by programmers. In earlier versions of Linux there was a pty.o
|
|
module, but it now seems that it's been built into the kernel. Here's
|
|
an example of some options available when you are compiling a Linux
|
|
2.6 kernel:
|
|
|
|
|
|
|
|
CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y
|
|
CONFIG_LEGACY_PTY_COUNT=256
|
|
|
|
|
|
|
|
7.3. The Controlling Terminal /dev/tty
|
|
|
|
/dev/tty stands for the controlling terminal (if any) for the current
|
|
process. To find out which tty's are attached to which processes use
|
|
the "ps -a" command at the shell prompt (command line). Look at the
|
|
"tty" column. For the shell process you're in, /dev/tty is the
|
|
terminal you are now using. Type "tty" at the shell prompt to see
|
|
what it is (see manual pg. tty(1)). /dev/tty is something like a
|
|
link to the actually terminal device name with some additional
|
|
features for C-programmers: see the manual page tty(4).
|
|
|
|
|
|
7.4. /dev/ttyIN "Terminals"
|
|
|
|
N stands for an integer. One use of these in Linux is with the ISDN
|
|
driver package: isdn4linux. The ttyIN is something like ttySN but it
|
|
emulates a modem and can be given modem commands.
|
|
|
|
|
|
7.5. The Console: ttyN or vc/N
|
|
|
|
In Linux the PC monitor is usually called the console and has several
|
|
device special files associated with it: vc/0 (tty0), vc/1 (tty1),
|
|
vc/2 (tty2), etc. When you log in you are on vc/1. To go to vc/2 (on
|
|
the same screen) press down the 2 keys Alt(left)-F3. For vc/3 use
|
|
Left Alt-F3, etc. These (vc/1, vc/2, vc/3, etc.) are called "virtual
|
|
terminals". vc/0 (tty0) is just an alias for the current virtual
|
|
terminal and it's where messages from the system are sent. Thus
|
|
messages from the system will be seen on the console (monitor)
|
|
regardless of which virtual terminal it is displaying.
|
|
|
|
You may log in to different virtual terminals and thus have a few
|
|
different sessions with the computer going on at the same time. Only
|
|
the system or the root user may write to /dev/vc/0 to which
|
|
/dev/console is sometimes linked. For more info on the console see
|
|
``The Linux Console''.
|
|
|
|
|
|
7.6. Creating a Device with "mknod"
|
|
|
|
The /dev directory comes supplied with many device special files. If
|
|
you need something that's not there you may try to create it with the
|
|
"mknod" command. See the manual page ttys(4) for how to do this for
|
|
serial ports. To use mknod you must know the major and minor device
|
|
numbers. You might be able to infer the numbers you need by using the
|
|
"ls -l" command in the /dev directory. It will display the major and
|
|
minor numbers of existing special files.
|
|
|
|
|
|
8. Some Details on How Terminals Work
|
|
|
|
If you know almost nothing about terminals, it's suggested that you
|
|
first read ``Introduction'' and also read ``Overview of How Terminals
|
|
Work''.
|
|
|
|
8.1. Terminal Memory Details
|
|
|
|
The terminal screen refreshes itself at perhaps 60 times per second
|
|
from an image stored in the memory of the terminal. For a PC the
|
|
monitor's image is stored on the video card inside the computer but
|
|
for a terminal, the equivalent of the video card is inside the
|
|
terminal. For a text terminal the storage of the image uses little
|
|
memory. Instead of putting every dot (pixel) on the screen into
|
|
memory and requiring the storage of about a quarter-million dots, a
|
|
much more efficient method of storage is used.
|
|
|
|
A screen-full of text may be represented inside the terminal memory by
|
|
ASCII bytes, one for each character on the screen. An entire screen
|
|
only takes about 2K ASCII bytes. To display these characters, the
|
|
terminal must also know the bit-map (the shape) of each of the almost
|
|
100 printable ASCII characters. With a bit-map of a character using
|
|
say 15 bytes, only about 1.5K of memory is needed for the bit-maps of
|
|
all the ASCII characters (the font). This ASCII text and font memory
|
|
is scanned so that the resulting image is put on the screen about 60
|
|
times each second. This is a form of shared memory where a single
|
|
bit-map of a letter such as the letter e, is shared by all of the many
|
|
letter e's which appear on a screen-full of text. Low memory
|
|
requirements meant low costs to produce monitors in the early 1980's
|
|
when the cost of memory was several thousand times higher than it is
|
|
today (costing then several dollars per kilobyte).
|
|
|
|
|
|
8.2. Early Terminals
|
|
|
|
The first terminals were something like remotely controlled
|
|
typewriters which could only "display" (print on paper) the character
|
|
stream sent to them from the computer. The earliest models were
|
|
called ``Teletypes''. The name "tty" is just an abbreviation for
|
|
"Teletype". Early terminals could do a line feed and a carriage
|
|
return just like a typewriter and ring a bell when a bell character
|
|
was received. Due to the lack of significant capabilities this was
|
|
the first type of terminal to be labeled "dumb". This type of
|
|
terminal interface (using a terminal type called "dumb") is sometimes
|
|
used today when the computer can't figure out what kind of a terminal
|
|
it is communicating with.
|
|
|
|
|
|
8.3. Escape Sequences and Control Codes (intro)
|
|
|
|
Terminals have many capabilities some of which are always present and
|
|
some of which require commands from the computer to change or
|
|
activate. To exercise all these capabilities under the control of the
|
|
computer requires that special codes be established so that the
|
|
computer can tell the terminal what to do. There are two major type
|
|
of such codes: escape sequences and control codes (control
|
|
characters). There are many times more escape sequences than control
|
|
codes.
|
|
|
|
|
|
8.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.
|
|
|
|
|
|
8.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.
|
|
|
|
|
|
8.4. Display Attributes & Magic Cookies
|
|
|
|
Terminals have various methods of generating character attributes such
|
|
as bold, reverse-video, underlining, etc. There should be no need for
|
|
the user to worry about how this is done, except that it creates
|
|
problems for some old terminals and there is sometimes an option for
|
|
this in the set-up menu of newer terminals.
|
|
|
|
The magic cookie method is obsolete. It's the simplest (and worst)
|
|
method of defining attributes: Use a certain byte for the start of an
|
|
attribute and another to end that attribute. For example, a "start
|
|
underlining" magic cookie byte is placed just before the first word to
|
|
be underlined. These extra bytes are put into the memory of the
|
|
screen page, just like character bytes that display as characters.
|
|
But this might foul up the count of the number of characters per line
|
|
since non-printable magic cookie characters are intermingled with
|
|
other printable characters. This sometimes causes problems.
|
|
|
|
A better method which uses more memory is to assign an attribute byte
|
|
(or half=byte, etc.) to each displayed character. This method is used
|
|
by PC video cards (for text) for the common PC monitor.
|
|
|
|
|
|
9. Special Features/Types of Some Terminals
|
|
|
|
|
|
|
|
9.1. Terminal Uses a PC Monitor
|
|
|
|
One may use a PC (including it's monitor) to emulate a terminal. But
|
|
PCs have become so powerful that only a small portion of the PC's
|
|
capacity is utilized to run the emulation. So why not make a tiny PC
|
|
that has low computing capability so it is barely able do the task of
|
|
emulating a terminal. Then call this tiny device a text terminal and
|
|
point out that one must supply and plug in a PC monitor in order to
|
|
use this terminal. Such devices exist and are only about an inch
|
|
high. They are sometimes referred to as small footprint terminals.
|
|
Their advantage is that they are cheap, take up little space, and
|
|
might be able to use surplus monitors that otherwise might be
|
|
discarded.
|
|
|
|
|
|
9.2. Color
|
|
|
|
9.2.1. Emulated text terminals
|
|
|
|
In contrast to the monochrome or most real text terminals, an emulated
|
|
text terminal usually has colors since it displays on a PC color
|
|
monitor. See ``Colors on Emulated Terminals''
|
|
|
|
|
|
9.2.2. Old real text terminal
|
|
|
|
Some real terminals had color displays but most had either no color or
|
|
fixed "color" displays other than white such as green or amber. All
|
|
terminals had black (electron beam turned off = zero brightness). A
|
|
real color terminal can change the color of the text and background to
|
|
many different colors while a monochrome terminal can only change the
|
|
brightness of a fixed color.
|
|
|
|
However, changing the brightness, etc. gives a lot of possibilities.
|
|
For example, a black and white (monochrome) terminal can have white,
|
|
grey, and black by varying the brightness. Some words can be black on
|
|
a light grey background while other are highlighted by black on white.
|
|
In addition there is white on black, underlining, and blinking.
|
|
|
|
Real color works like the color on a computer monitor or TV screen.
|
|
The CRT has three colors of dots permanently on it with the brightness
|
|
of each color controlled by its own electron beam (3 beams). The
|
|
monochrome of real text terminals had inherently better resolution
|
|
since it didn't depend on dots permanently fixed on the screen. For
|
|
text terminals the only use of color is to differentiate text and this
|
|
advantage was often not worth the cost of worse resolution. Thus
|
|
monochrome may have historically been better since it also cost less.
|
|
But today color displays have are ubiquitous and have improved in
|
|
resolution since the olden days of the real text terminal.
|
|
|
|
|
|
9.3. Multiple Sessions
|
|
|
|
For dual sessions the terminal has two serial ports of equal status.
|
|
Each port is connected to a serial port on a different computer. Thus
|
|
one may log in to two different computers with each session displaying
|
|
in a split-screen window. Alternatively, each session may run full-
|
|
screen with a "hot" key (or the like) to switch between sessions. One
|
|
could also connect to two different serial ports on the same computer
|
|
and log in twice (similar to "virtual terminals" at the console). The
|
|
program "screen" will make any ordinary terminal (single session)
|
|
connected to a single computer run two or more "sessions".
|
|
|
|
|
|
|
|
9.4. Printer/Auxiliary Port
|
|
|
|
Many terminals have a connector on the rear for such a port. It may
|
|
be labeled as "Aux" or "Printer", etc. Some printer ports are for
|
|
parallel printers while others are for serial printers. If a printer
|
|
is connected to the printer or auxiliary port, then pressing certain
|
|
keys will print the screen. One may also have everything that
|
|
displays on the screen go also to the printer. If the port is an
|
|
auxiliary port, one may connect this to another computer and almost
|
|
have dual sessions as above. However, the video memory inside the
|
|
terminal may not retain both sessions so you may need to refresh the
|
|
screen when switching to the other session. There will likely not be
|
|
a hot key either but possibly a programmable function key may be
|
|
programmed to do this. There exists various key combinations and
|
|
escape sequences for controlling such a port. See ``Printer Esc''.
|
|
|
|
There is a program called vtprint which is designed to send a print
|
|
job (text only) to your terminal to be printed on a printer attached
|
|
to the terminal. It's homepage is vtprint
|
|
<http://vtprint.sourceforge.net/>. It's also included in the Debian
|
|
distribution of Linux. xprt (also in Debian) seems to do something
|
|
similar, but only for X Window terminals ??
|
|
|
|
Using the printer port to print may be useful if you don't have an
|
|
extra port on your PC for a printer or for "point of sale" use in a
|
|
store. "Transparent print mode" is where whatever the PC sends out to
|
|
the terminal goes instead to the printer. If you want the printer to
|
|
be able to send bytes to the PC (in the reverse direction) then (per
|
|
Wyse) it's "bidirectional mode". The Wyse "auxiliary print mode" is
|
|
just transparent print mode where the terminal screen monitors what's
|
|
being printed.
|
|
|
|
|
|
9.5. Pages
|
|
|
|
Many terminals permit the storage of more than one page in their video
|
|
memory. Sometimes the page size is the same as the screen, but
|
|
sometimes it is larger so that scrolling will reveal unseen parts of a
|
|
page. So when one looks at a screen, there may be hidden text on the
|
|
same page above or below the display. In addition, if there is more
|
|
than just one page, there may be hidden text on these other pages.
|
|
One use for pages is on terminals that support dual sessions. Each
|
|
session may have its own page and one may switch back and forth
|
|
between them.
|
|
|
|
Even if you only have a one-page-terminal with the page sized equal to
|
|
what is displayed on the screen, you will still see other pages of a
|
|
file (etc.) as the host sends more data to the terminal. One
|
|
advantage to having additional pages stored in the terminal memory is
|
|
so that you can jump to them instantly without waiting a second or so
|
|
for them to be transmitted from the host.
|
|
|
|
Multiple pages is supported by ncurses. There is also a commercial
|
|
program called "Multiscreen" which supports multiple pages but
|
|
probably not for Linux ?? Multiscreen is reported to be part of SCO
|
|
and is something like the virtual terminals on a Linux PC console.
|
|
The Linux program "screen" makes it look like you have multiple pages
|
|
but they are stored in the computer and but you can have only one
|
|
page-like window for each running program.
|
|
|
|
|
|
9.6. Character-Sets
|
|
|
|
A character-set is normally represented by a list (or table or chart)
|
|
of characters along with the byte code assigned to each character.
|
|
The codes for a byte range from 0 to 255 (00 to FF in hexadecimal).
|
|
In MS-DOS, character-set tables are called "code-pages". You should
|
|
examine such a table if you're not familiar with them. They are
|
|
sometimes included in printer and terminal manuals but also are found
|
|
on the Internet.
|
|
|
|
Many character sets include letters from foreign languages. But they
|
|
may also include special characters used to draw boxes and other
|
|
special characters.
|
|
|
|
ASCII was the traditional English character set used on text terminals
|
|
It is a 7-bit code but will usually work OK even if your terminal is
|
|
set to 8-bit mode. In 8-bit mode with ASCII, the high order bit is
|
|
always set to zero. Other character-sets are usually available and
|
|
usually use 8-bit codes (except on very old terminals where the only
|
|
choice is ASCII). The first half of most character-sets are the
|
|
conventional 128 ASCII characters and the second half (with the high-
|
|
order bit set to 1) belong to a wide variety of character-sets.
|
|
Character sets are often ISO standards. To get specialized character
|
|
sets on a terminal, you may need to download a soft-font for that
|
|
character-set into the memory of the terminal. Many terminals have a
|
|
number of built-in character sets (but perhaps not the one you need).
|
|
|
|
Here are some common 8-bit character sets. CP stands for Code Page
|
|
character sets invented by IBM: CP-437 (DOS ECS), ISO-8859-1
|
|
(Latin-1), CP-850 (Multilingual Latin 1 --not the same as ISO
|
|
Latin-1), CP-1252 (WinLatin1 = MS-ANSI). MS Windows uses CP-1252
|
|
(WinLatin1) while the Internet often uses Latin-1. There are several
|
|
ISO-8859- character sets in addition to Latin-1. These include Greek
|
|
(-7), Arabic (-6), Eastern European (-2), and a replacement for
|
|
Latin-1 (-15) called Latin-9. There are many others. For example,
|
|
KOI8-R is more commonly used for Russian than IS0-8859-5. Unicode is
|
|
a very large character-set where each character is represented by 2
|
|
bytes instead on just one byte.
|
|
|
|
More info re character-sets are:
|
|
|
|
· Manual pages: charsets, iso_8859-l or latin1 (covers 8859 series),
|
|
ascii
|
|
|
|
· HOWTO's for various languages (often written in that language).
|
|
|
|
· ISO-8859 Alphabet Soup <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/>
|
|
|
|
· ... 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.
|
|
|
|
|
|
9.6.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.
|
|
|
|
|
|
9.6.2. National Replacement Characters (obsolete)
|
|
|
|
In the 1960's, the ASCII 7-bit code was devised to map 7-bit bytes to
|
|
English letters, numbers, punctuation marks, etc. Other countries
|
|
adopted ASCII, but most of them had some additional letters which were
|
|
not present in the ASCII code. What to do? Various people decided to
|
|
purge certain symbols (such as ^, }) from ASCII and to substitute
|
|
national letters (ones with dots over them, etc.) for the ASCII
|
|
letters. In other words they replaced ASCII letters with "National
|
|
Replacement Characters"
|
|
|
|
There were a lot of problems with this, since it was done mostly by
|
|
companies which sold computer terminals with a resulting lack of
|
|
standardization. Another problem was that sometimes the purged
|
|
symbols were needed. This problem was solved in the 1980's and 1990's
|
|
with the adoption of 8-bits/byte character sets which had many more
|
|
letters.
|
|
|
|
Many West-European languages only needed several additional letters
|
|
which were not in ASCII. To get them in 7-bit code, they borrowed the
|
|
codes for seldom used ASCII symbols:
|
|
} ~
|
|
when using these replacement character sets, you are deprived of using
|
|
certain of these ASCII symbols since they now are used for the new
|
|
non-ASCII letters. Now that 8-bit character codes have replaced 7-bit
|
|
ones, it's better to use an 8-bit code which has both all the ASCII
|
|
symbols plus the non-ASCII characters for various languages. There's
|
|
also Unicode which replaces 8-bit codes with the same code scheme to
|
|
cover all languages (well almost all significant ones).
|
|
|
|
ISO-646 (for 1972 and later) permitted using National Replacement
|
|
Characters (7-bit). It specified that the above mentioned character
|
|
codes may be borrowed, but doesn't specify which national characters
|
|
are to replace them. Some countries standardized the replacements by
|
|
registering them with ECMA.
|
|
|
|
Many terminals exist which support these national replacement
|
|
characters but you probably don't want to implement this support
|
|
unless you have some old files to read. Very old terminals may only
|
|
support the national characters for the country in which they were
|
|
sold. Later terminals offered a choice of languages. Modem terminals
|
|
are 8-bit and don't need "national replacements". Replacement
|
|
characters exist for the following languages/countries: British, Cuba
|
|
(Spanish), Dutch, Finnish, French, French Canadian, German, Hebrew,
|
|
Hungarian, Italian, Norwegian/Danish, Portuguese, Spanish, Swedish,
|
|
Swiss (German).
|
|
Here's tables for some character sets taken from Kermit and Unisys
|
|
documents:
|
|
|
|
|
|
|
|
Swedish Danish
|
|
ASCII German Finnish Norwegian French
|
|
|
|
@ at-sign section ------- ------- a-grave
|
|
[ left-bracket A-diaeresis A-diaeresis AE-digraph degree
|
|
/ backslash O-diaeresis O-diaeresis O-slash c-cedilla
|
|
] right-bracket U-diaeresis A-circle A-circle section
|
|
^ circumflex ------ U-diaeresis ------- -------
|
|
` accent-grave ------ e-acute ------- -------
|
|
{ left-brace a-diaeresis a-diaeresis ae-digraph e-acute
|
|
| vertical-bar o-diaeresis o-diaeresis o-circle u-grave
|
|
} right-brace u-diaeresis a-circle a-circle e-grave
|
|
~ tilde ess-zet u-diaeresis -------- diaeresis
|
|
|
|
ASCII Italian Spanish
|
|
|
|
@ at-sign section section
|
|
[ left-bracket degree inverted-exclamation
|
|
/ backslash #-pound N-tilde
|
|
] right-bracket e-acute inverted-question-mark
|
|
^ circumflex ------- -------
|
|
` accent-grave u-grave -------
|
|
{ left-brace a-grave degree
|
|
| vertical-bar o-grave n-tilde
|
|
} right-brace e-grave --------
|
|
~ tilde i-grave --------
|
|
|
|
|
|
|
|
9.7. Fonts
|
|
|
|
Most terminals made after the mid 1980's can accept downloaded soft-
|
|
font. This means that they can display almost any character set
|
|
provided that you can find the soft-font for it. If you can't find
|
|
the needed soft-font, you can always create your own. A free font
|
|
editor for this is called BitFontEdit (written by the author of this
|
|
document) and is at at
|
|
<http://www.ibiblio.org/pub/Linux/utils/terminal/>
|
|
For mapping the keyboard (and screen) for use of various fonts see
|
|
``Character Mapping: mapchan''
|
|
|
|
|
|
9.8. Keyboards & Special Keys
|
|
|
|
Terminal keyboards often have a number of keys that one doesn't find
|
|
on a PC keyboard. Few (if any) actual terminals will have all of
|
|
these keys and most will have additional keys not listed here. Some
|
|
have a large number of special purpose keys such as terminals made for
|
|
use with cash registers. There are often many more key meanings than
|
|
shown here since these keys often have extended meanings when used in
|
|
conjunction with other keys (such as shift and control).
|
|
|
|
|
|
· BREAK sends a very long 0 bit (space = +12 V) of duration 300 to
|
|
700 milliseconds to the host. The host may interpret this as an
|
|
interrupt if stty has set brkint or ignore it if ignbrk is set.
|
|
|
|
· NO SCROLL stops the screen from scrolling like ^S does. Depressing
|
|
it again resumes scrolling. Uses flow control signals to do this.
|
|
· REPEAT if held down with an other key, forces repeated output of
|
|
that other key even if the auto-repeat option is set to off.
|
|
|
|
· LINE FEED sends the line feed character ^J to the host. Seldom
|
|
used.
|
|
|
|
· SET-UP allows the manual configuration of the terminal via menus.
|
|
Sometimes purposely disabled by putting a block under it so it
|
|
can't be pressed down. Sometimes another key such as shift or
|
|
control must be pressed at the same time. See ``Getting Into Set-Up
|
|
(Configuration) Mode''.
|
|
|
|
· LOCAL disconnects the terminal from the host. In local, what one
|
|
types goes directly to the screen. Useful for testing.
|
|
|
|
· RETURN is the same as the "enter" key on a PC. It usually sends a
|
|
carriage return to the host which normally get translated to a new-
|
|
line character by the host's device driver. On some terminals it
|
|
may be set up to send something else.
|
|
|
|
· F1, F2, ... or PF1, PF2, ... are function keys which sometimes may
|
|
be programmed to send out a sequence of bytes (characters). See
|
|
``Function Keys''
|
|
|
|
|
|
9.9. Mouse
|
|
|
|
A few text-terminals support a mouse. When the mouse is clicked, an
|
|
escape sequence is sent to the host to tell it where the mouse is. An
|
|
article for a mouse on VT terminals was once at
|
|
http://www.cs.utk.edu/ shuford/terminal/dec_vt_mouse.html but it's now
|
|
a dead link (2013). Try the "Wayback" machine." These escape codes
|
|
for mice are called "DEC Locator sequences". The FALCO Infinity Series
|
|
of terminals, model ANSI-G supports it. Did any linux applications
|
|
support this ??
|
|
|
|
|
|
10. Terminal Emulation (including the Console)
|
|
|
|
10.1. Intro to Terminal Emulation
|
|
|
|
A trivial type of terminal emulation is where you set up a real
|
|
terminal to emulate another brand/model of terminal. To do this you
|
|
select the emulation you want (called "personality" in Wyse jargon)
|
|
from the terminal's set-up menu. This section will not discuss this
|
|
case.
|
|
|
|
Since a PC has a screen and keyboard (as does a real terminal) but
|
|
also has much more computing power, it's easy to use some of this
|
|
computing power to make the PC computer behave like a real text
|
|
terminal. Still a third type is where you just use a text-based
|
|
interface (at the console --usually just the monitor) to your Linux
|
|
PC, either by a terminal screen (such as xterm) in Xwindow or by a
|
|
"virtual terminal".
|
|
|
|
To fully emulate a real terminal on a PC requires that a serial port
|
|
of the computer will be used to connect the emulated terminal to
|
|
another computer. This would be either with a direct cable connection
|
|
from serial port to serial port, or via a modem. But in other cases,
|
|
the serial port will not be used directly as the interface. Instead,
|
|
the interface may be a network and the flow of bytes to and from the
|
|
terminal will travel in network packets via either a modem on a serial
|
|
port or via an ethernet port.
|
|
|
|
Emulation for connection to a remote computer provides more that just
|
|
a real text-terminal since the PC doing the emulation can also do
|
|
other tasks at the same time it's emulating a terminal. For example,
|
|
for serial port connections, kermit or zmodem may be run on the PC to
|
|
enable transfer of files over the serial line (and possibly over the
|
|
phone line via a modem) to the other computer that you are connected
|
|
to. The emulation needs only to be run on one of the virtual consoles
|
|
of the PC, leaving the other virtual consoles available for using the
|
|
PC in command-line-interface.
|
|
|
|
For Linux see ``Make a Linux PC a serial port terminal''. Emulation
|
|
software for this also available for use under MS Windows. See ``Make
|
|
a non-Linux PC a terminal'' This can be used to connect a Windows PC
|
|
(as a Text-Terminal) to a Linux PC.
|
|
|
|
Most Linux free software can only emulate a VT100, VT102, or
|
|
VT100/ANSI, xterm, pterm, or Wyse60 (but not fully). Since most PC's
|
|
have color monitors while VT100 and VT102 were designed for a
|
|
monochrome monitor, the emulation usually adds color capabilities
|
|
(including a choice of colors). Sometimes the emulation is not 100%
|
|
perfect but this usually causes few problems. None of them provide
|
|
programmable function keys. The non-free emulation software running
|
|
under MS Windows can emulate many more terminals than free Linux can.
|
|
|
|
|
|
10.2. Don't Try to Use TERM Variable for Emulation
|
|
|
|
Some have erroneously thought that they could create an emulator at a
|
|
Linux console (monitor) by setting the environment variable TERM to
|
|
the type of terminal they would like to emulate. This does not work.
|
|
The value of TERM only tells an application program what terminal you
|
|
are using. This way it doesn't need to interactively ask you this
|
|
question (and it's too dumb to be able to probe the terminal to find
|
|
out what type it is). If you're at a Linux PC monitor (command line
|
|
interface) it's a terminal of type "Linux", and since you can't change
|
|
this, TERM must be set to "Linux". But this "Linux" should be set
|
|
automatically, without you needing to do anything.
|
|
|
|
If you set it to something else, you are fibbing to an application
|
|
program. As a result, it will incorrectly interpret certain escape
|
|
sequences from the console resulting in a corrupted interface. Since
|
|
the Linux console behaves almost like a vt100 terminal, it could still
|
|
work almost OK if you falsely claimed it was a vt100 (or some other
|
|
terminal which is close to a vt100). In this case it may seeming work
|
|
OK most of the time but once in a while will give errors.
|
|
|
|
|
|
10.3. Serial Communication programs
|
|
|
|
while the newer free PuTTY and Terra-Term programs can connect
|
|
directly to a serial line but can't dial out, most of of the older
|
|
programs did dialing out via a serial port modem. Some dialing
|
|
programs are for making a PPP connection to the Internet via a modem,
|
|
such as wvdial, and don't normally include any terminal emulation.
|
|
But some other programs (such as minicom or seyon) do both terminal
|
|
emulation and modem dialing (without PPP so it's not easy to use them
|
|
to connect to the internet). But since these programs connect to a
|
|
modem via a specified serial port (including "internal" serial ports
|
|
that have no connector on the back of the PC), they may be used to
|
|
connect to a serial line via a possible serial port connector on the
|
|
back of a PC. For this case you just set them up to connect without
|
|
dialing a phone number. The program "picocom" just does terminal
|
|
emulation although it's possible to type in a modem command and a
|
|
phone number to dial out manually. These programs are also useful for
|
|
testing modems. Seyon is only for use with X Window and can emulate
|
|
Tektronix 4014 terminals. In the past (before the Internet was
|
|
widespread) one could use dialing programs to dial up some public
|
|
libraries to use their catalogs and indexes, or even read magazine
|
|
articles on line. But today such activity is almost always done using
|
|
the Internet where there is a much larger choice of connections and no
|
|
long-distance telephone bills.
|
|
|
|
The communication program C-Kermit (sometimes just called kermit)
|
|
doesn't do terminal emulation for Linux (in 2006). But Kermit can
|
|
emulate many terminals in its non-free MS Windows versions so you`ll
|
|
see lots of claims that Kermit can do terminal emulation. With Linux,
|
|
it's merely a semi-transparent pipe between whatever terminal you are
|
|
on and the remote site you are connected to. Thus if you use kermit
|
|
on a Linux PC the terminal type will be "Linux". If you have a Wyse60
|
|
connected to your PC and run kermit from that, you will appear as a
|
|
Wyse60 to the remote computer (which may not be able to handle Wyse60
|
|
terminals). Minicom emulates a VT102 and if you use it on Wyse60
|
|
terminal vt102 the remote host will think you are a vt102 and send you
|
|
vt102 escape sequences. These will flow into your computer's serial
|
|
port and will get translated to the Wyse escape sequences before going
|
|
out another serial port on your computer to your Wyse60 terminal. C-
|
|
Kermit can't do this sort of thing.
|
|
|
|
Emulators exist under DOS such as telix and procomm work just as well.
|
|
The terminal emulated is often the old VT100, VT102, or ANSI (like
|
|
VT100).
|
|
|
|
|
|
10.3.1. Emulation under X Window
|
|
|
|
There are many terminal emulation programs (such as xterm, uxterm.
|
|
gnome-terminal, and konsole) which may be run under X Window. They
|
|
can usually emulate a VT102, but some may be able to emulate at VT220,
|
|
or Tektronix 4014. They provide a command line interface to the
|
|
computer but they don't communicate via the serial port like a text
|
|
terminal. See Ubuntu -- x-terminal-emulator
|
|
<http://packages.ubuntu.com/dapper/virtual/x-terminal-emulator> for a
|
|
brief list of such emulators. Some are multilingual. Your Linux
|
|
distribution has likely installed one for you.
|
|
|
|
|
|
10.3.2. Real terminals once were better
|
|
|
|
Unless one was using X Window with a large display, a real terminal
|
|
was often nicer to use than emulating one. It often had better
|
|
resolution for text (since it's monochrome), and had no disk drives to
|
|
make annoying noises. Today, the resolution of modern color displays
|
|
is better than that of the old text-terminals and disk drives are
|
|
quieter.
|
|
|
|
|
|
10.4. Testing Terminal Emulation
|
|
|
|
For the VT series terminals there is a test program: vttest to help
|
|
determine if a terminal behaves correctly like a vt53, vt100, vt102,
|
|
vt220, vt320, vt420 etc. There is no documentation but it has menus
|
|
and is easy to use. To compile it run the configure script and then
|
|
type "make". It may be downloaded from:
|
|
<http://www.ibiblio.org/pub/Linux/utils/console/>
|
|
|
|
|
|
10.5. The Linux Console
|
|
|
|
The console for a PC Linux system is normally the computer monitor in
|
|
text mode. It emulates a terminal of type "Linux" and the escape
|
|
sequences it uses are in the man page: console_codes. There is no way
|
|
to make this interface emulate anything else. But of course you can
|
|
run emulation software on your PC so that the monitor and keyboard
|
|
will emulate a text terminal while that software program is running.
|
|
Setting the TERM environment variable to any type of terminal other
|
|
than "Linux" will not result in emulating that other terminal. It
|
|
will only result in a corrupted interface since you have falsely
|
|
declared (via the TERM variable) that your "terminal" is of a type
|
|
different from what it actually is: Linux. See ``Don't Use TERM For
|
|
Emulation''
|
|
|
|
In X Window, using a terminal emulator gives you the equivalent of a
|
|
console. For KDE they chose to call this emulation "konsole". In
|
|
some cases, the console for a Linux PC is a text-terminal. One may
|
|
recompile Linux to make a terminal receive most of the messages which
|
|
normally go to the console. See ``Make a Serial Terminal the
|
|
Console''.
|
|
|
|
The "Linux" emulation of the monitor is flexible and has features
|
|
which go well beyond those of the vt102 terminal which it was intended
|
|
to emulate. These include the ability to use custom fonts and easily
|
|
re-map the keyboard. These extra features reside in the console
|
|
driver software (including the keyboard driver). The console driver
|
|
only works for the monitor and will not work for a real terminal even
|
|
if it's being used for the console. Thus the "console driver" is
|
|
really a "monitor driver". In the early days of Linux one couldn't
|
|
use a real terminal as the console so "monitor" and "console" were
|
|
once always the same thing.
|
|
|
|
The stty commands work for the monitor-console just like it was a real
|
|
terminal. They are handled by the same terminal driver that is used
|
|
for real terminals. Bytes headed for the screen first go thru the
|
|
terminal (tty) driver and then thru the console driver. For the
|
|
monitor some of the stty commands don't do anything (such as setting
|
|
the baud rate). You may set the monitor baud rate to any allowed
|
|
value (such as a slow 300 speed) but the actual speed of putting text
|
|
on the monitor screen will not actually change. The file
|
|
/etc/ioctl.save stores stty settings for use only when the console is
|
|
in single user mode (but you are normally in multiuser-user mode).
|
|
This is explained (a little) in the init man page.
|
|
|
|
Many commands exist to utilize the added features provided by the
|
|
console-monitor driver. Real terminals, which use neither scan codes
|
|
nor VGA cards, unfortunately can't use these features. To find out
|
|
more about the console see the Keyboard-and-Console-HOWTO. Also see
|
|
the various man pages about the console (type "man -k console").
|
|
Unfortunately, much of this documentation is outdated.
|
|
|
|
|
|
10.6. Emulation Software
|
|
|
|
Since there are free programs to emulate the most common terminals,
|
|
you will unlikely need to use any non-free software. But if you need
|
|
to purchase software you should try to throughly check out what other
|
|
customers have to say about it.
|
|
|
|
|
|
10.6.1. Make a Linux PC a serial port terminal
|
|
|
|
Unless you want to emulate the standard vt100 (or close to it), xterm,
|
|
or a Wyse 60, there doesn't seem to be much free terminal emulation
|
|
software available for Linux. The free programs are minicom, picocom,
|
|
and for GUI: seyon and PuTTY. Seyon can emulate either xterm or vt100
|
|
while PuTTy uses its own termcap (terminfo) named "putty" (put the
|
|
terminal type "putty" in /etc/inittab). Putty's "pterm" can be used
|
|
as a replacement for xterm.
|
|
|
|
PuTTY is much newer than most other emulations and a major use of it
|
|
is as an SSH client but you can set its configuration for a serial
|
|
port connection. Seyon is much older but with more features (some of
|
|
which are seldom needed). There are also more recent (but weaker)
|
|
"emulators" for a GUI interface: gtkterm and cutecom, neither of which
|
|
can emulate any terminal except of type "dumb" ??). Seyon can also
|
|
emulate a Tektronix 4014 terminal. For Wyse see Wyse 60 emulator
|
|
<http://gutschke.com/wy60/>.
|
|
|
|
Both gtkterm (and likely cutecom) don't use escape sequences, and
|
|
might be said to emulate a terminal of type "dumb" so they would be
|
|
quite slow if used as a text terminal for editing files on the host
|
|
computer using the vim editor, etc. gtkterm is simple to set up and
|
|
very weak in capabilities but it does show its current status at the
|
|
bottom of the screen.
|
|
|
|
Minicom, PuTTY, picocom, gtkterm, or cutecom may be used to emulate a
|
|
directly connected terminal by simply starting one of them. For
|
|
minicom, you must configure it for the serial port used). Picocom is
|
|
like a mini-minicom and doesn't have automatic dialout capability.
|
|
Gtkterm might be called a "mini-mini-minicom".
|
|
|
|
Minicom : For the case of minicom you obviously don't try to dial-out.
|
|
When you want to quit minicom (after you logout from the other PC) you
|
|
use minicom's q command to quit without reset since there is no modem
|
|
to reset. When minicom starts, it automatically sends out a modem
|
|
init string to the serial port. But since there's no modem there, the
|
|
string gets put after the "login:" prompt. If this string is mostly
|
|
capital letters, the getty program (which runs login) at the other PC
|
|
may think that your terminal has only capital letters and try to use
|
|
only capital letters. To avoid this, configure the modem init strings
|
|
sent by minicom to null (erase the init strings).
|
|
|
|
The non-free terminal emulator "Procomm" (which is from the MS world),
|
|
can be used on a Linux PC if you run dosemu to emulate Dos or possibly
|
|
in a mode emulating MS Windows. The last version of it seems to be
|
|
4.8 released in around 2000 so it will likely not work with modern MS
|
|
systems. It was sold by Symantec which has many files supporting it
|
|
which may be found using their search engine at
|
|
<http://www.symantec.com/>. And if you check the Internet (in 2008),
|
|
it's still being sold here and there.
|
|
|
|
There was a specialized Linux distribution: Serial Terminal Linux. It
|
|
would turn a PC to into a minicom-like terminal. It's small (fits on
|
|
a floppy) and will not let you use the PC for any other purpose (when
|
|
it's running). The link to it is broken, but one similar to it (in
|
|
2013), but on CD, is ASASHI DOT NET: PITUX, micro SERIAL TERMINAL
|
|
LINUX <http://www.asashi.net/pages/pitux.html>
|
|
|
|
TERM (non-free commercial software from Century Software) Terminal
|
|
Emulator
|
|
<http://www.centurysoftware.com/terminal_emulator/advanced_terminal_emulator.php>
|
|
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.
|
|
|
|
|
|
10.6.2. Make a Linux PC an IBM network terminal
|
|
|
|
This happens automatically when you run programs like telnet or ssh,
|
|
provided of course that your computer is connected to a network
|
|
(perhaps via a modem). Telnet normally uses a network (often the
|
|
Internet) to connect your console, which emulates a terminal of type
|
|
"Linux", to a remote computer for you to log in to. However, there
|
|
are some free programs that allow you to use telnet with IBM terminal
|
|
emulation on your PC to connect with IBM mainframes.
|
|
|
|
One IBM program emulates an IBM tn5250 terminal and printer and
|
|
another emulates an IBM c3270. There's also one that emulates an IBM
|
|
pr3287 printer (the mainframe thinks it's connected to the printer).
|
|
The Debian distribution has these. It's reported that the tn5250
|
|
emulates a vt keyboard under Linux and not a 5250 keyboard like it
|
|
should. Also, it's reported that the documentation and keyboard
|
|
mapping for the MS Windows version are better than for the Linux
|
|
version.
|
|
|
|
|
|
10.6.3. Make a non-Linux PC a terminal
|
|
|
|
Emulators exist which run on non-Linux PCs. They permit you to use a
|
|
non-Linux-PC as a terminal to connected to a Linux-PC. Under DOS
|
|
there were many programs that not only emulated a terminal but let you
|
|
dial out with a modem so that you could connect to other computers
|
|
over telephone lines (without getting connected to the Internet). Of
|
|
historical interest is an article in Byte magazine from Feb 1994
|
|
entitled "DOS Serial Communications. It was onetime at
|
|
http://www.byte.com/art/9402/sec8/art1.htm.
|
|
|
|
Today Windows comes with "HyperTerminal" (formerly simply called
|
|
"Terminal" in Windows 3.x and DOS). Competing with this is both the
|
|
free (open source) PuTTY and the non-free "HyperTerminal Private
|
|
Edition" <http://www.hilgraeve.com/htpe/index.html> which is non-free
|
|
to business. It can emulate vt-220. PuTTY emulates xterm and
|
|
supposedly also vt-102 but it doesn't have file transfer capabilities
|
|
(such as zmodem) like HyperTerminal does. But PuTTY permits a display
|
|
with a height of over 24 lines (set the Linux shell variable LINES to
|
|
say 32 by typing: LINES=32). Turbosoft's TTWin (non-free) can emulate
|
|
over 80 different terminals under Windows. See
|
|
<http://www.ttwin.com/> or <http://www.turbosoft.com.au/>
|
|
(Australia). See also WRQ <http://www.wrq.com/>
|
|
|
|
For using a Mac computer to emulate a common terminal use either
|
|
PuTTY, Linux's "minicom" (ported to the Mac OS X) or the old "zterm"
|
|
(shareware). For very old Macs prior to OS X, see the mini-howto:
|
|
Mac-Terminal. Carnation Software
|
|
<http://www.carnationsoftware.com/carnation/HT.Carn.Home.html> has
|
|
non-free software to emulate a wide variety of terminals on a Mac.
|
|
Mac OS X has a "terminal" program that gives you a terminal window
|
|
just like the xterm window in Linux's X Window. In that window you
|
|
may run "minicom" (if it's available). Both the "fink" and
|
|
"darwinports" projects have ported minicom to the Mac, but they may
|
|
not have the most recent version and you might need to compile minicom
|
|
yourself.
|
|
|
|
|
|
|
|
10.7. Colors on Emulated Terminals
|
|
|
|
Since displays used for text terminal emulation are almost always
|
|
color displays, you can utilize color coding of words. Besides
|
|
displaying directories this way (See ``Example for ls Function'') some
|
|
other Linux programs display color-coded text. It seems to mostly
|
|
happen without any configuring but there may be color conflicts. For
|
|
example, if you have set the background color green, then if a
|
|
programs sends you green text, it will be difficult or impossible to
|
|
read.
|
|
|
|
Color usually works by programs sending ANSI escape sequences to the
|
|
terminal. One might think that an emulated terminal would show the
|
|
ANSI escape codes in the ``terminfo''. for the terminal. But this is
|
|
not usually the case since if a terminal support colors it seems to be
|
|
assumed that these color will be sent to the terminal using the ANSI
|
|
encoding.
|
|
|
|
|
|
If you want to see what these encodings are, look at "man
|
|
console_codes". The ECMA-48 color codes in this man page appear to be
|
|
a subset of the ANSI color codes. For excruciating details see ANSI
|
|
escape code - Wikipedia
|
|
<http://en.wikipedia.org/wiki/ANSI_escape_code>. Note that these ANSI
|
|
codes cover more than just colors.
|
|
|
|
For PuTTY one can select the precise color to display for every ANSI
|
|
code by using the settings menu and clicking on "Colours". For
|
|
example if you have your screen background light green, then you can
|
|
remap that ANSI color to some shade of brown that you select. Note
|
|
that light green is called "Green Bold". It's bold because it
|
|
contains a lot of white which makes it a light color.
|
|
|
|
|
|
11. Flow Control (Handshaking)
|
|
|
|
Flow control (= handshaking = pacing) is to prevent too fast of a
|
|
flow of bytes from overrunning a terminal, computer, modem or other
|
|
device. Overrunning is when a device can't process what it is
|
|
receiving quickly enough and thus loses bytes and/or makes other
|
|
serious errors. What flow control does is to halt the flow of bytes
|
|
until the terminal (for example) is ready for some more bytes. Flow
|
|
control sends its signal to halt the flow in a direction opposite to
|
|
the flow of bytes it wants to stop. Flow control must both be set at
|
|
the terminal and at the computer.
|
|
|
|
There are 2 types of flow control: hardware and software (Xon/Xoff or
|
|
DC1/DC3). Hardware flow control uses dedicated signal wires such as
|
|
RTS/CTS or DTR/DSR while software flow control signals by sending DC1
|
|
or DC3 control bytes in the normal data wires. For hardware flow
|
|
control, the cable must be correctly wired.
|
|
|
|
The flow of data bytes in the cable between 2 serial ports is bi-
|
|
directional so there are 2 different flows (and wires) to consider:
|
|
|
|
1. Byte flow from the computer to the terminal
|
|
|
|
2. Byte flow from the terminal keyboard to the computer.
|
|
|
|
|
|
11.1. Why Is Flow Control Needed ?
|
|
|
|
You might ask: "Why not send at a speed slow enough so that the device
|
|
will not be overrun and then flow control is not needed?" This is
|
|
possible but it's usually significantly slower than sending faster and
|
|
using flow control. One reason for this is that one can't just set
|
|
the serial port baud rate at any desired speed such as 14,500, since
|
|
only a discrete number of choices are available. The best choice is
|
|
to select a rate that is a little higher than the device can keep up
|
|
with but then use flow control to make things work right.
|
|
|
|
If one decides to not use flow control, then the speed must be set low
|
|
enough to cope with the worst case situation. For a terminal, this is
|
|
when one sends escape sequences to it to do complex tasks that take
|
|
more time than normal. In the case of a modem (with data compression
|
|
but no flow control) the speed from the computer to the modem must be
|
|
slow enough so that this same speed is usable on the phone line, since
|
|
in the worst case the data is random and can't be compressed. If one
|
|
failed to use flow control, the speed (with data compression turned
|
|
on) would be no faster than without using any compression at all.
|
|
|
|
Buffers are of some help in handling worst case situations of short
|
|
duration. The buffer stores bytes that come in too fast to be
|
|
processed at once, and saves them for processing later.
|
|
|
|
11.2. Padding
|
|
|
|
Another way to handle a "worst case" situation (without using flow
|
|
control or buffers) is to add a bunch of nulls (bytes of value zero)
|
|
to escape sequences. Sometimes DEL's are used instead provided they
|
|
have no other function. See ``Recognize Del''.
|
|
|
|
The escape sequence starts the terminal doing something, and while the
|
|
terminal is busy doing it, it receives a bunch of nulls which it
|
|
ignores. When it gets the last null, it has completed its task and is
|
|
ready for the next command. This is called null padding. These nulls
|
|
formerly were called "fill characters". These nulls are added just to
|
|
"waste" time, but it's not all wasted since the terminal is usually
|
|
kept busy doing something else while the nulls are being received. It
|
|
was much used in the past before flow control became popular. To be
|
|
efficient, just the right amount of nulls should be added and figuring
|
|
out this is tedious. It was often done by trial and error since
|
|
terminal manuals are of little or no help. If flow control doesn't
|
|
work right or is not implemented, padding is one solution. Some of
|
|
the options to the stty command involve padding.
|
|
|
|
|
|
11.3. Overrunning a Serial Port
|
|
|
|
One might wonder how overrunning is possible at a serial port since
|
|
both the sending and receiving serial ports involved in a transmission
|
|
of data bytes are set for the same speed (in bits/sec) such as 19,200.
|
|
The reason is that although the receiving serial port electronics can
|
|
handle the incoming flow rate, the hardware/software that fetches and
|
|
processes the bytes from the serial port sometimes can't cope with the
|
|
high flow rate.
|
|
|
|
One cause of this is that the serial port's hardware buffer is quite
|
|
small. Older serial ports had a hardware buffer size of only one byte
|
|
(inside the UART chip). If that one received byte of data in the
|
|
buffer is not removed (fetched) by CPU instructions before the next
|
|
byte arrives, that byte is lost (the buffer is overrun). Newer
|
|
UART's, namely most 16550's, have 16-byte buffers (but may be set to
|
|
emulate a one-byte buffer) and are less likely to overrun. It may be
|
|
set to issue an interrupt when the number of bytes in its buffer
|
|
reaches 1, 4, 8, or 14 bytes. It's the job of another computer chip
|
|
(usually the main CPU chip for a computer) to take these incoming
|
|
bytes out of this small hardware buffer and process them (as well as
|
|
perform other tasks).
|
|
|
|
When contents of this small hardware receive buffer reaches the
|
|
specified limit (one byte for old UART'S) an interrupt is issued.
|
|
Then the computer interrupts what it was doing and software checks to
|
|
find out what happened. It finally determines that it needs to fetch
|
|
a byte (or more) from the serial port's buffer. It takes these
|
|
byte(s) and puts them into a larger buffer (also a serial port buffer)
|
|
that the kernel maintains in main memory. For the transmit buffer,
|
|
the serial hardware issues an interrupt when the buffer is empty (or
|
|
nearly so) to tell the CPU to put some more bytes into it to send out.
|
|
|
|
Terminals also have serial ports and buffers similar to the computer.
|
|
Since the flow rate of bytes to the terminal is usually much greater
|
|
than the flow in the reverse direction from the keyboard to the host
|
|
computer, it's the terminal that is most likely to suffer overrunning.
|
|
Of course, if you're using a computer as a terminal (by emulation),
|
|
then it is likewise subject to overrunning.
|
|
|
|
Risky situations where overrunning is more likely are: 1. When
|
|
another process has disabled interrupts (for a computer). 2. When the
|
|
serial port buffer in main (or terminal) memory is about to overflow.
|
|
|
|
11.4. Stop Sending
|
|
|
|
When its appears that the receiver is about to be overwhelmed by
|
|
incoming bytes, it sends a signal to the sender to stop sending. That
|
|
is flow control and the flow control signals are always sent in a
|
|
direction opposite to the flow of data which they control (although
|
|
not in the same channel or wire). This signal may either be a control
|
|
character (^S = DC3 = Xoff) sent as an ordinary data byte on the data
|
|
wire (in-band signalling), or a voltage transition from positive to
|
|
negative in the dtr-to-cts (or other) signal wire (out-of-band
|
|
signalling). Using Xoff is called "software flow control" and using
|
|
the voltage transition in a dedicated signal wire (inside the cable)
|
|
is called hardware flow control.
|
|
|
|
|
|
11.5. Keyboard Lock
|
|
|
|
With terminals, the most common case of "stop sending" is where the
|
|
terminal can't keep up with the characters being sent to it and it
|
|
issues a "stop" to the PC. Another case of this is where someone
|
|
presses control-S. Much less common is the opposite case where the PC
|
|
can't keep up with your typing speed and tells the terminal to stop
|
|
sending. The terminal "locks" its keyboard and a message or light
|
|
should inform you of this. Anything you type at a locked keyboard is
|
|
ignored. When the PC catches up on it's work, then the keyboard
|
|
should unlock. When it doesn't, there is likely some sort of deadlock
|
|
going on.
|
|
|
|
Another type of keyboard lock happens when a certain escape sequence
|
|
(or just the ^O control character for Wyse 60) is sent to the
|
|
terminal. While the previous type of lock is done by the serial
|
|
driver, this type of lock is done by the hardware of a real terminal.
|
|
It's a catch-22 situation if this happens since you can't type any
|
|
commands to escape out of this lock. Going into setup and resetting
|
|
might work (but it failed on my Wyse 60 and I had to cycle power to
|
|
escape). One could also send an "unlock keyboard" escape sequence
|
|
from another terminal.
|
|
|
|
The term "locked" is also sometimes used for the common case of where
|
|
the computer is told to stop sending to a terminal. The keyboard is
|
|
not locked so that whatever you type goes to the computer. Since the
|
|
computer can't send anything back to you, characters you type don't
|
|
display on the screen and it may seem like the keyboard is locked.
|
|
Scrolling is locked (scroll lock) but the keyboard is not locked.
|
|
|
|
|
|
11.6. Resume Sending
|
|
|
|
When the receiver has caught up with its processing and is ready to
|
|
receive more data bytes it signals the sender. For software flow
|
|
control this signal is the control character ^Q = DC1 = Xon which is
|
|
sent on the regular data line. For hardware flow control the voltage
|
|
in a signal line goes from negative (negated) to positive (asserted).
|
|
If a terminal is told to resume sending the keyboard is then unlocked
|
|
and ready to use.
|
|
|
|
|
|
11.7. Hardware Flow Control (RTS/CTS etc.)
|
|
|
|
Some older terminals have no hardware flow control while others used a
|
|
wide assortment of different pins on the serial port for this. For a
|
|
list of various pins and their names see ``Standard Null Modem Cable
|
|
Pin-out''. The most popular pin to use seems to be the DTR pin (or
|
|
both the DTR pin and the DSR pin).
|
|
|
|
|
|
11.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.
|
|
|
|
|
|
11.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 file-transfer serial cable the DTR pin at the
|
|
terminal is connected to the DSR pin at the computer. But Linux
|
|
doesn't support DTR/DSR flow control (although drivers for some
|
|
multiport boards may support DTR/DSR flow control.) A way around this
|
|
problem is to simply wire the DTR pin at the terminal to connect to
|
|
the CTS pin at the computer and set RTS/CTS flow control (stty
|
|
crtscts). The fact that it's only one way will not affect anything so
|
|
long as the host doesn't get overwhelmed by your typing speed and drop
|
|
RTS in a vain attempt to lock your keyboard. See ``Keyboard Lock''.
|
|
For DTR/DSR flow control (if your terminal supports this two-way flow
|
|
control) you do the above. But you also connect the DSR pin at the
|
|
terminal to the RTS pin at the computer. Then you are protected if
|
|
you type too fast.
|
|
|
|
|
|
11.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.
|
|
11.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.
|
|
|
|
|
|
11.8. Is Hardware Flow Control Done by Hardware ?
|
|
|
|
Some think that hardware flow control is done by hardware but only a
|
|
small part of it is done by hardware. Most of it is actually done by
|
|
your operating system software. UART chips and associated hardware
|
|
usually know nothing at all about hardware flow control. When a
|
|
hardware flow control signal is received (due to the signal wire
|
|
flipping polarity) the hardware gives an electrical interrupt signal
|
|
to the CPU. However, the hardware has no idea what this interrupt
|
|
means. The CPU stops what it was doing and jumps to a table in main
|
|
memory that tells the CPU where to go to find a program which will
|
|
find out what happened and determine what to do about it. In this
|
|
case this program stops the outgoing flow of bytes.
|
|
|
|
But even before this program stops the flow, it was already stopped
|
|
by the interrupt which interrupted the work of the CPU. This is one
|
|
reason why hardware flow control stops the flow faster. It doesn't
|
|
need to wait for a program to do it. But if that program didn't
|
|
command that the flow be stopped, the flow would resume once that
|
|
program exited. So the program is essential to stop the flow even
|
|
though it is not the first to actually stop the flow. After the
|
|
interrupt happens any bytes (up to 16) which were already in the
|
|
serial port's hardware transmit buffer will still get transmitted. So
|
|
even with hardware flow control the flow doesn't instantly stop.
|
|
|
|
Using software flow control requires that each incoming byte be
|
|
checked to see if it's an "off" byte. These bytes are delayed by
|
|
passing thru the 16-byte receive buffer. If the "off" byte was the
|
|
first byte into this buffer, there could be a wait while 15 more bytes
|
|
were received. Then the 16 bytes would get read and the "off" byte
|
|
found. This extra delay doesn't happen with hardware flow control.
|
|
|
|
|
|
11.9. Obsolete ?? ETX/ACK or ENQ/ACK Flow Control
|
|
|
|
This is also software flow control and requires a device driver that
|
|
knows about it. Bytes are sent in packets (via the async serial port)
|
|
with each packet terminated by an ETX (End of Text) control character.
|
|
When the terminal gets an ETX it waits till it is ready to receive the
|
|
next packet and then returns an ACK (Acknowledge). When the computer
|
|
gets the ACK, it then send the next packet. And so on. This is not
|
|
supported by Linux ?? Some HP terminals use the same scheme but use
|
|
ENQ instead of ETX.
|
|
|
|
|
|
12. Physical Connection
|
|
|
|
12.1. Introduction
|
|
|
|
A terminal may be connected to its host computer either by a direct
|
|
cable connection, via a modem, or via a terminal server. The flow of
|
|
data may be either a direct sequence of bytes (such as from a serial
|
|
port) or packets on a network (such as TCP/IP).
|
|
|
|
|
|
|
|
12.2. Multiport I/O Cards (Adapters)
|
|
|
|
Additional serial cards may be purchased which have many serial ports
|
|
on them called "multiport boards". These boards are not covered in
|
|
this HOWTO but there is a list of some of them (with URLs) in the
|
|
Serial-HOWTO.
|
|
|
|
|
|
12.3. Direct Serial Cable Connection.
|
|
|
|
The simplest way to connect a terminal to a host computer is via a
|
|
direct connection to a serial port on the computer. You may also use
|
|
some the info in this section for connecting one computer to another
|
|
(via the serial port). Most desktop PC's come with a serial port or
|
|
two, one of which may be used by a mouse. For the EIA-232 port, you
|
|
need a null modem cable (PC-to-PC cable) that crosses over the
|
|
transmit and receive wires. In ethernet terminology it would be
|
|
called a "crossover cable" (but the ethernet cable will not work for
|
|
the serial port). If you want hardware flow control, you will
|
|
probably use the DTR pin (or both the DTR and DSR pins).
|
|
|
|
Make sure you have the right kind of cable. A null modem cable bought
|
|
at a computer store may do it (if it's long enough), but it probably
|
|
will not work for hardware flow control. Such a cable may be labeled
|
|
as a serial printer cable. Only larger computer stores are likely to
|
|
stock such cables. A "modem cable" will not work since the wires go
|
|
straight thru (and don't cross over). See ``Buy or Make'' your own
|
|
cable. Make sure you are connecting to your PC's serial port at the
|
|
male DB25 or the DB9, and not to your parallel port (female DB25).
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
12.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" ).
|
|
|
|
|
|
12.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 file-transfer (null-modem) cable (will
|
|
not work with terminal hardware handshaking; see above):
|
|
|
|
|
|
PC DB9 Terminal DB25
|
|
RxD Receive Data 2 <---- 2 TxD Transmit Data
|
|
TxD Transmit Data 3 ----> 3 RxD Receive Data
|
|
|--> 6 DSR Data Set Ready
|
|
DTR Data Terminal Ready 4 -|--> 8 DCD Carrier Detect
|
|
SG Signal Ground 5 ----- 7 SG Signal Ground
|
|
DCD Carrier Detect 1 <--|
|
|
DSR Data Set Ready 6 <--|- 20 DTR Data Terminal Ready
|
|
RTS Request To Send 7 ----> 5 CTS Clear To Send
|
|
CTS Clear To Send 8 <---- 4 RTS Request To Send
|
|
RI Ring Indicator 9 (not needed)
|
|
|
|
|
|
|
|
(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and
|
|
DB25 connectors!)
|
|
|
|
Here's how to connect two DB9's together (but DTR flow control will
|
|
not work):
|
|
|
|
|
|
PC DB9 DB9
|
|
RxD Receive Data 2 <----- 3 TxD Transmit Data
|
|
TxD Transmit Data 3 -----> 2 RxD Receive Data
|
|
|--> 6 DSR Data Set Ready
|
|
DTR Data Terminal Ready 4 --|--> 1 DCD Carrier Detect
|
|
GND Signal Ground 5 ------ 5 GND Signal Ground
|
|
DCD Carrier Detect 1 <--|
|
|
DSR Data Set Ready 6 <--|-- 4 DTR Data Terminal Ready
|
|
RTS Request To Send 7 -----> 8 CTS Clear To Send
|
|
CTS Clear To Send 8 <----- 7 RTS Request To Send
|
|
RI Ring Indicator 9 (not used)
|
|
|
|
|
|
|
|
Using the above 2 connections provide full modem control signals and
|
|
seemingly allow one to set "stty -clocal". Then one must turn on the
|
|
terminal first (asserts DTR) before the port may be opened in a normal
|
|
manner by getty, etc. But there is likely to be trouble if you fail
|
|
to turn on the terminal first (see ``Getty Respawning Too Rapidly'').
|
|
For this reason one should use "stty clocal" which is the default
|
|
(ignores modem control lines) and the additional wires in these cables
|
|
then serve no useful purpose.
|
|
|
|
In olden days when it may not have been this easy to ignore modem
|
|
control signals etc, the following "trick" was done for cables that
|
|
lacked conductors for modem control: on your computer side of the
|
|
connector, connect RTS and CTS together, and also connect DSR, DCD and
|
|
DTR together. This way, when the computer needs a certain handshaking
|
|
signal to proceed, it will get it (falsely) from itself.
|
|
|
|
|
|
12.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 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.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
12.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 or file-transfer) cable or a null modem adapter. Make sure
|
|
that the connectors on the cable ends will mate with the connectors on
|
|
the hardware. One may use telephone cable which is at least
|
|
4-conductor (and possibly twisted pair). Shielded, special low-
|
|
capacitance cable computer cable is best.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
|
|
12.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 ??
|
|
|
|
|
|
12.4. Modem Connection
|
|
|
|
By using a terminal-modem combination (without a computer) one may
|
|
dial out to other computers. Up to the mid 1990s in the US, there
|
|
were many "bulletin boards" one could dial out to. Some even provided
|
|
connections to the Internet. But bulletin boards lost out in favor of
|
|
the Internet.
|
|
|
|
|
|
12.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 host computer on this modem may run a
|
|
getty program to enable you to log in.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
12.5. Telnet and ssh
|
|
|
|
Telnet is a program which lets a text terminal (or a PC console)
|
|
connect to a host computer over a network. No serial ports are used
|
|
for the telnet connection. Of course if you are sitting at a real
|
|
text terminal there is a serial connection to your own host. But when
|
|
you run telnet, your host connects to another host via serial-less
|
|
telnet.
|
|
|
|
Telnet uses tcp/ip packets over various networks: the Internet, LANs,
|
|
etc. You run telnet (as a client) and it connects to a telnet server
|
|
on another computer on a network. Then you get a login prompt and log
|
|
in just as if you were directly connected via a cable to a serial
|
|
port.
|
|
|
|
Ssh is "Secure Shell" and is like telnet. At one time it was much
|
|
more secure than the conventional telnet which sent passwords in the
|
|
clear (no encoding). But now (2006) there are packages "telnet-ssl"
|
|
which offer secure telnet. But since telnet was slow in introducing
|
|
security, ssh may have become more popular.
|
|
|
|
Telnet may put each character you type inside a packet and naturally
|
|
there's a lot of overhead with this. But there's an option for
|
|
sending one line at a time. To use telnet as a client, you need to
|
|
have an account on another computer on that runs a telnet server.
|
|
Then you give the telnet command and specify the address of the
|
|
computer that will accept a connection from you.
|
|
|
|
What kind of terminal does telnet emulate? It doesn't. Instead, it
|
|
connects you to a remote computer using whatever kind of terminal you
|
|
are currently using. If you're on a Linux console, it's a terminal of
|
|
type Linux. The remote computer needs to somehow find out what type
|
|
of terminal you're on so it can send the correct escape sequences.
|
|
|
|
So using telnet is much like connecting up a dumb terminal to a serial
|
|
port except that instead of a cable between you and the computer,
|
|
there is a stream of packets flowing over the Internet between you and
|
|
some distant computer.
|
|
|
|
|
|
12.6. Terminal Server Connection
|
|
|
|
12.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.
|
|
|
|
|
|
12.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 once a "terminal server" evolved into a "remote
|
|
access server". It's infrequently been called a "digital terminal
|
|
server". Note that 56k modem service requires that an ISP have a
|
|
digital connection to the phone company.
|
|
|
|
With remote access servers, instead of many individual telephone line
|
|
cables connected to a terminal server, one now finds just a few cables
|
|
with many digitized telephone calls on each cable (multiplexed). The
|
|
multitude of connectors needed for large numbers of terminals or
|
|
modems is no longer present on a remote access server and thus the
|
|
successor to this type of terminal server can't readily serve text-
|
|
terminals anymore.
|
|
|
|
More recently with the advent of thin clients terminals, the term
|
|
"terminal server" was revived to apply to the hosts that served the
|
|
thin clients. Both MS Windows and Linux can serve thin clients.
|
|
|
|
|
|
|
|
12.7. Connector and Adapter Types
|
|
|
|
A connector is more-or-less permanently attached to the end of a cable
|
|
or to a hardware unit. There are two basic types of connectors used
|
|
in serial communications: 1. DB types with pins (DB 9 or DB25) and 2.
|
|
modular telephone-style connectors.
|
|
|
|
An adapter looks about like a connector but it has two ends with pins.
|
|
It is just like a cable that is so short that there is no cable part
|
|
left at all --just different connectors on each end is all that
|
|
remains. The adapter just plugs in to two other connectors on each
|
|
side of it. It allows two incompatible connectors to mate with each
|
|
other by going in between them. Except that even for two connectors
|
|
that will mate with each other, an adapter may be used to connect the
|
|
cable conductors together in other than straight-thru. Obviously, one
|
|
may use a special cable (perhaps homemade) as a substitute for an
|
|
adapter.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
12.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.)
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
|
|
12.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 file-transfer (null-modem) cable has a MMJ connector at
|
|
each end. It connects to the PC using a MMJ-to-DB adapter. This
|
|
adapter plugs into a DB (say 25 pin) connector on the back of the PC
|
|
and the MMJ connecter plugs into it. If you don't have such an
|
|
adapter, you can make a custom cable with a MMJ (or filed RJ)
|
|
connector on one end and a DB connector on the other end.
|
|
|
|
The standard file-transfer (null-modem) cable with two MMJ (or
|
|
RJ11/14) connectors will connect: 1-6, 2-5, and 3-4. Note that such a
|
|
cable supports DTR/DSR flow control which is not supported (yet) by
|
|
Linux. Making up your own standard 6-conductor file-transfer cable is
|
|
very simple if you understand that the ordinary 4-conductor telephone
|
|
cable from the wall to your telephone, used in hundreds of millions of
|
|
homes, is also a file-transfer cable. Find one and wire your cable
|
|
the same way.
|
|
|
|
If you lay such a cable flat on the floor (with no twists) you will
|
|
note that both plugs on the ends have their gold contacts facing up
|
|
(or both facing down). Although it's symmetrical, it is also file-
|
|
transfer if you think about it a bit. One may put a few such cables
|
|
together with inline couplers and everything works OK because each
|
|
inline coupler is also a file-transfer (null-modem) adapter. Two
|
|
file-transfer cables in series result in a straight-thru connection.
|
|
|
|
Here's a custom cable diagram (by Mark Gleaves) for connecting MMJ to
|
|
a 9-pin serial port using RTS/CTS flow control:
|
|
|
|
|
|
|
|
DEC MMJ Linux PC DB9
|
|
Pin Signal Signal Pin
|
|
=== ====== ====== ===
|
|
1 DTR -----------------------|---> DSR 6
|
|
|---> CTS 8
|
|
2 TxD ---------------------------> RxD 2
|
|
3 SG (TxD)--------------------|--- SG 5
|
|
4 SG (RxD)--------------------|
|
|
5 RxD <--------------------------- TxD 3
|
|
6 DSR <-----------------------|--- RTS 7
|
|
|--> DTR 4
|
|
|--> CD 1
|
|
(no connection) RI 9
|
|
|
|
|
|
|
|
12.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 |
|
|
|__. .__| |__. .__|
|
|
|____| |____|
|
|
|
|
|
|
|
|
12.8. Making or Modifying a Cable
|
|
|
|
12.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 were once labeled as "serial
|
|
printer" cables but serial printers are not popular today (2004).
|
|
They also may be labeled as "file-transfer" cables or "PC-to-PC"
|
|
cables. Hardware flow control will work on them for PC-to-PC
|
|
connections (terminal emulation) but not for the DTR flow control used
|
|
by most real text terminals. If Linux supported DTR flow control,
|
|
real terminals would work OK . Make sure the connectors on the cable
|
|
ends will fit the connectors on your computer and terminal.
|
|
|
|
But if you need longer cables to connect up terminals or need hardware
|
|
flow control, how do you get the right cables? The right ready-made
|
|
cables may be difficult to find (you might find them by searching the
|
|
Internet), especially if you want to use a minimum (say 4) of
|
|
conductors. One option is to get them custom made, which is likely to
|
|
be fairly expensive although you might find someone to make them at
|
|
prices not too much higher than ready-made cable (I did).
|
|
|
|
A low-cost alternative is to buy used cables (if you can find them).
|
|
If you get a used terminal, ask if they have a cable for it. Another
|
|
alternative is to make your own. Even if you get used cables, they
|
|
may need some changes to the pin wiring. In either case, this may
|
|
require special tools. Most connectors that come with short cables
|
|
are permanently molded to the cable and can't be rewired but most
|
|
custom-made and homemade cables have connectors that can be rewired.
|
|
One advantage of making your own cable is that the skills you learn
|
|
will come in handy if a cable breaks (or goes bad) or if you need to
|
|
make up another cable in a hurry.
|
|
|
|
|
|
12.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/
|
|
------ -----------------------------------
|
|
|
|
|
|
|
|
12.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 back of the pin.
|
|
|
|
Removing a pin with this tool is a little tricky. These directions
|
|
can be best understood if you have both the tool and wires in front of
|
|
you as you read this. With the tool tip around the wire insert the
|
|
tool as far as it will go into the hole (about 1 1/2 cm. Some tools
|
|
have a mark (such as a tiny hole) on them to indicate how far to
|
|
insert it. The tool tip should have a tapered gap so that you may get
|
|
the tip around the wire by starting it in where the gap is wider than
|
|
the wire. The tool may have 2 tips. The one that is the most
|
|
difficult to get around the wire is also the one that removes the wire
|
|
the easiest since it almost completely envelops the wire.
|
|
|
|
|
|
With the tip properly inserted pull on both the tool and the wire with
|
|
a gentle pull. If it doesn't come out, the tool was likely not
|
|
inserted correctly so either push it in more or twist it to a
|
|
different position (or both). Perhaps you should have used another
|
|
tip that fits tighter around the pin. Using this tool, one may
|
|
readily convert a straight-thru cable to a file-transfer (null-modem)
|
|
cable, etc.
|
|
|
|
There can be problems using the "insertion/extraction" tool. If the
|
|
tools will not insert on the back of the pin, it could be that the pin
|
|
was not neatly crimped to the wire and is sort of square where it
|
|
should be round, etc. If a pin starts to come out but will not pull
|
|
out all the way, the pin may be bent. Look at it under a magnifying
|
|
glass. Straightening a pin with needle-nose pliers may damage the
|
|
gold plating but you may have to straighten it to remove it.
|
|
Sometimes a stuck pin may be pushed out with a thick screwdriver blade
|
|
tip (or the like) but if you push too hard you may gouge the plastic
|
|
hole or bend the pin:.
|
|
|
|
Don't try soldering unless you know what you're doing or have read
|
|
about how to do it.
|
|
|
|
|
|
12.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.
|
|
|
|
|
|
|
|
13. Set-Up (Configure) in General
|
|
|
|
13.1. Intro to Set-Up
|
|
|
|
Configuring (Set-Up) involves both storing a configuration in the non-
|
|
volatile memory of the terminal, and putting commands in start-up
|
|
files (on your hard disk) that will run each time the computer is
|
|
powered on (or possibly only when the run-level changes). This
|
|
section gives an overview of configuring and covers the configuring of
|
|
the essential communication options for both the terminal and the
|
|
computer. The next two major sections cover in detail the
|
|
configuration of the terminal (see ``Terminal Set-Up'' and the
|
|
computer (see ``Computer Set-Up (Configure) Details''.
|
|
|
|
|
|
13.2. Terminal Set-Up (Configure) Overview
|
|
|
|
When a terminal is installed it's necessary to configure the physical
|
|
terminal by saving (in its non-volatile memory which is not lost when
|
|
the terminal is powered off) the characteristics it will have when it
|
|
is powered on. You might be lucky and have a terminal that has
|
|
already been set-up correctly for your installation so that little or
|
|
no terminal configuration is required.
|
|
|
|
There are two basic ways of configuring a terminal. One is to sit at
|
|
the terminal and go thru a series of set-up menus. Another is to send
|
|
escape sequences to it from the host computer. Before you can send
|
|
anything to the terminal (such as the above escape sequences), its
|
|
``Communication Interface'' options such as the baud rate must be set
|
|
up to match those of the computer. This can only be done by sitting
|
|
at the terminal since the communications must be set up right before
|
|
the computer and the terminal can "talk" to each other. See
|
|
``Terminal Set-Up''.
|
|
|
|
|
|
13.3. Computer Set-Up (Configure) Overview
|
|
|
|
Besides possibly sending escape sequences from the computer to
|
|
configure the terminal, there is the configuring of the computer
|
|
itself to handle the terminal. If you're lucky, all you need to do is
|
|
to put a "getty" command in the /etc/inittab file so that a "login:"
|
|
prompt will be sent to the terminal when the computer starts up. See
|
|
the section ``Getty (used in /etc/inittab)'' for details.
|
|
|
|
The computer communicates with the terminal using the serial device
|
|
driver software (part of the kernel). The serial device driver has a
|
|
default configuration and is also partly (sometimes fully) configured
|
|
by the getty program before running "login" at each terminal.
|
|
However, additional configuration is sometimes needed using programs
|
|
named "stty" and "setserial". These programs (if needed) must be run
|
|
each time the computer starts up since this configuration is lost each
|
|
time the computer powers down. See ``Computer Set-Up (Configure)
|
|
Details''.
|
|
|
|
|
|
13.4. Many Options
|
|
|
|
There are a great many configuration options for you to choose from.
|
|
The communication options must be set right or the terminal will not
|
|
work at all. Other options may be set wrong, but will cause no
|
|
problem since the features they set may not be used. For example, if
|
|
you don't have a printer connected to the terminal it makes no
|
|
difference how the printer configuration parameters are set inside the
|
|
terminal. This last statement is not 100% correct. Suppose that you
|
|
have no printer but the computer (by mistake) sends the terminal a
|
|
command to redirect all characters (data) from the computer to the
|
|
printer only. Then nothing will display on the screen and your
|
|
terminal will be dead. Some terminals have a configuration option to
|
|
inform the terminal that no printer is attached. In this case the
|
|
terminal will ignore any command to redirect output to the "printer"
|
|
and the above problem will never happen. However, this doesn't help
|
|
much since there are many other erroneous commands that can be sent to
|
|
your terminal that will really foul things up. This is likely to
|
|
happen if you send the terminal a binary file by accident.
|
|
|
|
In some cases a wrong setting will not cause any problem until you
|
|
happen to run a rare application program that expects the terminal to
|
|
be set a certain way. Other options govern only the appearance of the
|
|
display and the terminal will work fine if they are set wrong but may
|
|
not be as pleasant to look at.
|
|
|
|
Some options concern only the terminal and do not need to be set at
|
|
the computer. For example: Do you want black letters on a light
|
|
background? This is easier on the eyes than a black background.
|
|
Should a key repeat when held down? Should the screen wrap when a
|
|
line runs off the right end of the screen? Should keys click?
|
|
|
|
|
|
13.5. Communication Interface Options
|
|
|
|
Some of these communication settings (options) are for both the
|
|
terminal and the computer and they must be set exactly the same for
|
|
both: speed, parity, bits/character, and flow control. Other
|
|
communication options are only set at the terminal (and only a couple
|
|
of these are essential to establish communications). Still others
|
|
such as the address and interrupt (IRQ) of the physical port ttyS2 are
|
|
set only at the computer using the "setserial" command. Until all of
|
|
the above essential options are compatibly set up there can be no
|
|
satisfactory serial communication (and likely no communication at all)
|
|
between the terminal and the computer. For the terminal, one must set
|
|
these options manually by menus at each terminal (or by using some
|
|
sort of special cartridge at each terminal). The host computer is
|
|
configured by running commands each time the computer is powered up
|
|
(or when people log in). Sometimes the getty program (found in the
|
|
/etc/inittab file) which starts the login process will take care of
|
|
this for the computer. See ``Getty (used in /etc/inittab)''
|
|
|
|
The settings for both the computer and the terminal are:
|
|
|
|
· ``Speed (bits/second) ''
|
|
|
|
· ``Parity''
|
|
|
|
· ``Bits per Character ''
|
|
|
|
· ``Flow Control ''
|
|
|
|
Some essential settings for the terminal alone are:
|
|
|
|
· ``Port Select''
|
|
|
|
· Set communication to full duplex (=FDX on Wyse terminals)
|
|
|
|
If the ``Getty (used in /etc/inittab)'' program can't set up the
|
|
computer side the way you want, then you may need to use one (or both)
|
|
of the ``Stty & Setserial'' commands.
|
|
|
|
|
|
13.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.
|
|
|
|
|
|
13.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.
|
|
|
|
|
|
13.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.
|
|
|
|
|
|
|
|
13.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.
|
|
|
|
|
|
13.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).
|
|
|
|
|
|
13.6. Quick Attempt
|
|
|
|
While all the above may seem overly complex, to get a terminal working
|
|
is often fairly simple. The ``Quick Install'' section describes a
|
|
simple way to try to do this. But if that doesn't work or if you want
|
|
to make the display look better and perform better, more reading will
|
|
be needed.
|
|
|
|
|
|
14. Terminal Set-Up (Configure) Details
|
|
|
|
Except for the next subsection on sending escape sequences to the
|
|
terminal, this section mainly presents the details of setting up the
|
|
terminal manually by sitting at the terminal and going thru menus. If
|
|
you haven't already done so, you should read ``Terminal Set-Up
|
|
(Configure) Overview''. It's best if you have a terminal manual, but
|
|
even it you don't there is information here on many of the options
|
|
which you might possibly need to set.
|
|
|
|
The communication parameters such as its baud rate must always be set
|
|
up at the terminal since if this is not done there can be no
|
|
communication with the terminal. Once communication is established
|
|
you have two choices for doing the rest of the terminal configuration.
|
|
You may continue to configure manually at the terminal and save the
|
|
results in the terminal's non-volatile memory or you may do this by
|
|
sending escape sequences to the terminal from the computer each time
|
|
the terminal is powered on (or the like).
|
|
|
|
If you know how to set up and save a good configuration inside the
|
|
terminal it may be the best way. If you don't, you might want to just
|
|
send the init string from terminfo to your terminal each time you use
|
|
the terminal. Perhaps doing nothing will still give you a usable
|
|
terminal. You (or an application program) can always change things by
|
|
sending certain escape sequences to the terminal.
|
|
|
|
|
|
14.1. Send Escape Sequences to the Terminal
|
|
|
|
Once the communication interface is established, the rest of the
|
|
configuration of the terminals may sometimes be done by sending escape
|
|
sequences to the terminals from the computer. If you have a large
|
|
number of terminals, it may be worthwhile to write (or locate) a shell
|
|
script to automatically do this. There may (or may not) be a command
|
|
you can send to a terminal to tell it to save its current set-up in
|
|
its non-volatile memory so that it will be present the next time the
|
|
terminal is powered on.
|
|
|
|
There is an simple way to send these escape sequences and a complex
|
|
way. Using the simple way, you never look up escape sequences but
|
|
issue commands that automatically find an appropriate escape sequence
|
|
in the terminfo database and send that. Unfortunately, not all the
|
|
escape sequences which you might want to send are always in the
|
|
terminfo database. Thus the more complex (but possibly better) way is
|
|
to directly send escape sequences.
|
|
|
|
For this complex method you'll need an advanced manual. Old terminal
|
|
manuals once included a detailed list of escape sequences but newer
|
|
ones usually don't. To find them you may need to purchase another
|
|
manual called the "programmers manual" (or the like) which is not
|
|
supplied with the terminal. A ``Esc Sequence List'' for some
|
|
terminals is on the Internet but it's terse and likely incomplete.
|
|
|
|
Even without a manual or the like, you may still send commands to
|
|
configure the terminal by using the programs "tput" and "setterm".
|
|
See ``Changing the Terminal Settings''. You could just send the
|
|
terminal an init string from the terminfo entry if the init string
|
|
sets up the terminal the way want it. See ``Init String''. Unless
|
|
you plan to have these sequences sent from the computer to the
|
|
terminal each time the terminal is powered on, you must somehow save
|
|
the settings in the non-volatile memory of the terminal.
|
|
|
|
|
|
14.2. Older Terminals Set-Up
|
|
|
|
On older terminals look at the keyboard for labels just above the top
|
|
row of numeric keys. If they exist, these labels may be what these
|
|
keys do in set-up mode. Some older terminals may have only one "set-
|
|
up" menu. Still older ones have physical switches. In some cases not
|
|
all the switches are well labeled but they may be well concealed. Of
|
|
course, if you set something with a switch, it's "saved" and there is
|
|
no need to save the setting in non-volatile memory.
|
|
|
|
|
|
14.3. Getting Into Set-Up (Configuration) Mode
|
|
|
|
To select options (configure) at the terminal, you must first enter
|
|
"set-up" mode and then select options (i.e. configure) using menus
|
|
stored inside the terminal and displayed on the screen. To do this,
|
|
the terminal does not even need to be connected to a computer. How to
|
|
get into set-up mode is covered in the terminal's manual, but here's
|
|
some hints that may help:
|
|
|
|
If there's a "set-up" key try pressing it. Also try it shifted.
|
|
|
|
· Wyse: First try the shifted "Select" key; then substitute Ctrl for
|
|
shifted in all of the above.
|
|
|
|
· VT, Dorio: F3 may be the set-up key. On VT420 and later models
|
|
this key may have been programmed to do something else so turn off
|
|
the power. When you turn on the power again, hit the F3 key as
|
|
soon as you get an initial screen message.
|
|
|
|
· IBM: 3151: Ctrl-ScrollLock. 3153: Ctrl-Minus_on_Keypad (or like
|
|
3151)
|
|
|
|
To move around in the set-up menus, try the arrow keys. Use Return,
|
|
Space, or a special key ("toggle" on old terminals) to select. To
|
|
exit set-up mode select exit from a menu (or on some older terminals
|
|
press the set-up key again).
|
|
|
|
|
|
14.4. Communication Options
|
|
|
|
For the terminal to work at all, speed, parity, :its/character, and
|
|
communication mode must be set correctly. Incorrect flow control may
|
|
cause loss and/or corruption of data seen on the screen. The essential
|
|
communication options were dealt with (for both the terminal and
|
|
computer) in another section: See ``Communication Interface''. The
|
|
following list provides some links to that section, as well as some
|
|
additional communication options set only at the terminal.
|
|
|
|
|
|
· ``Speed (bits/second) '' (baud rate): 9600, 19200, etc.
|
|
|
|
· ``Parity'' none, even, odd, mark, space
|
|
|
|
· ``Bits per Character '' {Data}: 7 or 8
|
|
|
|
· ``Flow Control:'' or Handshake {Hndshk}: none, Xon-Xoff, or
|
|
hardware (DTR, etc).
|
|
|
|
· 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} ?
|
|
|
|
|
|
14.5. Saving the Set-up
|
|
|
|
Your set-up must be saved in the non-volatile memory of the terminal
|
|
so that it will be effective the next time you turn on the terminal.
|
|
If you fail to save it, then the new settings will be lost when you
|
|
turn off the terminal. Before you go to the trouble of setting up a
|
|
terminal, make sure that you know how to save the settings. For
|
|
modern terminals the save command is done via a menu. In some older
|
|
terminals, only the manual tells how to save. For many of these you
|
|
press Ctrl-S to save.
|
|
|
|
|
|
14.6. Set-Up Options/Parameters
|
|
|
|
What follows in this section describes some of the options which are
|
|
available in the set-up menus of many terminals. Options are also
|
|
called parameters or features. Many options may be called "modes".
|
|
Setting options is often called "configuring". Many of these options
|
|
may also be set by sending certain escape sequences to the terminal.
|
|
Different models and brands of terminals have various options and the
|
|
same option may be called by different names (not all of which are
|
|
given here) Terse names used by Wyse are enclosed in {...}. Names
|
|
used mostly for VT terminals are enclosed in {{...}}.
|
|
|
|
|
|
14.7. Emulation {Personality} {{Terminal Modes}}
|
|
|
|
Most modern terminals can emulate several other terminals. The
|
|
terminal can likely do more if it is set to emulate itself (actually
|
|
no emulation) {native personality}. Sometimes there are 2 different
|
|
emulations for the same model of terminal. For example VT220-7
|
|
emulates a VT220 with 7-bits/byte while VT220-8 emulates a VT220 with
|
|
8-bits/byte (256 possible characters).
|
|
|
|
Older models of terminals usually have fewer features than newer
|
|
models. Suppose one wanted to emulate an old terminal but also wanted
|
|
some of the advanced capabilities of the later model terminal they are
|
|
sitting at. This is sometimes possible (to some degree). This
|
|
feature is sometimes called {Enhance} (or Enhanced ??).
|
|
|
|
|
|
14.8. Display Options
|
|
|
|
14.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.
|
|
|
|
|
|
14.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''
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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).
|
|
|
|
|
|
14.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''.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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).
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.9. Page Related Options
|
|
|
|
For a Wyse terminal to be able to access multiple pages of display
|
|
memory {Multipage} must be set to on.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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".
|
|
|
|
|
|
14.10. Reporting and Answerback
|
|
|
|
The terminal will identify itself and its state, or send out a pre-
|
|
recorded message in response to certain escape sequences.
|
|
|
|
|
|
14.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).
|
|
|
|
|
|
14.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 ??
|
|
|
|
|
|
14.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).
|
|
|
|
|
|
14.10.4. Terminal ID {ANSI ID}
|
|
|
|
The terminal sends this reply in answer to a request for identity.
|
|
|
|
|
|
14.11. Keyboard Options
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.).
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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''
|
|
|
|
|
|
14.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 ??
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.12. Meaning of Received Control Codes
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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''
|
|
|
|
|
|
14.13. Where New Text Goes
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.14. Function Keys
|
|
|
|
These are the keys labeled F1, F2, etc. On older terminals they may
|
|
be labeled PF1, PF2, etc. where the P stands for Programmable. Some
|
|
keyboards have both. One may program (redefine) these keys to send
|
|
out a string of user-defined bytes. This doesn't work for older
|
|
terminals such as vt100 or for the Linux command-line interface (how
|
|
sad). They may often be easily "programmed" using a certain set-up
|
|
menu {FKey}. On some terminals, one may also specify where this
|
|
string is sent to when the key is pressed. In "normal" mode, pressing
|
|
the key is just like typing the string at the keyboard. In "local"
|
|
mode pressing the key sends it to the terminal (just like if the
|
|
terminal was in local mode). This may be used to send escape
|
|
sequences to the terminal so as to configure it in a special way. In
|
|
"remote" mode, the string is always sent out the serial port to the
|
|
host computer (even if the terminal is in local mode).
|
|
|
|
|
|
14.15. Block Mode Options
|
|
|
|
Some options are only for the case of ``Block Mode''. This option is
|
|
powerful since it provides forms and takes load off the host computer
|
|
by transmitting in bursts. But it's more complicated to set up and is
|
|
thus not used too much.
|
|
|
|
|
|
14.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)
|
|
|
|
|
|
14.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}
|
|
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.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.
|
|
|
|
|
|
14.16. Locks
|
|
|
|
There are various types of Locks. One is the Locked keyboard due to
|
|
flow control. See ``Keyboard Lock'' Another lock {Feature Lock} is
|
|
that which prohibits the host computer from changing the terminal set-
|
|
up by sending certain escape sequences to the terminal. Placing such
|
|
a lock may result in unexpected behavior as application programs send
|
|
escape sequences to the terminals that are ignored. Not all set-up
|
|
parameters lock. Unless you have a good reason to do so, you should
|
|
not enable such locking.
|
|
|
|
A Function Key lock will prohibit the computer from redefining what a
|
|
programmable function key sends. You may want to use this if you have
|
|
something important programmed into the function keys.
|
|
|
|
|
|
14.17. Screen Saver {Scrn Saver}
|
|
|
|
Also called "CRT Saver". This turns off (or dims) the screen after
|
|
the terminal is not used for a period of time. It may prolong the
|
|
life of the screen and save some energy. Hitting any key will usually
|
|
restore the screen and may "execute" that key so it's best to hit the
|
|
shift-key, etc.
|
|
|
|
|
|
14.18. Printer
|
|
|
|
For Wyse, if there is no {Printer Attached} set it to Off. It's not
|
|
essential to do this, but if you do it any escape sequence to send
|
|
text to the printer (instead of the terminal) will be ignored.
|
|
|
|
Setting up the printer port is about the same (usually simpler) as
|
|
setting up the communications on the main port. There are a couple of
|
|
options specific to the printer. Is the printer a serial or parallel
|
|
printer? If it's parallel it should be designated as such in setup
|
|
and connected to the parallel port on the terminal (if there is one).
|
|
Should a FF (form feed) be sent to the printer at the end of a print
|
|
job? If {Print Term} is set to FF, this will happen.
|
|
|
|
|
|
15. Computer Set-Up (Configure) Details
|
|
|
|
There are various files to edit to set up the computer for terminals.
|
|
If you're lucky, you'll only need to edit /etc/inittab. One does this
|
|
by editing at the console (or from any working terminal).
|
|
|
|
|
|
15.1. Getty (used in /etc/inittab)
|
|
|
|
|
|
|
|
15.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): Easy to set up with no
|
|
config required. See ``agetty''
|
|
|
|
2. ``getty (part of getty_ps)'' More advanced with config file.
|
|
|
|
Two gettys best for dial-in modems (avoid for directly connected
|
|
terminals) are:
|
|
|
|
1. mgetty: the best one for modems; works for terminals too but
|
|
inferior
|
|
|
|
2. uugetty: for modems only; part of the getty_ps package
|
|
|
|
Simple gettys to use if you don't use a real text-terminal. Most
|
|
Linux users use one of these at their monitor:
|
|
|
|
1. mingetty
|
|
|
|
2. fbgetty
|
|
|
|
3. fgetty
|
|
|
|
4. rungetty
|
|
|
|
Your Linux distribution may come with either getty_ps or agetty for
|
|
text-terminals. Some distributions supply neither. Unfortunately,
|
|
they often just call it "getty". If you need to determine which one
|
|
you have look at the man page for "getty". As of 2007 agetty (in the
|
|
"util-linux package) seems to be more widely used then getty_ps which
|
|
was at: getty_ps
|
|
<http://rpmfind.net/linux/rpm2html/search.php?query=getty_ps&subm>
|
|
|
|
As a last resort to try to determine which getty you have, you might
|
|
check out its executable code (usually in /sbin). getty_ps has
|
|
/etc/gettydefs embedded in this code. To search for it, go to /sbin
|
|
and type:
|
|
strings getty | grep getty
|
|
If getty is actually agetty the above will result in nothing. However
|
|
if you have agetty typing:
|
|
getty -h
|
|
|
|
The source codes for various gettys may be downloaded from Getty
|
|
Software <http://ibiblio.org/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.
|
|
15.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).
|
|
|
|
|
|
|
|
15.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 tty1. Other programs run at ttyS1 may inherit this
|
|
standard input/output (which is connected to ttyS1) and everything is
|
|
OK. But some programs may make the mistake of trying to read from
|
|
their controlling terminal (tty1) which is wrong. Now tty1 may think
|
|
that these programs are being run in the background by tty1 so an
|
|
attempt to read from tty1 (it should have been ttyS1) results in
|
|
stopping the process that attempted to read. (A background process is
|
|
not allowed to read from its controlling terminal.). You may see a
|
|
message something like: "[1]+ Stopped" on the screen. At this point
|
|
you are stuck since you can't interact with a process which is trying
|
|
to communicate with you via the wrong terminal. Of course to escape
|
|
from this you can go to another terminal and kill the process, etc.
|
|
15.1.4. agetty (may be named getty)
|
|
|
|
agetty means "alternative getty" and it was an easier-to-use
|
|
alternative to the original getty (getty_ps).
|
|
An example line in /etc/inittab:
|
|
|
|
|
|
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
|
|
|
|
|
|
|
|
S1 is from ttyS1. 23 means that getty is run upon entering run levels
|
|
2 or 3. respawn means that if getty (or a process that replaced it
|
|
such as bash) is killed, getty will automatically start up (respawn)
|
|
again. /sbin/getty is the getty command. The -L means Local (ignore
|
|
modem control signals). -h (not shown in the example) enables 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.
|
|
|
|
|
|
15.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.
|
|
|
|
|
|
15.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.
|
|
|
|
|
|
15.1.5. getty (part of getty_ps)
|
|
|
|
The name has often been misspelled as ps_getty. (Most of this is from
|
|
the old Serial-HOWTO by Greg Hankins)
|
|
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.
|
|
|
|
|
|
15.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
|
|
|
|
|
|
|
|
15.2. Stty & Setserial
|
|
|
|
There is both a "stty" command and a "setserial" command for setting
|
|
up the serial ports. Some (or all) of the needed stty settings can
|
|
be done via getty and there may be no need to use setserial so you may
|
|
not need to use either command. These two commands (stty and
|
|
setserial) set up different aspects of the serial port. Stty does the
|
|
most while setserial configures the low-level stuff such as interrupts
|
|
and port addresses. To "save" the settings, these commands must be
|
|
written in certain files (shell scripts) which run each time the
|
|
computer starts up. Distributions of Linux often supply a shell
|
|
script which runs setserial but seldom supply one which runs stty
|
|
since on seldom need it.
|
|
|
|
|
|
15.3. Setserial
|
|
|
|
This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There are
|
|
some minor differences, depending on which HOWTO it appears in.
|
|
|
|
|
|
15.3.1. Setserial problems with linmodems, laptops
|
|
|
|
|
|
If you have a Laptop (PCMCIA) don't use setserial until you read
|
|
``Laptops: PCMCIA''.
|
|
|
|
|
|
15.3.2. Introduction
|
|
|
|
setserial is a program used for the user to communicate with the
|
|
serial device driver. You normally never need to use it, provided
|
|
that you only use the one or two serial ports that come as standard
|
|
equipment with a PC. Even in other cases, most extra serial ports
|
|
should be auto-detected by modern kernels. Except you'll need to use
|
|
setserial if you have an obsolete ISA serial port set by jumpers on
|
|
the physical hardware or if your kernel (such as 2.2 or older) doesn't
|
|
both detect and set your add-on PCI serial ports. In some cases the
|
|
setserial program may have been previously used and the wrong serial
|
|
port data has been manually given by the some past user (perhaps by
|
|
you). If setserial hasn't been configured to accept what the kernel
|
|
says, it will override the (likely correct) kernel data with what
|
|
someone previously set.
|
|
|
|
setserial allows you (or a shell script) to talk to the serial
|
|
software. But there's also another program, tt/stty/, that also deals
|
|
with the serial port and is used for setting the port speed, etc.
|
|
setserial is really a misnomer, it doesn't set any information on the
|
|
serial card. Example: it can't change the irq set on the card. More
|
|
details on this later
|
|
|
|
setserial deals with the lower-level configuring of the serial port,
|
|
such as dealing with IRQs (such as 5), port addresses (such as 3f8),
|
|
and the like. A major problem with it is that it can't set or
|
|
configure the serial port hardware: It can't set the IRQ or port
|
|
addresses into the hardware. Furthermore, when it seemingly reports
|
|
the configuration of the hardware, it's sometimes wrong since it
|
|
doesn't actually probe the hardware unless you specifically tell it
|
|
to. Even then, it doesn't do the modern type of bus probing and some
|
|
hardware may never be found by it. Still, what it shows is right most
|
|
all the time but if you're having trouble getting a serial port to
|
|
work, then there's a fair chance it's wrong.
|
|
|
|
In olden days, when the IRQ and port address was set by jumpers on the
|
|
serial card, one would use setserial to tell the driver how these
|
|
jumpers were set. Today, when plug-and-play methods detect how the
|
|
jumperless serial port is set, setserial is not really needed anymore
|
|
unless you're having problems or using old hardware. Furthermore, if
|
|
the configuration file used by setserial is wrong, then there's
|
|
trouble. In this case, if you use setserial to try to find out how
|
|
the port is configured, it may just repeat the incorrect information
|
|
in the setserial configuration file.
|
|
|
|
setserial can sometimes be of help to find a serial port. But it's
|
|
only of use if you know the port address and use the right options.
|
|
For modern ports, there's usually better ways to look for them by
|
|
plug-and-play methods.
|
|
|
|
Thus the name setserial is somewhat of a misnomer since it doesn't set
|
|
the I/O address nor IRQ in the hardware, it just "sets" them in the
|
|
driver software. And the driver naively believes that what setserial
|
|
tells it, even if it conflicts with what the driver has found by using
|
|
plug-and-play methods. Too bad that it fails to at least issue a
|
|
warning message for setserial such a conflict. Since the device
|
|
driver is considered to be part of the kernel, the word "kernel" is
|
|
often used in other documentation with no mention made of any "serial
|
|
driver".
|
|
|
|
Some distributions (and versions) set things up so that setserial is
|
|
run at boot-time by an initialization shell script (in the /etc
|
|
directory tree). But the configuration file which this script uses
|
|
may be either in the /etc tree or the /var tree. In some cases, if
|
|
you want setserial to run at boot-time, you may have to take some
|
|
action. setserialwill not work without either serial support built
|
|
into the kernel or loaded as a module. The module may get loaded
|
|
automatically if you (or a script) attempt to use setserial.
|
|
|
|
While setserial can be made to probe the hardware IO port addresses to
|
|
try to determine the UART type and IRQ, this has severe limitations.
|
|
See ``Probing''. It can't set the IRQ or the port address in the
|
|
hardware of PnP or PCI serial ports (but the plug-and-play features of
|
|
the serial driver may do this). It also can't directly read the PnP
|
|
data stored in configuration registers in the hardware. But since the
|
|
device driver can read these registers and setserial tells you what
|
|
the device driver thinks, it might be correct. Or it could be telling
|
|
you what setserial had previously (and perhaps erroneously) told the
|
|
driver. There's no way to know for sure without doing some other
|
|
checks.
|
|
|
|
The serial driver (for Linux Kernels 2.4 and 2.6) looks for a few
|
|
"standard" legacy serial ports, for PnP ports on the ISA bus, and for
|
|
all supported port hardware on the PCI bus. If it finds your ports
|
|
correctly, then there's no need to use setserial unless they have been
|
|
"set" incorrectly in the setserial configuration file. The driver
|
|
doesn't probe for the IRQs of old ISA serial ports set with jumpers on
|
|
the card and may get these wrong.
|
|
|
|
Besides the man page for setserial, check out info in
|
|
/usr/doc/setserial.../ or /usr/share/doc/setserial. This should tell
|
|
you how setserial is handled for your distribution of Linux. While
|
|
setserial behaves the same in all distributions, the scripts for
|
|
running it, how to configure such scripts (including automatic
|
|
configuration), and the names and locations of the script files, etc.,
|
|
are all distribution-dependent. If your serial port is Plug-and-Play
|
|
you may need to consult other HOWTOs such as Plug-and-Play or Serial.
|
|
|
|
|
|
15.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.
|
|
Also changes made by setserial may be stored in setserial's
|
|
configuration file (see the documentation for your distribution, this
|
|
info is not in the man page).
|
|
|
|
|
|
|
|
15.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. In many cases you'll see some ports displayed with what
|
|
appears at first glance to be erroneous IRQs and addresses. But if
|
|
you also see: "UART: unknown" just ignore the entire line since no
|
|
serial port exists at that address.
|
|
|
|
If you add -a to the option -g you will see more info although few
|
|
people need to deal with (or understand) this additional info since
|
|
the default settings you see usually work fine. In normal cases the
|
|
hardware is set up the same way as "setserial" reports. But if you
|
|
are having problems there is a good chance that setserial has it
|
|
wrong. In fact, you can run "setserial" and assign a purely
|
|
fictitious I/O port address, any IRQ, and whatever uart type you would
|
|
like to have. Then the next time you type "setserial ..." it will
|
|
display these bogus values you've supplied to the driver. They will
|
|
also be officially registered with the kernel as displayed (at the top
|
|
of the screen) by the "scanport" command (Debian). Of course the
|
|
serial port driver will not work correctly (if at all) if you attempt
|
|
to use such a port. Thus, when giving parameters to setserial,
|
|
"anything goes". Well almost. If you assign one port a base address
|
|
that is already assigned (such as 3e8) it may not accept it. But if
|
|
you use 3e9 it will accept it. Unfortunately 3e9 is actually assigned
|
|
since it is within the range starting at base address 3e8. Thus the
|
|
moral of the story is to make sure your data is correct before
|
|
assigning resources with setserial.
|
|
|
|
|
|
15.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 configuration file.
|
|
|
|
Where this configuration file resides depends on your distribution.
|
|
Look at the start-up scripts somewhere in the /etc/ tree (such as
|
|
/etc/init.d/ or /etc/rc.d/) and read the startup script for "serial"
|
|
or "setserial" or the like. It should show where the configuration
|
|
file(s) reside. In Debian there are 4 options for use of this
|
|
configuration file:
|
|
|
|
|
|
1. Don't use this file at all. At each boot, the serial driver alone
|
|
detects the ports and setserial doesn't ever run. ("kernel"
|
|
option)
|
|
|
|
2. Save what setserial reports when the system is first shutdown and
|
|
put it in the configuration file. After that, don't ever make any
|
|
changes to the configuration file, even if someone has made changes
|
|
by running the setserial command on the command line and then shuts
|
|
down the system. ("autosave-once" option)
|
|
|
|
3. At every shutdown, save whatever setserial detects to the
|
|
configuration file. ("autosave" option)
|
|
|
|
4. Manually edit the configuration file to set the configuration.
|
|
Don't ever do any automatic saves to it. ("manual" option)
|
|
|
|
In olden days (perhaps before 2000), there wasn't any configuration
|
|
file and the configuration was manually set (hard coded) inside the
|
|
shell script that ran setserial. See ``Edit a script (prior to
|
|
version 2.15)''.
|
|
|
|
|
|
15.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.
|
|
A problem is where the software looks for a port at specified I/O
|
|
addresses. Prior to probing with "setserial", one may run the
|
|
"scanport" (Debian) command to check all possible ports in one scan.
|
|
It makes crude guesses as to what is on some ports but doesn't
|
|
determine the IRQ. It's a fast first start. It may hang your PC but
|
|
so far it's worked fine for me. Note that non-Debian distributions
|
|
don't seem to supply "scanport". Is there another scan program?
|
|
|
|
With appropriate options, setserial can probe (at a given I/O address)
|
|
for a serial port but you must guess the I/O address. If you ask it
|
|
to probe for /dev/ttyS2 for example, it will only probe at the address
|
|
it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2 is at a
|
|
different address, then it will probe at that address, etc. See
|
|
``Probing''
|
|
|
|
The purpose of such probing is to see if there is a uart there, and if
|
|
so, what its IRQ is. Use setserial mainly as a last resort as there
|
|
are faster ways to attempt it such as wvdialconf to detect modems,
|
|
looking at very early boot-time messages, or using pnpdump --dumpregs,
|
|
or lspci -vv. But if you want to detect hardware with setserial use
|
|
for example :
|
|
/dev/ttyS2 -v autoconfig
|
|
If the resulting message shows a uart type such as 16550A, then you're
|
|
OK. If instead it shows "unknown" for the uart type, then there is
|
|
supposedly no serial port at all at that I/O address. Some cheap
|
|
serial ports don't identify themselves correctly so if you see
|
|
"unknown" you still might have a serial port there.
|
|
|
|
Besides auto-probing for a uart type, setserial can auto-probe for
|
|
IRQ's but this doesn't always work right either. In one case it first
|
|
gave the wrong irq but when the command was repeated it found the
|
|
correct irq. In versions of setserial >= 2.15, the results of your
|
|
last probe test could be automatically saved and put into a
|
|
distribution-specific configuration file such as /etc/serial.conf or
|
|
/etc/sysconfig/serial or /var/lib/setserial/autoserial.conf for
|
|
Debian. This will be used next time you start Linux.
|
|
|
|
It may be that two serial ports both have the same IO address set in
|
|
the hardware. Of course this is not normally permitted for the ISA
|
|
bus but it sometimes happens anyway. Probing detects one serial port
|
|
when actually there are two. However if they have different IRQs,
|
|
then the probe for IRQs may show IRQ = 0. For me, it only did this if
|
|
I first used setserial to give the IRQ a fictitious value.
|
|
|
|
|
|
15.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 somewhere such as /etc/serial.conf (or autoserial.conf or
|
|
serial) when you shutdown. So if it worked OK (and solved your
|
|
problem) then there's no need to modify any configuration file. See
|
|
``Configuration method using /etc/serial.conf, etc.''.
|
|
15.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 was reported that other processes may try to open the serial port
|
|
before rc.local ran resulting in serial communication failure. Later
|
|
on it most likely was found in /etc/init.d/ but wasn't normally
|
|
intended to be edited.
|
|
|
|
If such a file was supplied, it likely contained a number of
|
|
commented-out examples. By uncommenting some of these and/or
|
|
modifying them, you could set things up correctly. It was important
|
|
use a valid path for setserial, and a valid device name. You could do
|
|
a test by executing this file manually (just type its name as the
|
|
super-user) to see if it works right. Testing like this was a lot
|
|
faster than doing repeated reboots to get it right.
|
|
|
|
For versions >= 2.15 (provided your distribution implemented the
|
|
change, Redhat didn't at first) it may be more tricky to do since the
|
|
file that runs setserial on startup, /etc/init.d/setserial or the like
|
|
was not intended to be edited by the user. See ``Configuration method
|
|
using /etc/serial.conf, etc.''.
|
|
|
|
An example line in such a script was:
|
|
|
|
|
|
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
|
|
|
|
|
|
|
|
or, if you wanted setserial to automatically determine the uart and
|
|
the IRQ for ttyS3 you would have used something like this:
|
|
|
|
|
|
|
|
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
|
|
|
|
|
|
|
|
This was done for every serial port you wanted to auto configure,
|
|
using a device name that really does exist on your machine. In some
|
|
cases it didn't work right due to the hardware.
|
|
|
|
|
|
15.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)''. This was simple, but the
|
|
simple and clear method has been changed to something that is
|
|
unnecessarily complex. Today the script and configuration file are
|
|
two different files instead of one. This shell-script is not edited
|
|
but gets its data from a configuration file such as /etc/serial.conf
|
|
(or /var/lib/setserial/autoserial.conf).
|
|
|
|
Furthermore you may not even need to edit serial.conf (or the like)
|
|
because using the "setserial" command on the command line may
|
|
automatically cause serial.conf to be edited appropriately. This was
|
|
done so that you may not need to edit any file in order to set up (or
|
|
change) what setserial does each time that Linux is booted.
|
|
|
|
What often happens is this: When you shut down your PC the script
|
|
that ran "setserial" at boot-time is run again, but this time it only
|
|
does what the part for the "stop" case says to do: It uses
|
|
"setserial" to find out what the current state of "setserial" is, and
|
|
it puts that info into the serial configuration file such as
|
|
serial.conf. Thus when you run "setserial" to change the serial.conf
|
|
file, it doesn't get changed immediately but only when and if you shut
|
|
down normally.
|
|
|
|
Now you can perhaps guess what problems might occur. Suppose you
|
|
don't shut down normally (someone turns the power off, etc.) and the
|
|
changes don't get saved. Suppose you experiment with "setserial" and
|
|
forget to run it a final time to restore the original state (or make a
|
|
mistake in restoring the original state). Then your "experimental"
|
|
settings are saved. And worst of all, unless you know which options
|
|
were set in the configuration file, you don't know what will happen.
|
|
One option in Debian (and likely other distributions) is known as
|
|
"AUTOSAVE-ONCE" which saves changes only for the first time you make
|
|
them with the setserial command.
|
|
|
|
If the option "###AUTOSAVE###" is set and you manually edit
|
|
serial.conf, then your editing is destroyed when you shut down because
|
|
it gets changed back to the state of setserial at shutdown. There is
|
|
a way to disable the changing of serial.conf at shutdown and that is
|
|
to remove "###AUTOSAVE###" or the like from first line of serial.conf.
|
|
In the Debian distribution, the removal of "###AUTOSAVE###" from the
|
|
first line was once automatically done after the first time you
|
|
shutdown just after installation. To retain this effect the
|
|
"AUTOSAVE-ONCE" option was created which only does a save when time
|
|
the system is shut down for the first time (just after you install or
|
|
update the setserial program).
|
|
|
|
The file most commonly used to run setserial at boot-time (in
|
|
conformance with the configuration file) is now /etc/init.d/setserial
|
|
(Debian) or /etc/init.d/serial (Redhat), or etc., but it should not
|
|
normally be edited. For 2.15, Redhat 6.0 just had a file
|
|
/usr/doc/setserial-2.15/rc.serial which you have to move to
|
|
/etc/init.d/ if you want setserial to run at boot-time.
|
|
|
|
To disable a port, use setserial to set it to "uart none". This will
|
|
not be saved. The format of /etc/serial.conf appears to be just like
|
|
that of the parameters placed after "setserial" on the command line
|
|
with one line for each port. If you don't use autosave, you may edit
|
|
/etc/serial.conf manually.
|
|
|
|
In order to force the current settings set by setserial to be saved to
|
|
the configuration file (serial.conf) without shutting down, do what
|
|
normally happens when you shutdown: Run the shell-script
|
|
/etc/init.d/{set}serial stop. The "stop" command will save the
|
|
current configuration but the serial ports still keep working OK.
|
|
|
|
In some cases you may wind up with both the old and new configuration
|
|
methods installed but hopefully only one of them runs at boot-time.
|
|
Debian labeled obsolete files with "...pre-2.15".
|
|
|
|
|
|
15.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
|
|
compiled in support for this, and 3. your serial hardware supports it.
|
|
See Serial-HOWTO: Interrupt sharing and Kernels 2.2+.
|
|
|
|
|
|
If you only have two serial ports, ttyS0 and ttyS1, you're still OK
|
|
since IRQ sharing conflicts don't exist for non-existent devices.
|
|
|
|
If you add a legacy internal modem (without plug-and-play) and retain
|
|
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
|
|
it in your serial port (or modem card) and then use setserial to
|
|
assign it to your device driver. If IRQ 5 is not being used for a
|
|
sound card, this could be used for a modem.
|
|
|
|
|
|
15.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.
|
|
|
|
|
|
|
|
15.4. Stty
|
|
|
|
15.4.1. Introduction
|
|
|
|
stty does much of the configuration of the serial port but since
|
|
application programs (and the getty program) often handle this, you
|
|
may not need to use it much. It's handy if you're having problems or
|
|
want to see how the port is set up. It also configures the terminal
|
|
interface which is not only used by the serial port but is also used
|
|
anytime you use a command-line interface in Linux. Try typing ``stty
|
|
-a'' at your terminal/console to see how it's now set. Also try
|
|
typing it without the -a (all) for a short listing which shows how
|
|
it's set different than "normal" which is how it's set using the
|
|
command "stty sane". Don't try to learn all the settings unless you
|
|
want to become a serial historian since many of the settings are only
|
|
for slow antique dumb terminals of the 1970's. Most of the defaults
|
|
should work OK.
|
|
|
|
stty is documented in the man pages with a more detailed account in
|
|
the info pages. Type "man stty" or "info stty".
|
|
|
|
Many of the stty options (or settings) start with an "o" (output) or
|
|
an "i" (input). For example: onlcr. Output is the flow of bytes out
|
|
of the computer while input is the flow of bytes into the computer.
|
|
The "point of view" is the computer, not the serial port or the device
|
|
connected to the serial port. For example, received input data comes
|
|
in on a cable and goes to the serial port chip. This chip, after
|
|
converting the bits from the serial to parallel representation, then
|
|
sends it (via a program read) to the large serial port buffer in main
|
|
computer memory. Thus the chip has both input and output but since
|
|
it's input data to the computer, its output is considered to be input.
|
|
The situation is similar for output flowing thru this chip. The
|
|
"input" and "output" refer to the direction of flow with respect to
|
|
the computer and not the serial port hardware (the chip).
|
|
|
|
Whereas setserial only deals with actual serial ports, stty is used
|
|
for terminals regardless of whether they are accesses via a serial
|
|
port, network, or by a virtual terminal on Linux PC monitor, or a GUI
|
|
terminal window such as xterm. For the PC monitor, xterm, or a
|
|
network many of the stty settings are meaningless. Changing the baud
|
|
rate, etc. doesn't appear to actually do anything.
|
|
|
|
Here are some of the items stty configures: speed (bits/sec), parity,
|
|
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
|
|
control, break signal, end-of-line markers, change case, padding, beep
|
|
if buffer overrun?, echo what you type to the screen, allow background
|
|
tasks to write to terminal?, define special (control) characters (such
|
|
as what key to press for interrupt). See the stty man or info page
|
|
for more details. Also see the man page: termios which covers the
|
|
same options set by stty but (as of mid 1999) covers features which
|
|
the stty man page fails to mention. For use of some special
|
|
characters see ``Special (Control) Characters''
|
|
|
|
With some implementations of getty (getty_ps package), the commands
|
|
that one would normally give to stty are typed into a getty
|
|
configuration file: /etc/gettydefs. Even without this configuration
|
|
file, the getty command line may be sufficient to set things up so
|
|
that you don't need stty.
|
|
|
|
One may write C programs which change the stty configuration, etc.
|
|
Looking at some of the documentation for this may help one better
|
|
understand the use of the stty command (and its many possible
|
|
arguments). Serial-Programming-HOWTO may be useful but it's outdated.
|
|
The manual page: termios contains a description of the C-language
|
|
structure (of type termios) which stores the stty configuration in
|
|
computer memory. Many of the flag names in this C-structure are
|
|
almost the same (and do the same thing) as the arguments to the stty
|
|
command.
|
|
|
|
|
|
15.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 restart the flow
|
|
after a flow-control stop. If you stop scrolling with the "stop
|
|
scroll" key (or the like) then hitting any key will resume scrolling.
|
|
It's seldom needed since hitting the "scroll lock" key again will do
|
|
the same thing.
|
|
|
|
ixon: Enables the port to listen for Xoff and to stop transmitting
|
|
when it gets an Xoff. Likewise, it will resume transmitting if it
|
|
gets an Xon.
|
|
|
|
ixoff: enables the port to send the Xoff signal out the transmit line
|
|
when its buffers in main memory are nearly full. It protects the
|
|
device where the port is located from being overrun.
|
|
|
|
For a slow dumb terminal (or other slow device) connected to a fast
|
|
PC, it's unlikely that the PC's port will be overrun. So you seldom
|
|
actually need to enable ixoff. But it's often enabled "just in case".
|
|
|
|
|
|
15.4.3. Using stty at a "foreign" terminal
|
|
|
|
How do you use stty to view or set a terminal other than the terminal
|
|
you are currently using? It's usually impossible to do it if the
|
|
foreign terminal is in use and has a shell running on it. In other
|
|
cases for dealing with say ttyS2 while typing at another terminal
|
|
(such as tty1) use stty -F /dev/ttyS2 ... (or --file instead of F).
|
|
If ... is -a it displays all the stty settings (-a means all).
|
|
|
|
But if the foreign terminal (ttyS2 in this example) has a shell
|
|
running on it, then what you see will likely be deceptive and trying
|
|
to set it will not work. This problem exists for virtual terminals
|
|
also such as dealing with tty3 from tty1, etc. See ``Two interfaces
|
|
at a terminal'' to understand it.
|
|
|
|
|
|
15.4.4. Two interface modes at a terminal
|
|
|
|
When using a shell (such as bash) with command-line-editing enabled
|
|
there are two different terminal interfaces (or line disciplines: what
|
|
you see when you type stty -a). When you type in modern shells at the
|
|
command line you have a temporary "raw" interface (or raw mode) where
|
|
each character is read by the shell's command-line-editor as you type
|
|
it. Once you hit the <return> key, the command-line-editor is exited
|
|
and the terminal interface is changed from raw to the nominal "cooked"
|
|
interface (cooked mode) for the terminal using the stty configuration
|
|
that was used for the last cooked mode (the shell has saved it and it
|
|
gets restored). This cooked mode lasts until the next prompt is sent
|
|
to the terminal (which is only a small fraction of a second) but it
|
|
exists during the execution of the command (or at least during the
|
|
first stage of the command execution). Note that one never gets to
|
|
type any command into this cooked mode but what was typed in raw mode
|
|
on the command line starts execution by the shell while in cooked
|
|
mode.
|
|
|
|
When a prompt is sent to the terminal, the terminal goes from "cooked"
|
|
to "raw" mode (just like it does when you start an editor such as vim.
|
|
The prompt signals starting the command-line editor. The settings for
|
|
the "raw" mode are based only on the basic stty settings taken from
|
|
the "cooked" mode. Raw mode keeps these setting but changes several
|
|
other settings in order to change the mode to "raw". It is not at all
|
|
based on the settings used in the previous "raw" mode (as contrasted
|
|
to "cooked" mode which gets restored by the shell to its previous
|
|
settings). Thus if one uses stty to change settings for the raw mode,
|
|
such settings will be permanently lost as soon as one hits the
|
|
<return> key at the terminal.
|
|
|
|
Now when one types stty to look at the terminal interface, one may
|
|
either get a view of the cooked mode or the raw mode. You need to
|
|
figure out which one you're looking at. It you use stty from a
|
|
foreign terminal (other than the terminal you are currently typing at)
|
|
then you will likely see the raw mode settings since the terminal is
|
|
in raw mode almost all the time. Any changes made will only be made
|
|
to the raw mode and will be lost when someone presses <return> at the
|
|
foreign terminal you tried to "set". But if you type a stty command
|
|
to view/change the configuration of the terminal you are using, and
|
|
then hit <return> it's a different story. The <return> puts the
|
|
terminal in cooked mode and your changes are saved by the shell before
|
|
it returns to raw mode. Since going into raw mode doesn't change all
|
|
stty settings, some of the changes you made via stty may still be
|
|
present in raw mode and will not get destroyed by <return>.
|
|
|
|
This situation can create problems. For example, suppose you corrupt
|
|
your terminal interface so that it's not displaying what you type,
|
|
etc. To restore it you go to another terminal (on the same PC) and
|
|
type "stty -F dev/ttyS1 sane" (or the like). It will not work because
|
|
the terminal is in raw mode! Of course you can try to type "stty sane
|
|
..." at the terminal that is corrupted but you can't see what you
|
|
typed. All the above not only applies to dumb terminals but to
|
|
virtual terminals used on a PC Monitor as well as to the terminal
|
|
windows in X. In other words, it applies to almost everyone who uses
|
|
Linux.
|
|
|
|
Luckily, when you start up Linux, any file that runs stty at boot-time
|
|
will likely deal with a terminal (or serial port with no terminal)
|
|
that has no shell running on it so there's no problem for this special
|
|
case.
|
|
|
|
|
|
15.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.
|
|
|
|
|
|
15.4.6. Obsolete redirection method
|
|
|
|
Prior to about 2000 you needed to use the redirection operator "<" if
|
|
you wanted to use stty on a foreign terminal. For example to use stty
|
|
on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2.
|
|
After 2000 (provided your version of setserial is >= 1.17 and stty >=
|
|
2.0) a better method was created using the -F option: stty -F
|
|
/dev/ttyS2. This will work when the old redirection method fails.
|
|
|
|
The old redirection example above makes ttyS2 the standard input to
|
|
stty. This gives the stty program a link to the "file" ttyS2 so that
|
|
it may "read" it. But instead of reading the bytes sent to ttyS2 as
|
|
one might expect, it uses the link to find the configuration settings
|
|
of the port so that it may read or change them. In olden days, some
|
|
people tried to use ``stty ... > /dev/ttyS2'' to set the terminal.
|
|
This didn't work. Instead, it takes the message normal displayed by
|
|
the stty command for the terminal you are on (say tty1) and sends this
|
|
message to ttyS2. But it doesn't change any settings for ttyS2.
|
|
|
|
Here's a problem with the old redirection operator (which doesn't
|
|
happen if you use the newer -F option instead). Sometimes when trying
|
|
to use stty, the command hangs and nothing happens (you don't get a
|
|
prompt for a next command even after hitting <return>). This is
|
|
likely due to the port being stuck because it's waiting for one of the
|
|
modem control lines to be asserted. For example, unless you've set
|
|
"clocal" to ignore modem control lines, then if no CD signal is
|
|
asserted the port will not open and stty will not work for it (unless
|
|
you use the newer -F option). A similar situation seems to exist for
|
|
hardware flow control. If the cable for the port doesn't even have a
|
|
conductor for the pin that needs to be asserted then there is no easy
|
|
way to stop the hang.
|
|
|
|
|
|
One way to try to get out of the above hang is to use the newer -F
|
|
option and set "clocal" and/or "crtscts" as needed. If you don't have
|
|
the -F option then you may try to run some program (such as minicom)
|
|
on the port that will force it to operate even if the control lines
|
|
say not to. Then hopefully this program might set the port so it
|
|
doesn't need the control signal in the future in order to open: clocal
|
|
or -crtscts. To use "minicom" to do this you likely will have to
|
|
reconfigure minicom and then exit it and restart it. Instead of all
|
|
this bother, it may be simpler to just reboot the PC or via using a
|
|
virtual terminal kill the process using "top" (or "ps" to get the
|
|
process number and then "kill" to kill that process.
|
|
|
|
The obsolete redirection method (which still works in later versions)
|
|
is to type ``stty ... < /dev/ttyS2''. If the new method using -F
|
|
works but the obsolete one hangs, it implies that the port is hung due
|
|
to a modem control line not being asserted. Thus the obsolete
|
|
redirection method might still useful for troubleshooting.
|
|
|
|
|
|
|
|
15.5. Terminfo & Termcap (brief)
|
|
|
|
See ``Terminfo and Termcap (detailed)'' for a more detailed discussion
|
|
of termcap. Many application programs that you run use the terminfo
|
|
(formerly termcap) data base. This has an entry (or file) for each
|
|
model or type (such as vt100) of terminal and tells what the terminal
|
|
can do, what codes to send for various actions, and what codes to send
|
|
to the terminal to initialize it.
|
|
|
|
Since many terminals (and PC's also) can emulate other terminals and
|
|
have various "modes" of operation, there may be several terminfo
|
|
entries from which to choose for a given physical terminal. They
|
|
usually will have similar names. The last parameter of getty (for
|
|
both agetty and getty_ps) should be the terminfo name of the terminal
|
|
(or terminal emulation) that you are using (such as vt100).
|
|
|
|
The terminfo does more than just specify what the terminal is capable
|
|
of doing and disclose what codes to send to the terminal to get it to
|
|
do those things. It also specifies what "bold" will look like (will
|
|
it be reverse video or will it be high intensity, etc.), what the
|
|
cursor will look like, if the letters will be black, white, or some
|
|
other color, etc. In PC terminology these are called "preferences".
|
|
It also specifies initialization codes to send to the terminal
|
|
(analogous to the init strings sent to modems). Such strings are not
|
|
automatically sent to the terminal by Linux. See ``Init String''. If
|
|
you don't like the way the display on the screen looks and behaves you
|
|
may need to edit (and then update) the terminfo (or termcap) file.
|
|
See ``Terminfo Compiler (tic)'' for how to update.
|
|
|
|
|
|
15.6. Setting TERM and TERMINFO
|
|
|
|
These are two environment variables for terminals: TERM and TERMINFO,
|
|
but you may not need to do anything about them. TERM must always be
|
|
set to the type of the terminal you are using (such as vt100). If
|
|
you don't know the type (name) see ``What is the terminfo name of my
|
|
terminal ?''. TERMINFO contains the path to the terminfo data base,
|
|
but may not be needed if the database is in a default location (or
|
|
TERMINFO could be set automatically by a file that comes with your
|
|
distribution of Linux). You may want to look at `` Compiled database
|
|
locations''.
|
|
|
|
Fortunately, the getty program usually sets TERM for you just before
|
|
login. It just uses the terminal type that was specified on getty's
|
|
command line (in /etc/inittab). This permits application programs to
|
|
find the name of your terminal and then look up the terminal
|
|
capabilities in the terminfo data base. See ``TERM Variable'' for
|
|
more details on TERM.
|
|
|
|
If your terminfo data base can't be found you may see an error message
|
|
about it on your terminal. If this happens it's time to check out
|
|
where terminfo resides and set TERMINFO if needed. You may find out
|
|
where the terminfo database is by searching for a common terminfo file
|
|
such as "vt100" using the "locate" command. Make sure that your
|
|
terminal is in this database. An example of setting TERMINFO is:
|
|
export TERMINFO=/usr/share/terminfo (put this in /etc/profile or the
|
|
like). If the data for your terminal in this data base is not to your
|
|
liking, you may need to edit it. See ``Terminfo & Termcap (brief)''.
|
|
|
|
|
|
15.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''.
|
|
|
|
|
|
15.7. Rarely Needed /etc/ttytype File
|
|
|
|
The configuration file /etc/ttytype is used to map /dev/ttySn's to
|
|
terminal names per terminfo. tset/reset uses it, but if the TERM
|
|
environment variable is already set correctly, then this file is not
|
|
needed. Since the Linux getty sets TERM for each tty, you don't need
|
|
this file. In other Unix-like systems such as FreeBSD, the file
|
|
/etc/ttys maps ttys to much more, such as the appropriate getty
|
|
command, and the category of connection (such as "dialup"). An
|
|
example line of Linux ttytype: vt220 ttyS1
|
|
|
|
|
|
15.8. Login Restrictions
|
|
|
|
By default, the root user may not login from a terminal. To permit
|
|
this you must create (or edit) the file /etc/securetty per the manual
|
|
page "securetty". To restrict logins of certain users and/or certain
|
|
terminals, etc. edit /etc/login.access (this replaces the old
|
|
/etc/usertty file ??). /etc/login.def determines if /etc/securetty is
|
|
to be used and could be edited so as to make /etc/securetty not needed
|
|
(or not used). /etc/porttime restricts the times at which certain
|
|
ttys and users may use the computer. If there are too many failed
|
|
login attempt by a user, that user may be prohibited from ever logging
|
|
in again. See the man page "faillog" for how to control this.
|
|
|
|
|
|
15.9. Run Command Only If TERM=my_term_type
|
|
|
|
Sometimes there are commands that one wants to execute at start-up
|
|
only for a certain type of terminal. To do this for the stty command
|
|
is no problem since one uses the redirection operator < to specify
|
|
which terminal the command is for. But what about shell aliases or
|
|
functions? You may want to make a function for the ls command so it
|
|
will color-code the listing of directories only on color terminals or
|
|
consoles. For monochrome terminals you want the same function name
|
|
(but a different function body) which will use symbols as a substitute
|
|
for color-coding. Where to put such function definitions that are to
|
|
be different for different terminals?
|
|
You may put them inside an "if" statement in /etc/profile which runs
|
|
at startup each time one logs on. The conditional "if" statement
|
|
defines certain functions, etc. only if the terminal is of a specified
|
|
type.
|
|
|
|
|
|
15.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. It makes the ls command display colors if the
|
|
terminal is "linux" but uses ls -F if you're using a dumb terminal
|
|
(VT220). Note that the -F option uses symbols to give information on
|
|
file types just like color coding does. So there are alternatives to
|
|
using colors for the ls command, although a color display may look
|
|
more impressive.
|
|
|
|
|
|
______________________________________________________________________
|
|
if [ "$TERM" = linux ]; then
|
|
eval `dircolors`;
|
|
elif [ "$TERM" = vt220 ]; then
|
|
ls () { command ls -F $* ; }# to export the function ls():
|
|
declare -xf ls
|
|
else echo "From /etc/profile: Unknown terminal type $TERM"
|
|
fi
|
|
______________________________________________________________________
|
|
|
|
|
|
|
|
15.10. Character Mapping: mapchan
|
|
|
|
There is a free program named "mapchan" which will map characters
|
|
(bytes) typed at a terminal keyboard (input) into different characters
|
|
per a user-supplied mapping table. It can also map characters which
|
|
are sent to the screen (output). This is nice for remapping the
|
|
keyboard for foreign language alphabets. Most distributions don't
|
|
seem to supply it (let me know if any do). Source code by Yura
|
|
Kalinichenko (Ukraine, partly in Russian ) download mapchan etc.
|
|
<http://sourceforge.net/projects/mapchan/>
|
|
|
|
|
|
16. Terminfo and Termcap (detailed)
|
|
|
|
16.1. Intro to Terminfo
|
|
|
|
Terminfo (formerly Termcap) is a database of terminal capabilities and
|
|
more. For every (well almost) model of terminal it tells application
|
|
programs what the terminal is capable of doing. It tells what escape
|
|
sequences (or control characters) to send to the terminal in order to
|
|
do things such as move the cursor to a new location, erase part of the
|
|
screen, scroll the screen, change modes, change appearance (colors,
|
|
brightness, blinking, underlining, reverse video etc.). After about
|
|
1980, many terminals supported over a hundred different commands (some
|
|
of which take numeric parameters).
|
|
|
|
One way in which terminfo gives the its information to an application
|
|
program is via the "ncurses" functions that a programmer may put into
|
|
a C program. For example, if a program wants to move the cursor to
|
|
row 3, col 6 it simply calls: move(3,6). The move() function (part of
|
|
ncurses) knows how to do this for your terminal (it has read
|
|
terminfo). So it sends the appropriate escape sequence to the
|
|
terminal to make this particular move for a certain terminal. Some
|
|
programs get info directly from a terminfo files without using
|
|
ncurses. Thus a Linux package that doesn't require ncurses may still
|
|
need a terminfo file for your terminal.
|
|
|
|
The terminfo abbreviations are usually longer than those of termcap
|
|
and thus it's easier to guess what they mean. The manual pages for
|
|
terminfo are more detailed (and include the old termcap
|
|
abbreviations). Also, the termcap entries had a size limitation which
|
|
is not present for terminfo. Thus, unless you are already committed
|
|
to working with termcap, it's suggested you use terminfo.
|
|
|
|
|
|
16.2. Terminfo Database
|
|
|
|
16.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 ?''
|
|
|
|
|
|
16.2.2. Where is the database located ?
|
|
|
|
16.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 should replace all the existing older copies of that
|
|
file (at various locations) unless you abolish redundant locations.
|
|
If you don't ensure this gets done, then some application programs
|
|
could wind up still finding and using the old (and possibly buggy)
|
|
terminfo data that sill exists in a "possible" location. Setting the
|
|
environment variable TERMINFO to the up-to-date location (as mentioned
|
|
above) would help avoid this problem.
|
|
|
|
|
|
|
|
16.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/>.
|
|
|
|
|
|
16.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.
|
|
|
|
|
|
16.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.
|
|
|
|
|
|
16.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 ones used for x-terminal-emulation such
|
|
as xterm. The terminal type "dumb" may be needed when an application
|
|
program can't figure out what type of terminal you are using. It
|
|
would save disk space if install programs only installed the terminfo
|
|
for the terminals that you have and if you could get a termcap for a
|
|
newly installed terminal over the Internet in a few seconds.
|
|
|
|
|
|
16.3. Bugs in Existing Terminfo Files (and Hardware)
|
|
|
|
Unfortunately, there are a number of bugs in the terminfo and termcap
|
|
files. In addition, many of these terminfo files are incomplete and
|
|
do not define certain features available on the terminals. Sometimes
|
|
you can get by without modifying the terminfo but in other cases you
|
|
need to modify it or possibly use another emulation that has a good
|
|
terminfo.
|
|
|
|
The sad state of the supplied terminfo files is due to a number of
|
|
reasons. One is that during the 1980's when many of them were written
|
|
(often in termcap format), application programs did not utilize more
|
|
advanced terminal features. Thus if such feature were not in the
|
|
termcap (or terminfo) file, no one complained. Also, writing termcaps
|
|
was often done by volunteers who were in short supply. Today,
|
|
programs such as vim use "context highlighting" and minicom uses the
|
|
terminal's graphics character set. These often need more definitions
|
|
to be added to the old termcap. This may (or may not) have already
|
|
been done.
|
|
|
|
Most terminals had hardware bugs (in their firmware) and sometimes
|
|
these were "fixed" by modifying the termcap. Then the manufacturer
|
|
might send out replacement chips which would fix the bug. Not all
|
|
owners would bother to get the replacement chips. Thus there may be 2
|
|
or more terminfos for your terminal, depending on what firmware chips
|
|
it has in it. This situation was often not noted in the termcap and
|
|
only one of these termcaps may be supplied with Linux. Some hardware
|
|
bugs which existed for features that were almost never used in the
|
|
past likely never did get fixed. Also, some reported hardware bugs
|
|
may never have been fixed since they were not of much significance at
|
|
the time or because the terminal manufacturing company went out of
|
|
business, etc.
|
|
|
|
|
|
16.4. Modifying Terminfo Files
|
|
|
|
To do this you need a manual for your terminal showing what escape
|
|
sequences it uses. Newer manuals from the 1990's often don't show
|
|
this. You also need a terminfo manual (the man page "terminfo" is
|
|
one). After you edit the terminfo source file you compile it using
|
|
"tic". "tic" should automatically put the compiled terminfo file in
|
|
the correct directory reserved for it.
|
|
|
|
If you would like to find a better terminfo entry for a certain
|
|
terminal than the one supplied, you might try searching the Internet
|
|
(but what you find could be worse). If your new terminfo entry is
|
|
better than the old one and it seems stable (you've used it for a
|
|
while with no problems) then you should send a copy to the maintainer
|
|
of terminfo as noted at the start of the source file for terminfo (or
|
|
termcap).
|
|
|
|
|
|
16.5. Init String
|
|
|
|
Included in the terminfo are often a couple of initialization strings
|
|
which may be sent to the terminal to initialize it. This may change
|
|
the appearance of the screen, change what mode the terminal is in,
|
|
and/or make the terminal emulate another terminal. No initialization
|
|
string is automatically sent to the terminal to initialize it. One
|
|
might expect that the getty program should do this. If it did, one
|
|
could make a change to the set-up stored inside the terminal but this
|
|
change wouldn't happen because the init string would override it.
|
|
Application programs don't seem to initialize (send an init string per
|
|
terminfo) either.
|
|
|
|
To actually send an init string you must use a command given on the
|
|
command line (or in a shell script such as /etc/profile). Such
|
|
commands are: "reset" "tset", "tput init", or "setterm -initialize".
|
|
Sometimes there is no need to send an init string since the terminal
|
|
may set itself up correctly when it is powered on (using
|
|
options/preferences one has set up and saved in the non-volatile
|
|
memory of the terminal).
|
|
|
|
|
|
16.6. TERM Variable
|
|
|
|
The Environment variable TERM should be set to the name of terminal
|
|
which you are using. If TERM hasn't been set yet and you don't know
|
|
the name of your terminal see ``What is the terminfo name of my
|
|
terminal ?''. It is normally set by the terminal_type parameter
|
|
passed to the getty program (look at it in the /etc/inittab file).
|
|
This name must be in the Terminfo data base. Just type "set" at the
|
|
command line to see what TERM is set to (or type: tset -q). At a
|
|
console (monitor) TERM is set to "linux" which is the PC monitor
|
|
emulating a fictitious terminal model named "linux". Since "linux" is
|
|
close to a vt100 terminal and many text terminals are also, the
|
|
"linux" designation will sometimes work as a temporary expedient with
|
|
a text terminal.
|
|
|
|
If more than one type of terminal may be connected to the same port
|
|
(/dev/ttyS...) (for example, if there is a switch to permit different
|
|
terminal types to use the same serial port, or if the port is
|
|
connected to a modem to which people call in from different types of
|
|
terminals) then TERM needs to be set each time someone connects to the
|
|
serial port. There is often a query escape sequence so that the
|
|
computer may ask the terminal what type it is. Another way is to ask
|
|
the user to type in (or select) the type of terminal s/he is using.
|
|
You may need to use tset for this or write a short shell script to
|
|
handle this.
|
|
|
|
|
|
One way to do this is to use "reset" (same as "tset"; see the manual
|
|
page). reset tries to determine the terminal name of the terminal you
|
|
are using. Then it looks up the data in terminfo and sends your
|
|
terminal an init string. It can also set the value of TERM. For
|
|
example, a user dials in and logs in. The .profile login script is
|
|
executed which contains within it the following statement: eval `tset
|
|
-s ?vt100`. This results in: The user is asked if s/he is using a
|
|
vt100. The user either responds yes or types in the actual terminal
|
|
type s/he is using. Then "reset" sends the init string and sets TERM
|
|
to this terminal name (type).
|
|
|
|
|
|
16.7. Terminfo/Termcap Documents
|
|
|
|
|
|
|
|
· manual pages for terminfo(5) (best) and/or termcap(5). The Termcap
|
|
Manual <http://www.delorie.com/gnu/docs/termcap/termcap_toc.html>
|
|
(2nd ed.) by Richard M. Stallman is a GNU manual also known as the
|
|
"Termcap Library". It's somewhat obsolete since it doesn't include
|
|
terminfo. It's also at: Termcap Library
|
|
<http://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html>
|
|
|
|
· the files: terminfo.src and /etc/termcap have info about various
|
|
versions of termcap files, naming conventions for terminals, and
|
|
special capabilities code named u6-u9. If you don't have one, go to
|
|
<http://catb.org/terminfo/>
|
|
|
|
· "Termcap and Terminfo" is a book published by O'Reilly in 1988.
|
|
|
|
|
|
17. Using the Terminal
|
|
|
|
17.1. Intro to Using the Terminal
|
|
|
|
This section is about controlling the terminal-computer interface
|
|
and/or changing the terminal set-up while using the terminal. It
|
|
explains (or points to explanations of) how the user of a terminal can
|
|
control and inspect the interface and how to use various commands
|
|
provided by the device driver. It does not explain how to use the
|
|
many application programs, shells or most Linux utilities. Two
|
|
commands commonly used at the terminal are:
|
|
|
|
|
|
|
|
· clear (to clear the screen)
|
|
|
|
· reset (to reset the terminal
|
|
|
|
· setterm -reset (alternative for "reset" in case of bug)
|
|
|
|
|
|
17.2. Starting Up the Terminal
|
|
|
|
Of course the power must be on for the terminal to work. If you don't
|
|
see a login prompt hit the "return" (or "enter") key a few times.
|
|
Then type your account name (followed by a return/enter) and your
|
|
password when prompted for it (also followed by return/enter). Make
|
|
sure not to type all capital letters. If you do, the computer may
|
|
think that you have an old terminal that can't send lowercase letters
|
|
and the serial driver may set itself up to send only capital letters
|
|
to the terminal.
|
|
|
|
If nothing happens, make sure that both the host computer and the
|
|
terminal are OK. If the host computer is shut down (no power) what
|
|
you type at the terminal keyboard may appear on the screen since the
|
|
transmit and receive pins at the computer may be connected together
|
|
resulting in echoing of characters by an "off" computer. If you can't
|
|
log in when the host computer is running, see ``Trouble-Shooting''.
|
|
|
|
|
|
17.3. Terminal (Serial) Device Driver
|
|
|
|
When typing at the command line, the shell (such as the Bash shell) is
|
|
reading what you type and reacting to it. What you type first passes
|
|
thru the terminal driver part of your operating system. This driver
|
|
may translate certain characters (such as changing the "return"
|
|
character generated by the "return" key into a "new-line" character
|
|
for Linux files). It also recognizes certain control codes which you
|
|
may type at the keyboard such as ^C to interrupt the execution of a
|
|
program. It also normally echoes what you type back to the display.
|
|
``Stty'' may be used to configure how this terminal driver behaves,
|
|
including disabling some (or all) of its functionality.
|
|
|
|
|
|
17.4. Problems with Editors
|
|
|
|
There may be some problems with using both emacs and vi on some
|
|
terminals. A few terminals have no escape key (ESC) so you may need
|
|
to type Ctrl-[ to get ESC.
|
|
|
|
|
|
17.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.
|
|
|
|
|
|
17.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.
|
|
|
|
|
|
17.5. Problem with Slow Scrolling
|
|
|
|
The scrolling speed of the text terminal is limited by the speed over
|
|
the serial line. This limitation is good in one respect since the
|
|
scrolling speed is slow enough that you can almost read what is
|
|
scrolling on the screen before it disappears off the bottom of the
|
|
screen.
|
|
|
|
But there is a downside to this. For example, if you copy a large
|
|
number of files (like everything on your hard drive) and use options
|
|
to display the full name (path name) of each file copied, then the
|
|
speed limitations of the serial line may only only display 30 files
|
|
per second on the screen. But your hard drive can copy many times
|
|
faster than this but the terminal will slow down the transfer to the
|
|
speed at which it can be displayed by the terminal. It does this by
|
|
``Flow Control''.
|
|
|
|
The fix is to disable "progress" information being displayed on the
|
|
screen for cases where it slows down the "progress". If it just
|
|
updates progress numbers a few times per second or less, it shouldn't
|
|
be a problem.
|
|
|
|
|
|
17.6. Bugs in Bash ?
|
|
|
|
One problem still outstanding is that if certain terminal keys send
|
|
bytes with the high order bit set to 1, then Bash seems to ignore the
|
|
meaning for them as defined in a terminfo entry. This may be because,
|
|
unless one is using 7-bit ASCII, bytes with the high order bit set to
|
|
1, may represent a non-English letter. I reported this as a bug in
|
|
Bash (but years later realized that it may not have been a bug).
|
|
Other programs such as the vim editor and the lynx browser work OK
|
|
with such keys (when they are set to use 7-bit ASCII).
|
|
To work around this problem, one may define what these keys should do
|
|
in Bash by putting such definitions into /etc/inputrc. For example, A
|
|
Wyse 60 will send D0-D3 when the arrow-keys are hit provided the
|
|
terminal is in "application key mode". After modifying the terminfo
|
|
to reflect this, they still wouldn't work on the command line in the
|
|
Bash shell. So I explicitly defined the arrow-keys in /etc/inputrc
|
|
like this:
|
|
|
|
|
|
|
|
# Arrow keys in 8 bit keypad mode: Sends d0-d3. -ap means application.
|
|
$if term=wy60-25-ap
|
|
set enable-keypad on
|
|
"\xd0": backward-char
|
|
"\xd1": forward-char
|
|
"\xd2": next-history
|
|
"\xd3": previous-history
|
|
$endif
|
|
|
|
|
|
|
|
If the terminal is already in "application key mode" there's no need
|
|
to "set enable-keypad on". enable-keypad will send the terminal the
|
|
escape sequence named smkx in terminfo (which for wyse60 is \E~3 and
|
|
makes the arrow keys send D0-D3). Many other applications (other
|
|
than Bash) send this without needing to be told to do so.
|
|
|
|
|
|
17.6.1. A fixed Bash bug
|
|
|
|
There have been problems with the readline interface to the Bash
|
|
shell. Bash 2.01 (1998) had a readline interface which was quite
|
|
corrupted if one used a dumb terminal. This was fixed in later
|
|
versions.
|
|
|
|
|
|
17.7. Color ls Corruption
|
|
|
|
If ls is corrupting your terminal emulation with the color feature,
|
|
turn it off. ls --color, and ls --colour all use the color feature.
|
|
Some installations have ls set to use color by default. Check
|
|
/etc/profile, etc. for ls aliases. See ``Example for ls Function''
|
|
for how to have ls do color for the console and do monochrome for
|
|
terminals.
|
|
|
|
|
|
17.8. Display Freezes (hung terminal)
|
|
|
|
The symptom of a hung terminal is where what you type doesn't display
|
|
on the terminal (or in some cases displays but doesn't do anything).
|
|
If what you type is invisible (or does nothing) type ^Q to restart
|
|
flow (if flow control stopped it). Hanging may also be due to:
|
|
``Sent terminal binary'' or ``Abnormally exited a program''
|
|
If you didn't do any of these two, then the program you're running
|
|
could by buggy or you interaction with it fatally illegal.
|
|
|
|
If you want to quit the program you were running and you can't do it
|
|
by the usual methods (some programs have special keys you must hit to
|
|
exit) then try killing it from another terminal using "top" or "kill".
|
|
If the process refuses to die, then kill it with signal 9 from top (or
|
|
use "kill" on the command line). The "9" type of forced exit may leave
|
|
some temporary files lying around as well as a corrupted interface.
|
|
If this doesn't work, killing the login shell should result in a
|
|
startup of getty with a new login prompt. If all else fails, you may
|
|
need to reboot the computer or even power it down. Just rebooting may
|
|
not alter the possibly corrupted content of the serial port hardware
|
|
registers.
|
|
|
|
|
|
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No
|
|
Scroll" key) which mysteriously freezes the screen (although that is
|
|
what this key is supposed to do if you use software flow-control). To
|
|
restore normal screen interaction, press Ctrl-Q (^Q). Note that
|
|
everything typed during the "freeze" gets executed but you don't see
|
|
any report of this until you hit ^Q. Thus when it's frozen, don't
|
|
type anything drastic that might destroy files, etc. One argument for
|
|
using hardware flow-control is to prevent such freezes.
|
|
|
|
|
|
17.9. Corrupted Terminal Interface
|
|
|
|
This includes the case of a "frozen display" = "hung terminal" of the
|
|
previous section.
|
|
|
|
|
|
17.9.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''
|
|
|
|
|
|
17.9.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" or
|
|
"tset" or "setterm -reset" (followed by a <return> of course -- what
|
|
you type will likely not be readable on the screen). This will send
|
|
the reset string from the terminfo entry to the terminal. As an
|
|
alternative to this, if the correct set-up has been saved inside the
|
|
terminal then pressing a special key(s) (perhaps in setup mode) may
|
|
restore the settings. Then you might still need to use "reset" to
|
|
send the init string if you use it to set up your terminal.
|
|
|
|
|
|
17.9.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.
|
|
|
|
|
|
17.9.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.
|
|
|
|
|
|
17.9.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.
|
|
|
|
|
|
17.10. Special (Control) Characters
|
|
|
|
A number of control characters which you may type at the keyboard are
|
|
"caught" by the terminal driver and perform various tasks. To see
|
|
these control commands type: stty -a and look at lines 2-4. They are
|
|
tersely explained in the stty manual pages. They may be changed to
|
|
different control characters or disabled using the stty command. Thus
|
|
your control characters might be different than those described below.
|
|
They are used for command-line editing, interrupting, scrolling, and
|
|
to pass the next character thru transparently.
|
|
|
|
|
|
17.10.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 ??
|
|
|
|
|
|
17.10.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.).
|
|
|
|
|
|
17.10.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.
|
|
|
|
|
|
17.10.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.
|
|
|
|
|
|
17.11. Viewing Latin1 Files on a non-Latin1 terminal
|
|
|
|
Some "text" files are 8-bit Latin1 (=ISO-8859-1). See ``Character-
|
|
Sets''. If you have a terminal that will not display Latin1 (or don't
|
|
have the Latin1 character set installed), then certain symbols (such
|
|
as a bullet) will display wrong. When viewing manual pages (they are
|
|
Latin1) you may give the option -7 to man so as to translate
|
|
everything to ASCII. Are there some pagers that make these
|
|
translations ??
|
|
|
|
|
|
17.12. Eliminating Overstriking in Files
|
|
|
|
If one uses the "man" command to view a manual page but instead
|
|
redirects the output to a file, that file will have overstrikes in it.
|
|
Overstrikes are where some printed characters appear bold by printing
|
|
them twice in the same location. Thus to print an overstrike
|
|
character the file contains a backspace after the character and then
|
|
the same character repeated. If this is in a file, it's fine if you
|
|
are going to print it on a printer (unless the normal output from the
|
|
printer is so darks that overstriking makes little improvement). But
|
|
it's not so good if you want to use the file to email or edit.
|
|
|
|
One way to get rid of the overstrikes is to use the "ul" (underline)
|
|
command. You type: ul -t dumb my_overstruck_file > output_file The ul
|
|
command converts overstrikes to bold for whatever terminal is
|
|
specified and adds escape sequences to the output_file to generate the
|
|
bold. But the terminal of type "dumb" has no escape sequences so you
|
|
get the desired result. There are other ways to do this but this is a
|
|
possible use for a terminal of type "dumb".
|
|
|
|
|
|
17.13. Inspecting the Interface
|
|
|
|
These utility programs will provide information about the terminal
|
|
interface:
|
|
|
|
· gitkeys: shows what byte(s) each key sends to the host.
|
|
|
|
· tty: shows what tty port you are connected to.
|
|
|
|
· set: shows the value of TERM (the terminfo entry name)
|
|
|
|
· stty -a: shows all stty settings.
|
|
|
|
· setserial -g /dev/tty?? (you fill in ??) shows UART type, port
|
|
address and IRQ number.
|
|
|
|
· infocmp: shows the current terminfo entry (less comments)
|
|
|
|
|
|
17.14. Changing the Terminal Settings
|
|
|
|
The terminal settings are normally set once when the terminal is
|
|
installed using the setup procedures in the terminal manual. However,
|
|
some settings may be changed when the terminal is in use. You
|
|
normally would not give any "stty" or "setserial" commands when the
|
|
terminal is in use as they are likely to corrupt the terminal
|
|
interface. However, there are changes you may make to the appearance
|
|
of the terminal screen or to its behavior without destroying the
|
|
integrity of the interface. Sometimes these changes are made
|
|
automatically by application programs so you may not need to deal with
|
|
them.
|
|
|
|
One direct method of making such changes is to use the setup key (or
|
|
the like) at the terminal and then use menus (or the like) to make the
|
|
changes. To do this you may need to be familiar with the terminal.
|
|
The other 3 methods send an escape sequence from the computer to the
|
|
terminal to make the changes. These 3 examples show different methods
|
|
of doing this to set reverse video:
|
|
|
|
|
|
1. setterm -reverse
|
|
|
|
2. tput -rev
|
|
|
|
3. echo ^[[7m
|
|
|
|
|
|
17.14.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.
|
|
|
|
|
|
17.14.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.
|
|
17.14.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.
|
|
|
|
|
|
17.14.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.
|
|
|
|
|
|
17.15. Multiple Sessions
|
|
|
|
The "screen" package runs multiple sessions something like virtual
|
|
terminals on the console: See ``The Console: /dev/tty?''. You can
|
|
switch back and forth between the sessions. The non-free Facet Term
|
|
software also does this. See FacetTerm
|
|
<http://www.facetcorp.com/ft_overview.html>
|
|
|
|
|
|
17.16. Logging Out
|
|
|
|
To log out type either "logout" or "exit". Under some circumstances
|
|
your request will be refused, but you should be told why. One reason
|
|
for refusal is if you are not in the same shell that you logged into.
|
|
Another way to log out is to press ^D. Since ^D is also used for
|
|
other purposes, you may not want it to log you out. If you set
|
|
IGNOREEOF in the Bash shell then ^D will no longer log you out.
|
|
|
|
|
|
17.17. Chatting between Terminals, Spying
|
|
|
|
If two persons logged into terminals on the same host computer want to
|
|
chat with each other they may use the "write" or the "talk" (better)
|
|
program. One may prevent anyone (except the superuser) from writing
|
|
(sending messages) to their terminal by using the "mesg" command.
|
|
|
|
For spying on what someone else is doing at their terminal use the
|
|
"ttysnoop" program. In "ttysnoop" the two terminals have the same
|
|
status and anything typed on either keyboard appears on both screens
|
|
(in the same location). So if you're really spying and don't want to
|
|
be detected, you shouldn't type anything.
|
|
|
|
"ttysnoop" can be used for training with instructor and trainee
|
|
sitting side-by-side, each at their own terminal. The instructor may
|
|
watch what the trainee is typing and can correct any mistakes by
|
|
typing it correctly. The trainee can watch what the instructor types
|
|
and then try typing it. It's just like they used one terminal with
|
|
both people having their hands on the keyboard at the same time.
|
|
|
|
There's one shortcoming to "ttysnoop" and that is that the terminals
|
|
involved should all be (or emulate) the same type of terminal (such as
|
|
vt100). Since the "Linux" emulation done by a console (monitor) and
|
|
the "minicom" (or "picocom") emulation are close to vt100 one may use
|
|
ttysnoop using two PCs, one running "minicom" which emulates a
|
|
terminal.
|
|
|
|
There's a non-free program called "DoubleVision" that is something
|
|
like ttysnoop but does much more. Terminals may be of different types
|
|
and it can remember and playback sessions on terminals so you can
|
|
observe what happened in the past. The webpage is at
|
|
<http://www.tridia.com>.
|
|
|
|
|
|
17.18. Sharing the Serial Port
|
|
|
|
It's possible to use the same serial port for both a text-terminal and
|
|
another serial device such as a printer or modem. Making the physical
|
|
connection is easy using one of these methods:
|
|
|
|
· Just unplug the terminal cable and plug in the other device
|
|
|
|
· Use an AB switch to switch between the terminal and other device
|
|
(uses 3 cables)
|
|
|
|
· Use the printer (or aux) port on the terminal for the other device
|
|
|
|
When you are not using the serial port for a terminal, then you need
|
|
to make sure that no characters intended for the terminal are sent to
|
|
the other device by mistake. One unsafe way to do this is to let the
|
|
programs running on the terminal keep running, provided they don't
|
|
send out anything for the terminal when you are using the other
|
|
device. This sometimes works since a terminal running on a serial
|
|
port doesn't prevent another program (process) from opening the same
|
|
port. This sometimes works if the other device is a printer. But if
|
|
the other device should send bytes to the serial port on the computer,
|
|
then the program(s) for the terminal which are still running on the
|
|
port will often send back some bytes for the terminal which will
|
|
actually go to the other device as garbage.
|
|
|
|
To avoid this, it's best to kill all programs (processes) running on
|
|
the terminal before using the other device. This is not quite as easy
|
|
as it sounds. You normally have a shell (such as Bash) running on the
|
|
port and if you kill Bash (by logging out for example) then the
|
|
program "getty" will start up on the port to try to log you in again.
|
|
If you kill getty, it will respawn and start up again. So at first
|
|
glance it seems impossible to kill all processes on the terminal's
|
|
serial port.
|
|
|
|
One way to work around this problem is to switch runlevels so that no
|
|
getty program or shell is running on the port. For the runlevel fix,
|
|
you may create another runlevel in which no getty program runs on the
|
|
port. Then you enter this new runlevel and use the serial port for
|
|
something else. To set this up you need to edit /etc/inittab and
|
|
check and/or set the runlevels at which getty runs. For example the
|
|
line: "S1:23:respawn:/sbin/getty ..." means that getty will run (on
|
|
ttyS1) in runlevels 2 and 3. Now you could have it only run in level
|
|
2 (by deleting "3") and then go to runlevel 3 when you want to use the
|
|
other serial device. Thus to use the serial port for something else,
|
|
the super-user would type "init 3" to switch to runlevel 3. Type
|
|
"init 2" to get back to runlevel 2. Note that each runlevel may have
|
|
a different set of initialization scripts but you can change this if
|
|
you want, so that the same scripts are run in both runlevels. How the
|
|
scripts and runlevels work are distribution dependent. For the Debian
|
|
distribution, the explanation of this is in /usr/doc/sysvinit, but
|
|
also look in /usr/share/doc.
|
|
|
|
There's also the problem of the stty configuration of the port. When
|
|
the port is being used for the terminal it has certain configurations
|
|
but when say "init 3" is used to switch runlevels and disable getty on
|
|
the port, the original (boot-time) configuration of the port is not
|
|
restored. You are likely to wind up with the port configured in a
|
|
"raw" mode. This means that the serial port likely needs to be fully
|
|
reconfigured by stty, either by a script you write or by the next
|
|
application which runs on the port. Some applications such as
|
|
printing from the serial port may not capable of fully reconfiguring.
|
|
The obsolete version of /etc/printcap could only partially reconfigure
|
|
(but the new one under "lprng" can). Thus you might need to write a
|
|
script to do it. The stty configuration of a terminal will be
|
|
different depending on whether a shell is running on it, whether it's
|
|
at the "login" prompt, etc. Thus the stty configuration after
|
|
switching runlevels may vary.
|
|
|
|
|
|
17.19. Browsers for Text-Terminals
|
|
|
|
See 2005 Text Mode Browser Roundup
|
|
<http://www.linuxjournal.com/article/8148> for a review of text
|
|
browsers.
|
|
|
|
The "lynx" browser works correctly with all text terminals. There are
|
|
some other text browsers: "w3m", "links2" (formerly "links", and
|
|
"elinks" that only work perfectly with the Linux console, xterm, or
|
|
vt100 terminals. But links2 and elinks will work with any terminal by
|
|
classifying the type as dumb like the ``first terminals''. However,
|
|
such an interface is slower.
|
|
|
|
The "netrik" browser requires a color terminal. For "links2" and
|
|
"elinks" you must set your terminal to 8-bits with no parity. (I filed
|
|
a bug report years ago for elinks since it should work with parity and
|
|
finally in 2008 I got a message that it was fixed in version 0.13 and
|
|
might become fixed in 0.11 and 0.12 also). All (including netrik ??)
|
|
support ssl (secure socket layer) for encoded communication.
|
|
|
|
"w3m", "links2", and "elinks" overcome some of the "lynx"
|
|
deficiencies. "elinks" is just a more advanced "links". They can
|
|
usually display tables better and can display frames side-by-side.
|
|
Unfortunately, the width of what they try to display (for tables and
|
|
frames) is often wider than the terminal width so the text may run off
|
|
the right side of the screen. This requires scrolling sideways to see
|
|
everything. Doing this may cause the names of the table rows to
|
|
disappear from the screen. So in some cases, using "lynx" may be
|
|
better.
|
|
|
|
Unfortunately "w3m", "links2", and "elinks" don't have numbered links
|
|
like lynx does, nor do they have good support for cookies. Support
|
|
for Javascript may be a problem. Elinks and netrik have partial
|
|
support. Links2 also has support (full ?). Both netrik and links2 has
|
|
a graphic mode for use in X Window.
|
|
|
|
There are still other text browser projects. Some of them seem to be
|
|
dead.
|
|
|
|
|
|
18. Special Uses for a Terminal
|
|
|
|
18.1. Make a Serial Terminal the Console
|
|
|
|
This will turn a text-terminal (or emulator PC) into a "serial
|
|
console". Many messages from the system are normally only sent to the
|
|
console (the PC monitor). Some of the messages sent to the console at
|
|
boot-time may also be seen on any terminal after the boot succeeds by
|
|
typing the command: dmesg. If the boot failed this will not be of any
|
|
use since the terminal can't work without an operating system. It's
|
|
possible to modify the Linux kernel so as to make a terminal serve as
|
|
the console and receive all the messages from Linux intended for the
|
|
console. Unfortunately, the messages from the BIOS (which display on
|
|
the monitor when a PC is first started) will not display on this
|
|
terminal (but still display on the monitor).
|
|
|
|
There's a Remote-Serial-Console-HOWTO on this topic. Some people use
|
|
a serial console when they run a PC without a monitor or keyboard.
|
|
Normally, a PC will not start up without a keyboard and video card but
|
|
some BIOSs permit it. If you are lucky enough to have such a BIOS
|
|
that supports "console re-direct" you will likely then need to setup
|
|
the BIOS using the CMOS menus when you start your PC.
|
|
|
|
The method of creating a "serial console" depends on your kernel
|
|
version. In any case serial support needs to be compiled into the
|
|
kernel and not supplied as a module.
|
|
|
|
|
|
18.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).
|
|
|
|
|
|
18.1.2. Serial-Console For Kernels before 2.2
|
|
|
|
The Linux Journal in April 1997 had an article on patching the Linux
|
|
kernel. You add a couple of #defines at the start of
|
|
src/linux/drivers/char/console.c:
|
|
|
|
|
|
#define CONFIG_SERIAL_ECHO
|
|
#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */
|
|
|
|
The following was not in the Linux Journal article.
|
|
In kernel 2.+ (and earlier ??) you need to also set the baud
|
|
rate (unless 9600 is OK). Find these 2 lines:
|
|
|
|
serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
|
|
serial_echo_outb(0x0c, UART_DLL);
|
|
|
|
Change 0x0c in the line above (depending on the baud rate you want):
|
|
|
|
115200 baud: 0x01 19200 baud: 0x06 2400 baud: 0x30
|
|
57600 baud: 0x02 9600 baud: 0x0c 1200 baud: 0x60
|
|
38400 baud: 0x03 4800 baud: 0x18
|
|
|
|
|
|
|
|
If you currently use the console to select which operating system to
|
|
boot (using LILO), but would like to do this from a terminal, then you
|
|
need to add a line to the /etc/lilo.conf file. See the manual page
|
|
for lilo.conf and search for "serial=".
|
|
|
|
|
|
18.2. Run Linux without a Monitor
|
|
|
|
One way to do this is to just use a terminal (serial console) for the
|
|
monitor See ``Make a Serial Terminal the Console''. You may still
|
|
need a video card since many BIOSs require one to get the PC started.
|
|
Your BIOS may also require a keyboard to get started or it may have an
|
|
option where you can set the BIOS not to require a keyboard.
|
|
|
|
If you boot without a monitor, make sure that the boot loader (such as
|
|
LILO or GRUB) doesn't try to present any image on the screen. A text-
|
|
terminal can't display it and the booting may hang.
|
|
|
|
If you have a keyboardless terminal, it can also be used as a monitor
|
|
by use of the ttysnoop program. As of yet, it doesn't work like a
|
|
console since it doesn't get all the initial boot-time messages. See
|
|
``Use a Keyboardless Terminal as the Monitor''
|
|
|
|
|
|
18.3. Use a Keyboardless Terminal as the Monitor
|
|
|
|
18.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 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).
|
|
|
|
|
|
18.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 $@
|
|
|
|
|
|
|
|
19. Trouble-Shooting
|
|
|
|
If you suspect that the problem is a hardware problem, see the
|
|
``Repair and Diagnose'' section. If it's the keyboard see
|
|
``Keyboards''. If it responds incorrectly (if at all) to what you
|
|
type. see ``Corrupted Terminal Interface''. If the problem involves
|
|
the serial port itself see the Serial-HOWTO.
|
|
|
|
Here is a list of possible problems:
|
|
|
|
· ``Is the Terminal OK ?'' Suspect the terminal is defective.
|
|
|
|
· ``Display Freezes (hung terminal)''
|
|
|
|
· ``Displays Foreign/Weird Characters/Symbols''
|
|
|
|
· ``Displays Escape Sequences''
|
|
|
|
· ``Missing Text'' Either skips over some text or displays some text
|
|
OK and hangs.
|
|
|
|
· ``All Keys Work Erratically; Must Hit a Key a Few Times''
|
|
|
|
· ``If getty run from command line: Programs get stopped'' with
|
|
message "Stopped"
|
|
|
|
· ``Getty Respawning Too Rapidly'' (console error message)
|
|
|
|
· ``Fails Just After Login''
|
|
|
|
· ``Can't Login'' but login prompt is OK.
|
|
|
|
· ``Garbled Login Prompt''
|
|
|
|
· ``No Login Prompt''
|
|
|
|
· ``Cursor Jumps''
|
|
|
|
There are two cases where the terminal goes bad. One is when it's
|
|
been recently working OK and suddenly goes bad. This is discussed in
|
|
the next sub-section. The other case is where things don't work right
|
|
just after you install a terminal. For this case you may skip over
|
|
the next section.
|
|
|
|
|
|
19.1. Terminal Was Working OK
|
|
|
|
When a formerly working terminal suddenly goes bad it is often easy to
|
|
find the problem. That's because (except for hardware failures) the
|
|
problem is likely due to something that you did (or something the
|
|
software that you used did).
|
|
|
|
The problem may be obvious such as an error message when the terminal
|
|
is first turned on. If it makes a strange noise it likely needs
|
|
repair. See ``Repair & Diagnose''. First, think about what has been
|
|
done or changed recently as it's likely the cause of the problem. Did
|
|
the problem happen just after new system software was installed or
|
|
after a change in the configuration?
|
|
|
|
If the terminal isn't responding correctly (if at all) to what you
|
|
type to it, you may have a ``Corrupted Terminal Interface''.
|
|
|
|
|
|
|
|
19.2. Terminal Newly Installed
|
|
|
|
If you've just connected up a terminal to a computer per instructions
|
|
and it doesn't work this section is for you. If a terminal that
|
|
formerly worked OK doesn't work now then see ``Terminal Was Working
|
|
OK'' If you suspect that the serial port on your computer may be
|
|
defective you might try running a diagnostic test program on it. At
|
|
present (June 1998) it seems that Linux doesn't yet have such a
|
|
diagnostic program so you may need to run diagnostics under MS
|
|
DOS/Windows. There are some programs to monitor the various serial
|
|
lines such at DTR, CTS, etc. and this may help. See ``Serial
|
|
Monitoring/Diagnostics''
|
|
|
|
One approach is to first see if the terminal will work by trying to
|
|
copy a file to the terminal (cp my_file /dev/ttyS?) under the most
|
|
simple situation. This means with the modem control lines disabled
|
|
and at a show speed that doesn't need flow control (make sure that any
|
|
hardware flow control is disabled). If this copy works, then make the
|
|
situation a little more complicated and see if it still works, etc.,
|
|
etc. When the trouble appears just after you made a change, then that
|
|
change is likely the source of the trouble. Actually, its more
|
|
efficient (but more complex) to jump from the simple situation to
|
|
about half way to the final configuration so that the test eliminates
|
|
about half of the remaining possible causes of the problem. Then
|
|
repeat this methodology for the next test. This way it would only
|
|
take about 10 tests to find the cause out of a thousand possible
|
|
causes. You should deviate a little from this method based on hunches
|
|
and clues.
|
|
|
|
|
|
19.3. Is the Terminal OK ?
|
|
|
|
Many terminals will start up with some words on the screen. If these
|
|
words convey no error message, it's probably OK. If there is no sign
|
|
of power (a dark screen, etc.) re-plug in the computer power cord at
|
|
both ends. Make sure there is power at the wall jack (or at the
|
|
extension cord end). Try another power cord if you have one. Make
|
|
sure the terminal is turned on and that its fuse is not blown. A
|
|
blank (or dim) screen may sometimes be fixed by just turning up the
|
|
brightness and contrast using knobs or a keyboard key in set-up mode.
|
|
|
|
A terminal that's been stored for a long time may take a while to
|
|
"warm up" as the electrolytic capacitors heal themselves under
|
|
voltage. If it still won't work See ``Repair & Diagnose'' for tips on
|
|
repairing it.
|
|
|
|
If the terminal starts up OK, but you suspect that something may be
|
|
wrong with it, go into "local mode" where is works like a typewriter
|
|
and try typing on it. See ``Local Mode''. Before you have trouble,
|
|
you should find out if your terminal displays error messages if the
|
|
hardware is bad. One way to test a terminal for this is to turn it on
|
|
with the keyboard unplugged and see if it displays an error message.
|
|
|
|
|
|
19.4. Missing Text
|
|
|
|
If several lines or text displays on the terminal OK and then it stops
|
|
without finishing (in the middle of a word, etc.) or if big chunks of
|
|
text are missing, you likely have a problem with flow control. If you
|
|
can't figure out right away what's causing it, decrease the speed. If
|
|
that fixes it, it's likely a flow control problem. It may be that
|
|
flow control is not working at all due to failure to configure it
|
|
correctly, or due to incorrect cable wiring (for hardware flow
|
|
control). See ``Flow Control''
|
|
|
|
|
|
If you can type OK at the terminal but when text is sent to the
|
|
terminal, only about 1 in every 16 characters sent gets thru, then you
|
|
may have given the wrong UART to setserial. This will happen if the
|
|
port is an obsolete 16550 (or lower) but you've told setserial it's a
|
|
16550A or higher.
|
|
|
|
If single characters are missing, perhaps the serial port is being
|
|
overrun by too fast a speed. Try a slower baud rate.
|
|
|
|
If your device is under 1200 baud (probably a very slow old hard-copy
|
|
terminal or printer) and the text gets truncated, then the problem may
|
|
be in the serial device driver. See Printing-HOWTO under "Serial
|
|
devices" on how to fix this.
|
|
|
|
|
|
19.5. All Keys Work Erratically; Must Hit a Key a Few Times
|
|
|
|
This is where you need to hit a key a few times before it works (and
|
|
see the letter you typed on the screen). If you type a word, some (or
|
|
even all) of the letters may be missing on the screen. If letters are
|
|
missing from a command it doesn't work and even if all letters are
|
|
present you may need to hit the return-key several times to get the
|
|
command to execute.
|
|
|
|
This may be due to two different processes opening the serial port.
|
|
Both try to read what you type. Sometimes one process (the right one
|
|
--perhaps the shell) reads what you type and at other times the other
|
|
process reads what you type. An example is where the other process is
|
|
for a serial mouse (such as gpm) which doesn't echo what you type. So
|
|
another process running on the same ttySx is eating some of what you
|
|
type. To fix this, use "ps -alx" to see what else is running on your
|
|
ttySx and kill that process.
|
|
|
|
You might think that lockfiles would prevent two programs from using
|
|
the same serial port at the same time. But neither the terminal nor
|
|
the gpm mouse program uses lockfiles. Since others may need to write
|
|
to your terminal, it's reasonable not to use lockfiles. See Lock-
|
|
Files in the Serial-HOWTO.
|
|
|
|
|
|
19.6. ... respawning too fast: disabled for 5 minutes
|
|
|
|
19.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 rapidly respawns over and over. But the operating system
|
|
intervenes and stops this nonsense (for 5 minutes). The following
|
|
sections show possible causes and fixes.
|
|
|
|
|
|
19.6.2. Getty line in /etc/inittab file incorrect
|
|
|
|
Make sure the line which calls getty in /etc/inittab is correct. A
|
|
typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty" may cause this
|
|
problem.
|
|
|
|
|
|
|
|
19.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 getty_ps).
|
|
|
|
Another approach is to determine why CD is not being asserted. In
|
|
many cases the cable to the terminal simply doesn't have a wire for
|
|
the CD pin so you must use the "local" option. If there is a wire for
|
|
the CD pin then there may not be any signal on it until the terminal
|
|
is powered on. Note that the CD pin signal is sometimes supplied by
|
|
the DTR pin of the terminal (or the PC) by using jumper wires inside
|
|
the connector.
|
|
|
|
|
|
19.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".
|
|
|
|
|
|
19.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.)
|
|
|
|
|
|
19.6.6. Key shorted
|
|
|
|
Another possible cause of getty respawning too rapidly is if a
|
|
keyboard key is shorted. This can happen if the key gets stuck in the
|
|
down position. With auto-repeat enabled, this "types" thousands of
|
|
characters to the login prompt. Look for a screen filled with all the
|
|
same character (in some cases, with 2 or more different characters).
|
|
|
|
|
|
19.7. Fails Just After Login
|
|
|
|
If you can login OK but then you can't use the terminal it may be
|
|
because the starting of the login shell has reconfigured the terminal
|
|
(to an incorrect setting) by a command which someone put into one of
|
|
the files that are run when you login and a shell starts. These files
|
|
include /etc/profile and ~/.bashrc. Look for a command starting with
|
|
"stty" or "setserial" and make sure that it's correct. Even if it's
|
|
done OK in one initialization file, it may be reset incorrectly in
|
|
another initialization file that you are not aware of. Ways to get
|
|
into the systems to fix it are to use another terminal or console, use
|
|
a rescue diskette, or type: "linux single" at the lilo prompt which
|
|
puts you into single user mode without running startup files.
|
|
|
|
|
|
19.8. Can't Login
|
|
|
|
If you get a login prompt but get no response (or perhaps a garbled
|
|
response) to your login attempts a possible cause is that the
|
|
communication is bad one-way from the terminal to the computer. It
|
|
could be a bad or mis-wired cable/connector. If you're not already
|
|
using the "local" option with getty, do so to disable the modem
|
|
control lines. See ``Getty (used in /etc/inittab)''. You might also
|
|
disable hardware flow control (stty -crtscts) if it was enabled. If
|
|
it now works OK then your modem control lines are likely either not
|
|
wired correctly or there's a mistake in your set-up. Some terminals
|
|
allow setting different values (such as baud rate) for send and
|
|
receive so the receive could be OK but the send bad.
|
|
|
|
You should also try at another terminal (such as the console) "stty -F
|
|
/dev/ttyS1" (or ttyS whatever) to see that it's set up correctly. It
|
|
will often be in raw mode (and this is probably OK) with -icanon and
|
|
-echo etc. If the terminal incorrectly set at half-duplex (HDX), then
|
|
one set of the characters you see when you type are coming from the
|
|
terminal itself. If the characters are doubled, then the echos from
|
|
the computer are OK and you may switch to full-duplex to fix this.
|
|
But if half-duplex is set and you only see what looks like normal
|
|
"echos", then they are not coming from the computer as they should be.
|
|
|
|
If you get a message saying something like "login failed" then if
|
|
there is no error in typing or in the password, there may be some
|
|
restrictions on logins which will not allow you to log in.
|
|
Unfortunately, this message, may not tell you why it failed. See
|
|
``Login Restrictions''
|
|
|
|
|
|
19.9. Garbled Login Prompt
|
|
|
|
This may be due to using the wrong character set, transmission errors
|
|
due to too high of a baud rate, incompatible baud rates, incompatible
|
|
parity, or the wrong number of bits per byte. If it's a variety of
|
|
strange characters you have the wrong character set or a high order
|
|
bit is being set by mistake. If words are misspelled, try a lower
|
|
baud rate. For baud, parity, or bits/character incompatibilities you
|
|
see a lot of the same "error character" which represents a real
|
|
character that can't be displayed correctly due to an error in parity
|
|
or baud rate. The "error character" may be an upside-down question
|
|
mark or some other strange looking character such as a rectangle.
|
|
|
|
If you are using agetty (often just named getty), the agetty program
|
|
will detect and set parity and/or bits/character if you type
|
|
something. Try it with a return to see if it fixes it.
|
|
|
|
|
|
19.10. No Login Prompt
|
|
|
|
If there's no login prompt displayed after hitting the return-key a
|
|
few times then check the following: Use the "top" or "ps" programs to
|
|
make sure that a getty (or login) process is actually running on the
|
|
terminal. Is the terminal getting power? Is the null modem cable
|
|
plugged in to the correct ports on both the terminal and computer?
|
|
|
|
Check that getty isn't hanging because there is no CD signal (or no CD
|
|
wire in the cable). If such a CD signal doesn't exist you should have
|
|
specified "local" to getty by either:
|
|
|
|
· If getty_ps (Redhat, etc.) two CLOCAL flags in /etc/gettydefs (See
|
|
``getty (part of getty_ps)'').
|
|
|
|
· If agetty (Debian, etc.) a -L flag in /etc/inittab (See
|
|
``agetty'').
|
|
|
|
If getty (or login) isn't running, carefully check the format for
|
|
calling getty in /etc/inittab. Make sure that it includes the current
|
|
runlevel (shown by typing the command "runlevel") and that it is valid
|
|
for your flavor of getty. Sometimes killing getty or login (it will
|
|
restart automatically) helps.
|
|
19.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.
|
|
|
|
|
|
19.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
|
|
file-transfer), terminal setup at wrong baud-rate, terminal in local
|
|
mode, etc. At this point two different avenues of approach are (you
|
|
may pursue more than one at a time).
|
|
|
|
|
|
· ``Diagnose problem from the console''
|
|
|
|
· ``Measure voltages''
|
|
|
|
|
|
19.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.
|
|
|
|
|
|
19.10.4. Measure voltages
|
|
|
|
If you have a voltmeter handy check for a negative voltage (-4v to
|
|
-15v) at pin 3 or 2 (receive data) at the terminal side of the file-
|
|
transfer cable. The positive lead of the meter should be connected to
|
|
a good ground (a metal connector on the end of the cable may not be
|
|
grounded). If there is no such negative voltage then check for it at
|
|
the transmit pin (TxD) on the computer (see ``DB9-DB25'' for the pin-
|
|
out). If it's present there but not at the receive pin (RxD) at the
|
|
terminal, then the cable is bad (loose connection, broken wire, or not
|
|
a file-transfer aka null-modem). If this voltage is absent at the
|
|
computer, then its serial port is dead. Test it with a software
|
|
diagnostic test or replace it.
|
|
|
|
If the serial port is alive, you may want to send a file to it (with
|
|
modem controls disabled) and watch the signal on a voltmeter (or other
|
|
electronic gadget). To check for a transmitted signal with a
|
|
voltmeter, check for a steady negative voltage when the line is idle.
|
|
Then start sending a file (or start getty). On an analog meter you
|
|
should see the needle dropping to almost 0 and fluttering about 0 as
|
|
it measures short-run averages of the bit stream. On a digital meter
|
|
you will not see the fluctuations as well but you can switch to the AC
|
|
scale to see the AC voltage created by the flow of bits. If your
|
|
meter fails to block out DC on the AC scale (the default of most
|
|
analog meters), then you could get a false high AC reading when
|
|
looking at the idle DC of -12v (or -5v) on the AC scale. Without a
|
|
meter, you could connect a known good device (such as another terminal
|
|
or an external modem) to the serial port and see if it works OK.
|
|
|
|
19.11. Displays Foreign/Weird Characters/Symbols
|
|
|
|
Don't confuse this with ``Displays Escape Sequences''. If what you
|
|
type or see on the screen is not what's expected but looks like a
|
|
foreign alphabet, math symbols, line-drawing character, etc. then it
|
|
could be that the many of bytes that are sent to your terminal have
|
|
the high order bit set (when it shouldn't be). You are looking at the
|
|
character set (or part of a character set) which has the high order
|
|
bit set. This may happen if you have the baud rate wrong or parity
|
|
set wrong (per stty). If you have parity set per stty but inside the
|
|
terminal it's 8-bit no-parity, then the high order bit (= parity bit)
|
|
will often be erroneously set. Try stty -F /dev/ttyS? from another
|
|
terminal to check if the baud rate and parity are correct.
|
|
|
|
Perhaps the wrong character set (font) has been installed. An
|
|
erroneous escape sequence sent to the terminal could have switched
|
|
character sets. If you are using the mapchan program to change the
|
|
keyboard mapping, it could be incorrect.
|
|
|
|
|
|
19.12. Displays Escape Sequences
|
|
|
|
You may see something like "5;35H22,1" or "3;4v" or "1;24r" or
|
|
"^[[21;6H", etc., etc. Of course, the numbers and letters will be
|
|
different. They will be scattered about (either randomly or in a
|
|
strange sense of order). The display will look a mess and will likely
|
|
have other defects. Some application and commands will result in
|
|
corrupted displays.
|
|
|
|
What you see are escape sequences (or fragments of them) that were
|
|
sent to your terminal in order to control it, but your terminal didn't
|
|
recognize them and passed them on to the screen. It's likely that the
|
|
program you're using erroneously thinks you are using another type of
|
|
terminal. Thus it sends escape sequences that your terminal doesn't
|
|
understand. This can sometimes do strange things to your display.
|
|
Check that the TERM environment variable is set correctly (type: echo
|
|
$TERM).
|
|
|
|
|
|
19.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).
|
|
|
|
|
|
19.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''.
|
|
19.13. Slow: pauses of several seconds between bursts of characters
|
|
|
|
You likely have mis-set interrupts> See the Serial-HOWTO section
|
|
starting with "Slow:"
|
|
|
|
|
|
19.14. Cursor Jumps
|
|
|
|
This error happens when you expect the cursor to move to the next
|
|
character but instead it seems to jump to another character. It can
|
|
happen in the vim editor when you've selected "showmatch" to highlight
|
|
matching brackets (or parentheses). There is nothing wrong with the
|
|
terminal and the cursor isn't jumping, but it looks like it is.
|
|
|
|
What is happening is that the cursor is reverse video and the
|
|
highlighting is also reverse video. So suppose you highlight (or
|
|
emphasize) a character by reverse video and then put a reverse-video
|
|
cursor over it. The cursor's reverse video will then reverse the
|
|
existing reverse video of the character and result in normal video.
|
|
The result is that both the cursor and character highlighting have
|
|
disappeared for that character and the cursor is invisible (until you
|
|
move it to a non-highlighted character).
|
|
|
|
OK, so the cursor suddenly disappears, but what makes it jump? For
|
|
the vim "showmatch" when you move the cursor to an opening bracket it
|
|
also highlights the closing bracket. Thus the closing bracket
|
|
suddenly becomes reverse video and it looks just like the cursor has
|
|
jumped there, but it hasn't. Similar "illusions" happen when you move
|
|
the cursor to a closing bracket (or parenthesis). This illusion when
|
|
you reverse reverse-video happens in other cases besides the vim
|
|
example just presented.
|
|
|
|
|
|
19.15. Terminal doesn't scroll
|
|
|
|
One reason may be that something is wrong with terminfo. Another
|
|
reason could be that you are outside the scrolling region set for the
|
|
terminal. Some stupid programs just assume that your terminal has 24
|
|
lines and set the scrolling region for 24 lines (by an escape sequence
|
|
sent to the terminal) without consulting terminfo to see how many
|
|
lines there actually are. Then when you use another program it may
|
|
leave the cursor on line 25 where it becomes trapped and the terminal
|
|
will not scroll. To avoid this problem, create an environment
|
|
variable "export LINES=25" and also "stty -F /dev/ttySx rows 25".
|
|
Then the programs that assume 24 lines will hopefully use 25 lines set
|
|
the scrolling region accordingly.
|
|
|
|
|
|
19.16. Serial Monitoring/Diagnostics
|
|
|
|
A few Linux programs will monitor the modem control lines and indicate
|
|
if they are positive (1) or negative (0).
|
|
|
|
· statserial (in Debian distribution)
|
|
|
|
· The "file": /proc/tty/driver/serial. Use "watch head ..." to
|
|
monitor it. Has info on errors and byte flow.
|
|
|
|
· modemstat (only works on Linux PC consoles. Will coexist with the
|
|
command line)
|
|
|
|
You may already have the above programs. If not, go to Serial
|
|
Software <http://ibiblio.org/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.
|
|
|
|
|
|
19.17. Local Mode
|
|
|
|
In local mode, the terminal disconnects from the computer and behaves
|
|
like a typewriter (only it doesn't type on paper but on the screen).
|
|
Going back into on-line mode reconnects to the computer allowing you
|
|
to resume activities at the same point where you left off when you
|
|
went into "local". This is useful both for testing the terminal and
|
|
for educational purposes. For some terminals there is no "local
|
|
mode" but "block mode" may substitute for it. If there is no "block
|
|
mode", "half duplex" mode might work, except that what you type gets
|
|
sent to the computer also. In this case the computer may echo the
|
|
characters sent to it resulting in two characters displayed on the
|
|
screen for every character you type. To prevent this you could shut
|
|
down the computer, disconnect the RS-232 cable, etc.
|
|
|
|
When in local mode you may type escape sequences (starting with the
|
|
ESC key) and observe what they do. If the terminal doesn't work
|
|
correctly in local mode, it's unlikely that it will work correctly
|
|
when connected to the computer. If you're not exactly sure what an
|
|
escape sequence does, you can try it out in local mode. You might
|
|
also use it for trying out a terminal that is for sale. To get into
|
|
local mode on some terminals you first enter set-up mode and then
|
|
select "local" from a menu (or press a certain key). See ``Getting
|
|
Into Set-Up (Configuration) Mode''.
|
|
|
|
|
|
19.18. Serial Electrical Test Equipment
|
|
|
|
19.18.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.
|
|
|
|
|
|
19.18.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.
|
|
|
|
|
|
19.18.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.
|
|
|
|
|
|
|
|
20. Repair & Diagnose
|
|
|
|
Repairing a terminal has much in common with repairing a monitor
|
|
and/or keyboard. Sometimes the built-in diagnostics of the terminal
|
|
will display on the screen. By the symptoms, one may often isolate
|
|
the trouble to one of the following: bad keyboard, CRT dead, power
|
|
electronics failure (distorted display), or digital electronics
|
|
failure. It's best to have a service manual, but even if you don't
|
|
have one, you can often still repair it.
|
|
|
|
|
|
20.1. Repair Books & Websites
|
|
|
|
20.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.
|
|
|
|
|
|
20.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).
|
|
|
|
|
|
20.2. Safety
|
|
|
|
CRT's use high voltage of up to 30,000 volts for color (less for
|
|
monochrome). Be careful not to touch this voltage if the set is on
|
|
and the cover off. It probably won't kill you even if you do since
|
|
the amount of current it can supply is limited. But it is likely to
|
|
badly burn and shock you, etc. High voltage can jump across air gaps
|
|
and go thru cracked insulation so keep your hands a safe distance from
|
|
it. You should notice the well-insulated high voltage cable connected
|
|
to one side of the picture tube. Even when the set is off, there is
|
|
still enough residual voltage on the picture tube cable connection to
|
|
give you quite a shock. To discharge this voltage when the set is
|
|
unplugged use a screwdriver (insulated handle) with the metal blade
|
|
grounded to the picture tube ground cable with a jumper wire. Don't
|
|
use chassis ground.
|
|
|
|
The lower voltages (of hundreds of volts) can be even more dangerous
|
|
since they are not current limited. It is even more dangerous if your
|
|
hands are wet or if you are wearing a metal watchband, ring or the
|
|
like. In rare cases people have been killed by it so be careful. The
|
|
lowest voltages of only several volts on digital circuitry are fairly
|
|
safe but don't touch anything (except with a well insulated tool)
|
|
unless you know for sure.
|
|
|
|
|
|
20.3. Appearance of Display
|
|
|
|
If the display is too dim, turn up the brightness and/or contrast.
|
|
using knobs on the exterior of the unit (if they exist). If the
|
|
width, height or centering is incorrect, there are often control knobs
|
|
for these. For some older terminals one must press an arrow key (or
|
|
the like) in set-up mode.
|
|
|
|
You may need to remove the cover to make adjustments, especially on
|
|
older models. You could arrange things so that a large mirror is in
|
|
front of the terminal so as to view the display in the mirror while
|
|
making adjustments. The adjustments to turn may be on a printed
|
|
circuit board. While a screwdriver (possibly Phillips-head) may be
|
|
all that's needed, inductors may require special TV alignment tools
|
|
(plastic hex wrenches, etc.). The abbreviated name of the adjustment
|
|
should be printed on the circuit board. For example, here are some
|
|
such names:
|
|
|
|
|
|
· V-Size adjusts the Vertical height (Size)
|
|
|
|
· H-Size adjusts the Horizontal width (Size). It may be an inductor.
|
|
|
|
· V-Pos adjusts the Vertical Position
|
|
|
|
· H-Pos adjusts the Horizontal Position
|
|
|
|
· V-Lin adjusts Vertical Linearity (Use if width of scan lines
|
|
differs at the top and bottom of the screen)
|
|
|
|
· V-Hold adjusts Vertical Hold (Use if screen is uncontrollable
|
|
scrolling)
|
|
|
|
· Bright adjusts brightness (an external knob may also exist)
|
|
|
|
· Sub-Bright adjusts brightness of subdued intensity mode (often the
|
|
normal mode: dimmer than bold or bright mode).
|
|
|
|
Changing linearity may change the size so that it will need to be
|
|
readjusted. A terminal that has been stored for some time may have a
|
|
small display rectangle on the screen surrounded by a large black
|
|
Before adjusting it, leave the terminal on for a while since it will
|
|
likely recover some with use (the black borders will shrink).
|
|
|
|
|
|
20.4. Diagnose
|
|
|
|
20.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.
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
|
|
20.5. Detective work
|
|
|
|
By carefully inspecting the circuitry, one may often find the cause of
|
|
the problem. Look for discoloration, cracks, etc. An intermittent
|
|
problem may sometimes be found by tapping on components with a ball-
|
|
point pen (not the metal tip of course). A break in the conductor of
|
|
a printed circuit board may sometimes be revealed by flexing the
|
|
board. Solder that looks like it formed a drop or a solder joint with
|
|
little solder may need re-soldering. Soldering may heat up
|
|
transistors (and other components) and damage them so use a heat sink
|
|
if feasible. One failure may cause others, so unless you find the
|
|
original cause, the failure may reoccur.
|
|
|
|
If you have a common brand of terminal, you may be able to search the
|
|
Internet (including newsgroup postings) to find out what the most
|
|
frequent types of problems are for your terminal and perhaps
|
|
information on how to fix it. If you find that a certain component is
|
|
bad you may search for this component (for example R214 wyse) and
|
|
hopefully find a report by someone else who had the same problem.
|
|
Such a report may indicate other components that failed at the same
|
|
time. If a component is damaged so badly that its value can't be
|
|
read, then you might find it on the Internet. The manufacturer may
|
|
have on-line data that search engines don't index.
|
|
|
|
To see if the digital electronics work, try (using a good keyboard)
|
|
typing at the bad terminal. Try to read this typing at a good
|
|
terminal (or the console) using the copy command or with a terminal
|
|
communication program such as picocom. You may need to hit the return
|
|
key at the terminal in order to send a line. One may ask the bad
|
|
terminal for its identity etc. from another terminal. This will show
|
|
if two-way communication works.
|
|
|
|
|
|
20.6. Error Messages on the Screen
|
|
|
|
You are in luck if you see an error message on the screen. This
|
|
usually happens when you first turn the terminal on.
|
|
|
|
|
|
20.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''
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.7. Capacitors
|
|
|
|
Electrolytic capacitors have a metal shell and are may become weak or
|
|
fail if they set for years without being used. Sometimes just leaving
|
|
the terminal on for a while will help partially restore them. If you
|
|
can, exercise any terminals you have in storage by turning them on for
|
|
a while every year or so.
|
|
|
|
Note that cheap electrolytic capacitors designed for use in audio
|
|
circuits may fail if used in high frequency horizontal circuitry. For
|
|
this, you need low resistance (low ESR) capacitors. Replace non-
|
|
polarized capacitors (NP) with the same (or with "bi-polar").
|
|
|
|
If the terminal display takes several minutes of warmup before it's OK
|
|
then it's likely that you have one or more bad electrolytic
|
|
capacitors. One trick to find the bad one is to parallel each
|
|
suspected bad one with a good one (of at least the same voltage rating
|
|
and capacitance of roughly the same order of magnitude). If the
|
|
display improves a lot when you do this, then you've likely found the
|
|
bad capacitor. Be careful not to get shocked when doing this. The
|
|
actual voltage with respect to ground may be much higher than the
|
|
voltage rating of the capacitor.
|
|
|
|
|
|
20.8. Keyboards
|
|
|
|
20.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.
|
|
|
|
|
|
20.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".
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.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''
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.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.
|
|
|
|
20.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''.
|
|
|
|
|
|
20.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.
|
|
|
|
|
|
20.8.9. Cleaning keyboard contacts
|
|
|
|
20.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.
|
|
|
|
|
|
20.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 of the key with a finger. There exists a special tool known
|
|
as keycap puller but you can get by without it. The key-cap may tilt
|
|
a bit and wobble as it comes loose. It may even fly up into the air
|
|
and onto the floor.
|
|
|
|
Then you may have two choices on how to clean the contacts: Use
|
|
contact cleaner spray directly on top of the key switch, or take the
|
|
key switch apart and clean it (the best way if it comes apart easily).
|
|
Still another choice is to replace the key switch with a new or used
|
|
one but this is often more work (and more cost if you have to go thru
|
|
the trouble of finding a replacement.
|
|
|
|
Directly spraying contact cleaner into the top of the key switch,
|
|
without taking the switch apart, is the fastest method but the cleaner
|
|
may not reach the contacts it's supposed to clean. Before spraying,
|
|
clean the area around it a little. With the keyboard live (or with
|
|
the key contacts connected to an ohm-meter) use the plastic tube which
|
|
came with the spray to squirt cleaner so it will get inside the key
|
|
switch. Try to move the key push rod up and down while spraying.
|
|
Don't let the cleaning liquid get under nearby keys where it may pick
|
|
up dust and then seep (with the dust) into adjacent key switches. If
|
|
you make this mistake you may fix one key but damage nearby keys. If
|
|
this should happen, immediately work (repeatedly press) the affected
|
|
nearby keys until they continue to work OK.
|
|
|
|
You might tilt the keyboard so that the cleaner flows better into the
|
|
contacts. For the CIT101e terminal with an Alps keyboard, this means
|
|
tilting the top row of numeric keys up toward the ceiling. While
|
|
moving the key switch up and down with a pen or small screwdriver
|
|
handle avoid getting the toxic cleaner liquid on your skin (or wear
|
|
gloves). You might try turning the keyboard upside-down while working
|
|
the key to drain off remaining cleaner. The more cleaner you squirt
|
|
in the more likely it will fix it but it is also more likely to do
|
|
more damage to the plastic or contaminate adjacent keys, so use what
|
|
you think is just enough to do the job. Once the key works OK, work
|
|
it up and down a little more and test it a half minute later, etc. to
|
|
make sure it will still work OK.
|
|
|
|
Sometimes a key works fine when the contacts inside are saturated with
|
|
contact cleaner liquid. But when the liquid dries a few minutes later
|
|
then the resulting scale deposit left from the evaporation of the
|
|
cleaning liquid on the contacts, prevents good contact. Then the key
|
|
may work erratically (if at all). Operating the key when the liquid
|
|
is drying inside may help. Some switches have the contacts nearly
|
|
sealed inside so little if any contact cleaner reaches the contacts.
|
|
The cleaner that does get to the contacts may carry contamination with
|
|
it (cleaning around the tops before spraying helps minimize this).
|
|
|
|
If you want to disassemble the key switch, first inspect it to see if
|
|
it comes apart (and if so, how). Sometimes one may remove the cover
|
|
of the switch without removing the switch from the keyboard. To do
|
|
this pry up (or pull up) the top of the key switch after prying apart
|
|
thin plastic tabs that retain it. You may be able to use two small
|
|
screwdrivers for this and be able to pry up the switch while prying
|
|
apart the plastic retaining tabs. Don't pry too hard or you may break
|
|
the plastic. If this can't be done, you may have to unsolder the
|
|
switch and remove it in order to take it apart (or replace it). Once
|
|
the switch has been taken apart you still may not be able to see the
|
|
contacts if the contact surfaces are sandwiched together (nearly
|
|
touching). You may put contact cleaner on the contacts by squirting
|
|
some cleaner on an edge so it can penetrate onto the contacts. Insert
|
|
a tiny screwdriver blade just a little so as to pry apart the edges as
|
|
you apply the cleaner. This will help the cleaner reach the contacts.
|
|
Work the contacts open and closed with a screwdriver to help clean
|
|
them and note if the key is working by looking at the terminal screen.
|
|
|
|
There may be some kind of clip holding the contact surfaces together
|
|
which needs to be removed so you can pry them apart. Take care not to
|
|
loose small parts as they may fly up into the air when taking apart a
|
|
key switch. As a last resort, you may try bending the moving part
|
|
that the push-rod pushes so as to make a stronger contact. In my
|
|
terminal, this part looks like the electrical contact but it just
|
|
pushes the real electrical contact thru a thin insulator.
|
|
|
|
When putting the key switch back together, make sure that the spring
|
|
is in the right place. If, after you assemble the switch, the key
|
|
pushes down too hard or too easy, the spring is likely not positioned
|
|
right. If the spring is supposed to be recessed into a hole on the
|
|
push rod, one way to temporarily "glue" the spring into the push-rod
|
|
is to use a half-drop of water on the end of the spring. Then insert
|
|
this end into the push rod and assemble quickly before the water
|
|
dries. This should keep the spring from falling out of the push rod
|
|
during assembly. Instead of using water, you may stand the keyboard
|
|
on end (or upside-down) to keep the spring from falling out during
|
|
assembly.
|
|
|
|
|
|
21. Appendix A: General
|
|
|
|
21.1. List of Linux Terminal Commands
|
|
|
|
21.1.1. Sending a command to the terminal
|
|
|
|
|
|
· ``setterm'': long options
|
|
|
|
· ``tput'': terse options
|
|
|
|
· reset: initializes only
|
|
|
|
· tset: same as reset
|
|
|
|
· clear: clears screen
|
|
|
|
· setterm -reset: sends reset string
|
|
|
|
|
|
21.1.2. Configuring the terminal device driver
|
|
|
|
|
|
· ``Setserial'':
|
|
|
|
· ``Stty''
|
|
|
|
|
|
21.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
|
|
|
|
|
|
21.1.4. Other
|
|
|
|
|
|
· gitkeys: shows what bytes each key sends to the host.
|
|
|
|
· tty: shows what tty port you are connected to.
|
|
|
|
· reset -q: shows the value of TERM, the terminfo entry name
|
|
|
|
· ``reset'': sets TERM interactively and initializes
|
|
|
|
|
|
21.2. The Internet and Books
|
|
|
|
21.2.1. Terminal Info on the Internet
|
|
|
|
In the first decade of the 20th century,
|
|
http://www.cs.utk.edu/ shuford/terminal_index.html was Shuford's
|
|
Website at the University of Tennessee. It was the major sit for
|
|
information about text terminals but is now (2013) defunct. Perhaps
|
|
one can find it archived on the "Wayback" machine.
|
|
http://www.cs.utk.edu/ shuford/terminal/repair_hints_news.txt was
|
|
Shuford's repair archive of newsgroup postings on terminal repair. See
|
|
below for the vt100 part of this website which is still on the
|
|
internet.
|
|
|
|
|
|
· vt100 section of Shuford's Website <http://www.vt100.net>
|
|
|
|
· Text-terminal - Wikipedia
|
|
<http://en.wikipedia.org/wiki/Text_terminal>
|
|
|
|
· Terminal Interface per Wikipedia
|
|
<http://en.wikipedia.org/wiki/POSIX_terminal_interface>
|
|
|
|
· 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.
|
|
|
|
· Boundless <http://www.boundless.com/terminals.html> purchased the
|
|
VT and Dorio terminal business from DEC. Boundless used to have
|
|
online Specs of their ADDS, VT, and DORIO terminals but that link
|
|
(in previous versions of this HOWTO) is now dead.
|
|
|
|
· Wyse had detailed info (such as escape sequences) in it's knowledge
|
|
base. It's not as complete as a real manual since it mainly cover
|
|
"native" personality. It was Wyse text-terminals database" at
|
|
http://www.wyse.com/service/support/kbase/wyseterm.aspi but it's
|
|
defunct. You may still access their knowledge base (does it still
|
|
cover text-terminals) by registering. Start at <www.wyse.com>.
|
|
|
|
· ncurses FAQ <http://dickey.his.com/ncurses/ncurses.faq.html>
|
|
|
|
· comp.terminals is the newsgroup for terminals
|
|
|
|
|
|
21.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''
|
|
|
|
|
|
21.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 few months or so. The following are mainly of
|
|
historical interest:
|
|
|
|
|
|
· Handbook of Interactive Computer Terminals by Duane E. Sharp;
|
|
Reston Publishing Co. 1977. (mostly obsolete)
|
|
|
|
· Communicating with Display Terminals by Roger K. deBry; McGraw-Hill
|
|
1985. (mostly on IBM synchronous terminals)
|
|
|
|
The "HANDBOOK ... " presents brief specifications of over 100
|
|
different models of antique terminals made in the early 1970's by over
|
|
60 different companies. It also explains how they work physically but
|
|
has a diagram for a CRT which erroneously shows electrostatic
|
|
deflection of the electron beam (p. 36). Terminals actually used
|
|
magnetic deflection (even in the 1970's). This book explains a number
|
|
of advanced technical concepts such as "random scan" and "color
|
|
penetration principle".
|
|
|
|
The "COMMUNICATING ... " book in contrast to the "Handbook ... "
|
|
ignores the physical and electronic details of terminals. It has an
|
|
entire chapter explaining binary numbers (which is not needed in a
|
|
book on terminals since this information is widely available
|
|
elsewhere). It seems to mostly cover old IBM terminals (mainly the
|
|
3270) in block and synchronous modes of operation. It's of little use
|
|
for the commonly used ANSI terminals used today on Unix-like systems.
|
|
Although it does discuss them a little it doesn't show the various
|
|
wiring schemes used to connect them to serial ports.
|
|
|
|
|
|
21.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.
|
|
|
|
|
|
21.3. Non-Linux OSs
|
|
|
|
Under Microsoft's DOS one may use the DOS command "ctty COM2" so that
|
|
the DOS command line will display on a serial terminal (on COM2 in
|
|
this example). Unfortunately one can then no longer use the computer
|
|
monitor since MS DOS is not a multiuser operating system. Nor can
|
|
more than one terminal be used. So this capability is of little (if
|
|
any) benefit. If you emulate DOS under Linux with the free dosemu,
|
|
it's reported that you can run several terminals (multiuser). But
|
|
it's reported that PCTerm emulation doesn't work with it (yet ??).
|
|
|
|
While MS didn't create a "multiuser DOS" OS, others did. This permits
|
|
the use of many terminals on one DOS PC. It's compatible with most
|
|
MS-DOS software. One multiuser DOS OS is named "REAL/32". The
|
|
terminal's "pcterm" emulation is used here. There also may be a
|
|
"scan" (scancodes) setup mode which needs to be set. Other OSs such
|
|
as PICK, PC-MOS, and Concurrent DOS were/are multiuser and support
|
|
terminals.
|
|
|
|
There are 3 programs for Linux which let you run Windows applications
|
|
on a Linux PC: free: Wine, non-free: VMware and NeTraverse. Can they
|
|
use text-terminals under DOS? Wine can't since it doesn't have a DOS
|
|
mode. The other two require you to run the MS Windows OS software as
|
|
a "guest OS". The guest MS Windows OS has a DOS mode but it's not of
|
|
much use for text-terminals since it's not multiuser.
|
|
|
|
For other unix-like OSs, the configuration of the host computer for
|
|
terminals is usually significantly different than for Linux. Here are
|
|
some links to on-line manuals for non-linux systems.
|
|
|
|
|
|
· Adding Serial Terminals
|
|
<http://docsrv.sco.com:507/en/HANDBOOK/serial_terminal_adding.html>
|
|
in SCO OpenServer Handbook.
|
|
|
|
· Hewlett-Packard's HP-UX Configuring Terminals and Modems
|
|
<http://docs.hp.com/en/B2355-90675/ch03.html>
|
|
|
|
|
|
22. Appendix B: Escape Sequence Commands Terminology
|
|
|
|
These are sometimes called "control sequences". This section of Text-
|
|
Terminal-HOWTO is incomplete (and may never be complete as there are
|
|
such a huge number of control sequences). This section is for
|
|
reference and perhaps really belongs in something that would be called
|
|
"Text-Terminal-Programming-HOWTO".
|
|
|
|
An example of an ANSI standard escape sequence is ESC[5B which moves
|
|
the cursor down 5 lines. ESC is the Escape character. The parameter
|
|
5 is included in the sequence. If it were 7 the cursor would move
|
|
down 7 lines, etc. A listing for this sequence as "move cursor down x
|
|
lines: ESC[xB" is easy to to understand. But command jargon such as:
|
|
"tertiary device attribute request" is less comprehensible. This
|
|
section will try to explain some of the more arcane jargon used for
|
|
escape sequence commands. A full listing (including the escape
|
|
sequence codes for the ANSI standard) is a "wish list" project. Since
|
|
many escape sequences do the same thing as is done when setting up the
|
|
terminal with ``Set-Up Options'', such escape sequences options will
|
|
not be repeated here.
|
|
|
|
|
|
22.1. Esc Sequence Lists
|
|
|
|
See url url= "http://www.neoware.com/docs/teemtalk/t2k17pro.pdf"
|
|
name="TeemTalk.2000 Programmer's Guide v 1.7"> in pdf format. But
|
|
there are some sites that have info for certain terminals. For VT
|
|
terminals see VT Manuals <http://www.vt100.net/>. Other lists have
|
|
disappeared from the internet.
|
|
|
|
|
|
22.2. 8-bit Control Codes
|
|
|
|
Table of 8-bit DEC control codes (in hexadecimal). Work on VT2xx or
|
|
later. CSI is the most common.
|
|
|
|
|
|
|
|
ACRONYM FULL_NAME HEX REPLACES
|
|
IND Index (down one line) 84 ESC D
|
|
NEL Next Line 85 ESC E
|
|
RI Reverse Index (one line up) 8D ESC M
|
|
SS2 Single Shift 2 8E ESC N
|
|
SS3 Single Shift 3 8F ESC O
|
|
DCS Device Control String 90 ESC P
|
|
CSI Control Sequence Introducer) 9B ESC [
|
|
ST String Terminator 9C ESC \
|
|
|
|
|
|
|
|
22.3. Printer Esc
|
|
|
|
|
|
|
|
· Auto Print on/off: When on, data from the host is also teed (sent)
|
|
to the printer port of the terminal (and also shows on the terminal
|
|
screen).
|
|
|
|
· Print Controller on/off: When on, data from the host is sent only
|
|
to the printer (nothing shows on the terminal screen).
|
|
|
|
|
|
22.4. Reports
|
|
|
|
These sequences are usually a request sent from the host to request a
|
|
report from the terminal. The terminal responds by sending a report
|
|
(actually another escape sequence) to the host which has embedded in
|
|
it certain values telling the host about the current state of the
|
|
terminal. In some cases a report may be sent to the host even if it
|
|
wasn't asked for. This sometimes happens when set-up is exited. By
|
|
default no unsolicited reports should be sent.
|
|
|
|
|
|
· Request for Status (Report Operating Status): Meaning of replies
|
|
for VT100 is either "I'm OK" or "I'm not OK"
|
|
|
|
· Request for Device Attributes: The "device" is usually the
|
|
printer. Is there a printer? Is it ready?
|
|
|
|
· Reqest for Tertiary Device Attributes (VT): Reply is report that
|
|
was entered during set-up. The tertiary device is the 3rd device
|
|
(the printer or auxiliary port device ??). The 1st device may be
|
|
the host computer and the 2nd device the terminal.
|
|
|
|
· Request for Terminal Parameters: What is the parity, baud rate,
|
|
byte width, etc. This request doesn't seem to make much sense,
|
|
since if the host didn't already know this it couldn't communicate
|
|
with the terminal or send a reply.
|
|
|
|
|
|
22.5. Cursor Movements
|
|
|
|
The cursor is where the next character received from the host will be
|
|
displayed. Most of the cursor movements are self-explanatory. "index
|
|
cursor" means to move the cursor down one line. Cursor movements may
|
|
be relative to the current position such as "move 4 spaces left" or
|
|
absolute such as "move to row 3, column 39". Absolute is called
|
|
"Direct Cursor Positioning" or "Direct Cursor Addressing".
|
|
|
|
The home position is row 1 col. 1 (index origin is 1). But where this
|
|
home position is on the physical screen is not completely clear. If
|
|
"Cursor Origin Mode" = "Relative Origin Mode" is set, then home is at
|
|
the top of the scrolling region (not necessarily the top of the
|
|
screen) at the left edge of the screen. If "Absolute Origin Mode" is
|
|
set (the same as unsetting any of the two modes in the previous
|
|
sentence) then home is at the upper left corner of the screen. On
|
|
some old terminals if "Cursor Origin Mode" is set it means that it's
|
|
relative.
|
|
|
|
|
|
22.6. Pages (definition)
|
|
|
|
See ``Pages'' for an explanation of pages. There are a number of
|
|
escape sequences to deal with pages. Text may be copied from one page
|
|
to another and one may move the cursor from page to page. Switching
|
|
pages may or may not be automatic: when the screen becomes full (page
|
|
1) then more data from the host goes to page 2. The cursor may only
|
|
be on one page at a time and characters which are sent to the terminal
|
|
go there. If that page is not being displayed, new text will be
|
|
received by the terminal and go into display memory, but you will not
|
|
see it (until the terminal is switched to that page).
|
|
|
|
|
|
23. Appendix C: Serial Communications on EIA-232 (RS-232)
|
|
|
|
23.1. Intro to Serial Communication
|
|
|
|
(Much of this section is now found in Serial-HOWTO.) Text terminals
|
|
on Unix-like systems (and on PC's) are usually connected to an
|
|
asynchronous 232 serial port of a computer. It's usually a RS-232-C,
|
|
EIA-232-D, or EIA-232-E. These three are almost the same thing. The
|
|
original RS prefix became EIA (Electronics Industries Association) and
|
|
later EIA/TIA after EIA merged with TIA (Telecommunications Industries
|
|
Association). The EIA-232 spec provides also for synchronous (sync)
|
|
communication but the hardware to support sync is almost always
|
|
missing on PC's. The RS designation is obsolete but is still in use.
|
|
EIA will be used in this article.
|
|
|
|
The serial port is more than just a physical connector on the back of
|
|
a computer or terminal. It includes the associated electronics which
|
|
must produce signals conforming to the EIA-232 specification. The
|
|
standard connector has 25 pins, most of which are unused. An
|
|
alternative connector has only 9 pins. One pin is used to send out
|
|
data bytes and another to receive data bytes. Another pin is a common
|
|
signal ground. The other "useful" pins are used mainly for signalling
|
|
purposes with a steady negative voltage meaning "off" and a steady
|
|
positive voltage meaning "on".
|
|
|
|
The UART (Universal Asynchronous Receiver-Transmitter) chip does most
|
|
of the work. Today, the functionality of this chip is usually built
|
|
into another chip.
|
|
|
|
|
|
23.2. Voltages
|
|
|
|
23.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
|
|
(newer ones are 5 volts but the 12 volt example is given here). For
|
|
the transmit and receive pins +12 volts is a 0-bit (sometimes called
|
|
"space") and -12 volts is a 1-bit (sometimes called "mark"). This is
|
|
known as inverted logic since normally a 0-bit is both false and
|
|
negative while a one is normally both true and positive. Although the
|
|
receive and transmit pins are inverted logic, other pins (modem
|
|
control lines) are normal logic with a positive voltage being true (or
|
|
"on" or "asserted") and a negative voltage being false (or "off" or
|
|
"negated"). Zero voltage has no meaning (except it usually means that
|
|
the PC is powered off).
|
|
|
|
A range of voltages is allowed. The specs say the magnitude of a
|
|
transmitted signal should be between 5 and 15 volts but must never
|
|
exceed 25 V. Any voltage received under 3 V is undefined (but some
|
|
terminals will accept a lower voltage as valid). One sometimes saw
|
|
erroneous claims that the voltage is commonly 5 volts (or even 3
|
|
volts) but it's usually 11-12 volts on older PCs. If you are using a
|
|
EIA-422 port on a Mac computer as an EIA-232 (requires a special
|
|
cable) or EIA-423 then the voltage will actually be only 5 V. The
|
|
discussion here assumes 12 V. There was much confusion about voltages
|
|
on the Internet.
|
|
|
|
Note that normal computer logic normally is just a few volts (5 volts
|
|
was once the standard) so that if you try to use test equipment
|
|
designed for testing 3-5 volt computer logic (TTL) on a 12 volt serial
|
|
port, it may damage the test equipment.
|
|
|
|
|
|
23.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).
|
|
|
|
|
|
23.3. Parity Explained
|
|
|
|
Characters are normally transmitted with either 7 or 8 bits (of data).
|
|
An additional parity bit may (or may not) be appended to this
|
|
resulting in a byte length of 7, 8 or 9 bits. Some terminal emulators
|
|
and older terminals do not allow 9 bits. Some prohibit 9 bits if 2
|
|
stop bits are used (since this would make the total number of bits too
|
|
large: 12 bits total).
|
|
|
|
The parity may be set to odd, even or none (mark and space parity may
|
|
be options on some terminals). With odd parity, the parity bit is
|
|
selected so that the number of 1-bits in a byte, including the parity
|
|
bit, is odd. If a such a byte gets corrupted by a bit being flipped,
|
|
the result is an illegal byte of even parity. This error will be
|
|
detected and if it's an incoming byte to the terminal an error-
|
|
character symbol will appear on the screen. Even parity works in a
|
|
similar manner with all legal bytes (including the parity bit) having
|
|
an even number of 1-bits. During set-up, the number of bits per
|
|
character usually means only the number of data bits per byte (7 for
|
|
true ASCII and 8 for various ISO character sets).
|
|
|
|
A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
|
|
0). For mark parity, the parity bit is always a one-bit. For space
|
|
parity it's always a zero-bit. Mark or space parity only wastes
|
|
bandwidth and should be avoided when feasible. "No parity" means that
|
|
no parity bit is added. For terminals that don't permit 9 bit bytes,
|
|
"no parity" must be selected when using 8 bit character sets since
|
|
there is no room for a parity bit.
|
|
|
|
|
|
23.4. Forming a Byte (Framing)
|
|
|
|
In serial transmission of bytes via EIA-232 ports, the low-order bit
|
|
is always sent first. Serial ports on PC's use asynchronous
|
|
communication where there is a start bit and a stop bit to mark the
|
|
beginning and end of a byte. This is called framing and the framed
|
|
byte is sometimes called a frame. As a result a total of 9, 10, or 11
|
|
bits are sent per byte with 10 being the most common. 8-N-1 means 8
|
|
data bits, No parity, 1 stop bit. This adds up to 10 bits total when
|
|
one counts the start bit. One stop bit is almost universally used.
|
|
At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
|
|
used but today the 2nd stop bit is used only in very unusual
|
|
situations (or by mistake since it seemingly still works OK that way).
|
|
|
|
|
|
23.5. Limitations of EIA-232
|
|
|
|
23.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.
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.6. Synchronization & Synchronous
|
|
|
|
23.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.
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.7. Block Mode
|
|
|
|
23.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'').
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.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.
|
|
|
|
|
|
23.8. EIA-232 (RS-232) Books
|
|
|
|
(Note: The first book covers much more than just EIA-232.)
|
|
|
|
· Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE
|
|
Computer Society Press, Los Alamitos, CA, 1996.
|
|
|
|
· Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.
|
|
|
|
· Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.
|
|
|
|
· Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall, 1991.
|
|
|
|
|
|
23.9. Serial Software
|
|
|
|
See Serial Software <ftp://ibiblio.org/pub/Linux/system/serial/> for
|
|
Linux software for the serial ports including getty and port monitors.
|
|
|
|
|
|
24. Appendix D: Notes by Brand/Model
|
|
|
|
Here are notes by brand name that were too specific to a certain
|
|
terminal to be put elsewhere in this HOWTO. If you have some info to
|
|
contribute on a certain terminal that is not covered elsewhere, it
|
|
could go here. Various models often have much in common so such
|
|
common information need only be written about once. It would be nice
|
|
if for each terminal model, there were a set of links linking to most
|
|
of the documentation relevant to that model (including escape codes).
|
|
But it hasn't been done. Note that some VT (DEC) manuals are now
|
|
available on the Internet. See and ``VT (DEC)''. Wyse put the
|
|
information from its manuals on the Internet but it can't be readily
|
|
found now (2013).
|
|
|
|
|
|
24.1. Adds
|
|
|
|
The Adds terminal menu incorrectly used "Xon/Xoff" to mean any kind of
|
|
flow control. True for which models ??
|
|
|
|
Adds, which made the Adds Viewpoint terminal, was taken over by
|
|
Boundless Technologies in 1994 but they continued to use the "Adds"
|
|
name.
|
|
|
|
|
|
24.2. CIT
|
|
|
|
CIT terminals were made in Japan in the 1980's for CIE Terminals.
|
|
They ceased to be imported in the late 1980's. The company, CIE,
|
|
still made CItoh printers (in 1997) but has no parts for its abandoned
|
|
terminals. Ernie at (714) 453-9555 in Irvine CA sold (in 1997) some
|
|
parts for models 224, 326, etc. but has nothing for the 80 and 101.
|
|
|
|
To save the Set-Up parameters press ^S when in Set-Up mode. cit80:
|
|
Contrast: knob on rear of terminal, cit101e: Brightness: use up/down
|
|
arrow keys in Set-Up mode.
|
|
|
|
|
|
24.3. IBM Terminals
|
|
|
|
Don't confuse IBM terminals with IBM PC monitors. Many IBM terminals
|
|
don't use ASCII but instead use an 8-bit EBCDIC code. It's claimed
|
|
that in EBCDIC the bit order of transmission is reversed from normal
|
|
with the high-order bit going first. The IBM mainframe communication
|
|
standards are a type of synchronous communication in block mode (sends
|
|
large packets of characters). Two standards are "BISYNC" and "SNA"
|
|
(which includes networking standards). Many of their terminals
|
|
connect with coax cable (RG62A/U) and naive persons may think the
|
|
"BNC" connecter on the terminal is for ethernet (but it's not).
|
|
|
|
While this IBM system is actually more efficient than what is
|
|
normally used in Linux, terminals meeting this IBM standard will not
|
|
currently work with Linux. However, some IBM terminals are
|
|
asynchronous ASCII terminals and should work with Linux on PC's. The
|
|
numbers 31xx may work with the exception that 317x and 319x are not
|
|
ASCII terminals. Before getting an IBM terminal, make sure there is a
|
|
termcap (terminfo) for it. If their isn't, it likely will not work
|
|
with Linux. Even if there is a terminfo, it may not work. For
|
|
example, there is a termcap for 327x but the 3270 is an EBCDIC
|
|
synchronous terminal.
|
|
|
|
The 3270 series includes the 3278 (late 1970's), 3279 with color and
|
|
graphics, and the 3274 terminal controller (something like the 3174).
|
|
They may be used for both BISYNC and SNA. The 3290 has a split screen
|
|
(splits into quarters).
|
|
|
|
The synchronous IBM terminals don't connect directly to the IBM
|
|
mainframe, but connect to a "terminal controller" (sometimes called
|
|
"cluster controller" or "communication controller"). Some of these
|
|
controllers can convert a synchronous signal to asynchronous so that
|
|
in this case a synchronous terminal could indirectly connect to a
|
|
Unix-like host computer via its serial port. But there is still a
|
|
major problem and that is block transmission. See section ``Block
|
|
Mode''.
|
|
|
|
|
|
24.3.1. IBM 3153
|
|
|
|
It's claimed that the Aux port is DCE and uses a straight-thru cable.
|
|
|
|
|
|
24.4. Teletypes
|
|
|
|
These are antiques and represent the oldest terminals. They are like
|
|
remotely controlled typewriters but are large and noisy. Made by the
|
|
Teletype Corp., the first models were made in the 1920's and predate
|
|
the computer by over 30 years. Early models used electro-mechanical
|
|
relays and rotating distributors instead of electronics. Their Baudot
|
|
code was only 5-bits per character as compared to 7-bit ASCII. See
|
|
the book "Small Computer Systems Handbook" by Sol Libes, Hayden Books,
|
|
1978: pp. 138-141 ("Teletypes").
|
|
|
|
|
|
24.5. VT (originally DEC, now Boundless)
|
|
|
|
Digital Equipment Corporation (DEC) made the famous VT series of
|
|
terminals including the commonly emulated VT100.
|
|
|
|
In 1995 DEC sold their terminal business to Boundless Technologies.
|
|
Boundless went bankrupt in 2003 but emerged from bankruptcy in 2006 as
|
|
a division of "Visual Technologies". Then in 2008 they were acquired
|
|
by Video Display Corporation and given to their Z-AXIS subsidiary
|
|
located near Rochester, New York. The Boundless
|
|
<http://www.boundless.com/terminals.html> name and url have been
|
|
retained.
|
|
|
|
Detailed VT terminal information, some manuals, and history is at
|
|
<http://www.vt100.net/>.
|
|
|
|
VT220: Some have a BNC connector for video output (not for input).
|
|
Sometimes people erroneously think this is for an ethernet connection.
|
|
|
|
VT510, 520, 525: Supports full DTR/DSR flow control. Some are "low
|
|
emissions" models. The 520 is multi-session and the 525 has colors for
|
|
highlighting.
|
|
|
|
Dorio is a lower quality model which can emulate many other terminals.
|
|
The "sco unix console" is claimed to be a powerful emulation using the
|
|
"scoansi" terminfo.
|
|
|
|
|
|
24.6. Links
|
|
|
|
The terminal maker Links was taken over by Wyse.
|
|
|
|
|
|
24.7. Qume
|
|
|
|
Qume was taken over by Wyse in the early 1990s.
|
|
|
|
|
|
24.8. Wyse Terminals
|
|
|
|
detailed manual-like information on old terminals see
|
|
<http://www.wyse.com/service/support/kbase/wyseterm.asp>. This
|
|
information includes specs, lists of escape sequences, part lists,
|
|
FAQs, setup info, etc. Thanks to Wyse for providing this even though
|
|
as of 2006 they are no longer making text terminals.
|
|
|
|
Wyse terminals were lower in cost than other brands and they captured
|
|
a major share of the market. There were concerns about the quality of
|
|
these terminals, especially the Wyse 50. But the large number of
|
|
failure reports (other than Wyse 50) may be due in part to the large
|
|
number of Wyse terminals in use.
|
|
|
|
See <en.wikipedia.org/wiki/Dell_Wyse> for a history of Wyse.
|
|
|
|
|
|
24.8.1. Wyse 50
|
|
|
|
Reported not to last very long.
|
|
|
|
|
|
24.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 0xd0 - 0xd3.
|
|
Due to a bug in the readline interface of the Bash shell, you need to
|
|
edit /etc/inputrc so that the arrow keys will work in Bash. See
|
|
``Bugs in Bash''
|
|
|
|
|
|
24.8.3. Wyse 85
|
|
|
|
Can emulate VT52/VT100/VT200. Press F3 for setup. After moving
|
|
left/right to go a menu "icon", press space to select it. Scroll thru
|
|
setup menus with up/down keys. Press F3 at any time to reenter setup
|
|
(without loosing any settings).
|
|
|
|
|
|
24.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.
|
|
|
|
|
|
24.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).
|
|
|
|
|
|
24.8.6. Wyse 185
|
|
|
|
Has 10x20 character cells. Can emulate DEC VT320. Uses 45 watts
|
|
power. Later models were 185e.
|
|
|
|
|
|
24.8.7. Low Emissions: -ES
|
|
|
|
ES after the model number means low emissions: low magnetic field,
|
|
etc.
|
|
|
|
END OF Text-Terminal-HOWTO
|
|
|
|
|
|
|