Text Terminal Howto
Text Terminal Howto
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO...................................................................................................................................1
David S. Lawyer mailto:dave@lafn.org..................................................................................................1
1. Introduction..........................................................................................................................................1
2. Types of Terminals..............................................................................................................................1
3. Thin Clients Terminals........................................................................................................................1
4. Quick Install.........................................................................................................................................1
5. Why Use a Terminal ?.........................................................................................................................1
6. Overview of How Terminals Work (in Linux)....................................................................................2
7. Terminal Special Files such as /dev/tty...............................................................................................2
8. Some Details on How Terminals Work...............................................................................................2
9. Special Features of Some Terminals....................................................................................................2
10. Terminal Emulation (including the Console)....................................................................................2
11. Flow Control (Handshaking).............................................................................................................3
12. Physical Connection..........................................................................................................................3
13. Set-Up (Configure) in General...........................................................................................................3
14. Terminal Set-Up (Configure) Details................................................................................................3
15. Computer Set-Up (Configure) Details...............................................................................................4
16. Terminfo and Termcap (detailed)......................................................................................................4
17. Using the Terminal............................................................................................................................4
18. Special Uses for a Terminal...............................................................................................................5
19. Trouble-Shooting...............................................................................................................................5
20. Repair & Diagnose.............................................................................................................................5
21. Appendix A: General.........................................................................................................................5
22. Appendix B: Escape Sequence Commands Terminology.................................................................5
23. Appendix C: Serial Communications on EIA-232 (RS-232)............................................................6
24. Appendix D: Notes by Brand/Model.................................................................................................6
1. Introduction.........................................................................................................................................6
1.1 Copyright, Trademarks, Disclaimer, & Credits.................................................................................6
Copyright...........................................................................................................................................6
Disclaimer.........................................................................................................................................7
Trademarks........................................................................................................................................7
Credits...............................................................................................................................................7
1.2 Future Plans: You Can Help..............................................................................................................7
1.3 New Versions of this HOWTO..........................................................................................................7
1.4 Related HOWTOs, etc......................................................................................................................8
1.5 Terminology Used in this Document.................................................................................................8
1.6 What is a Terminal ?..........................................................................................................................8
1.7 What is a Text-Terminal ?.................................................................................................................8
Real text terminals.............................................................................................................................9
2. Types of Terminals..............................................................................................................................9
2.1 Dumb Terminals................................................................................................................................9
2.2 Text Terminals.................................................................................................................................10
2.3 Graphic GUI Capabilities of Text Terminals...................................................................................10
Graphics GUI displays...................................................................................................................10
3. Thin Clients Terminals......................................................................................................................11
3.1 Introduction......................................................................................................................................11
3.2 MS Window terminals.....................................................................................................................11
Network computers (NCs)...............................................................................................................12
i
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
Thin clients and NCs under Linux.................................................................................................12
Hardware hookups...........................................................................................................................13
History and the future......................................................................................................................13
3.3 Emulation on a PC...........................................................................................................................14
4. Quick Install......................................................................................................................................14
5. Why Use a Terminal ?.......................................................................................................................14
5.1 Intro to Why Use a Terminal...........................................................................................................14
5.2 Lower Hardware Costs ?..................................................................................................................15
5.3 Control of Software..........................................................................................................................15
5.4 Hardware Upgrades.........................................................................................................................15
5.5 Other Advantages of Terminals.......................................................................................................16
5.6 Major Disadvantages of Terminals..................................................................................................16
5.7 Are Text Terminals Obsolete ?........................................................................................................16
6. Overview of How Terminals Work (in Linux).................................................................................16
6.1 Device Names.................................................................................................................................17
6.2 Login/Logout...................................................................................................................................17
6.3 Half/Full Duplex.............................................................................................................................17
6.4 Terminal Memory............................................................................................................................17
6.5 Commands for the Terminal............................................................................................................17
6.6 Lack of Standardization Solved by Terminfo..................................................................................18
6.7 The Interface....................................................................................................................................18
6.8 Emulation.........................................................................................................................................18
6.9 The Console.....................................................................................................................................19
7. Terminal Special Files such as /dev/tty............................................................................................19
7.1 Serial Port Terminals.......................................................................................................................19
7.2 Pseudo Terminals.............................................................................................................................19
7.3 The Controlling Terminal /dev/tty...................................................................................................21
7.4 /dev/ttyIN "Terminals".....................................................................................................................21
7.5 The Console: ttyN or vc/N..............................................................................................................21
7.6 Creating a Device with "mknod".....................................................................................................21
8. Some Details on How Terminals Work............................................................................................21
8.1 Terminal Memory Details...............................................................................................................21
8.2 Early Terminals...............................................................................................................................22
8.3 Escape Sequences and Control Codes (intro)..................................................................................22
Control codes..................................................................................................................................22
Escape sequences...........................................................................................................................22
8.4 Display Attributes & Magic Cookies..............................................................................................23
9. Special Features of Some Terminals..................................................................................................23
9.1 Color................................................................................................................................................23
9.2 Multiple Sessions.............................................................................................................................24
9.3 Printer/Auxiliary Port......................................................................................................................24
9.4 Pages...............................................................................................................................................24
9.5 Character-Sets.................................................................................................................................25
Graphics (Line Drawing, etc.).........................................................................................................25
National Replacement Characters (obsolete)..................................................................................26
9.6 Fonts.................................................................................................................................................27
9.7 Keyboards & Special Keys..............................................................................................................27
ii
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
9.8 Mouse...............................................................................................................................................28
10. Terminal Emulation (including the Console).................................................................................28
10.1 Intro to Terminal Emulation..........................................................................................................28
10.2 Don't Try to Use TERM Variable for Emulation.........................................................................29
10.3 Serial Communication (Dialing) programs....................................................................................29
Emulation under X Window............................................................................................................29
Real terminals may be better...........................................................................................................30
10.4 Testing Terminal Emulation..........................................................................................................30
10.5 The Linux Console........................................................................................................................30
10.6 Emulation Software.......................................................................................................................31
Make a Linux PC a serial port terminal.........................................................................................31
Make a Linux PC an IBM network terminal...................................................................................31
Make a non-Linux PC a terminal...................................................................................................32
11. Flow Control (Handshaking)..........................................................................................................32
11.1 Why Is Flow Control Needed ?.....................................................................................................33
11.2 Padding.........................................................................................................................................33
11.3 Overrunning a Serial Port..............................................................................................................33
11.4 Stop Sending..................................................................................................................................34
11.5 Keyboard Lock..............................................................................................................................34
11.6 Resume Sending............................................................................................................................35
11.7 Hardware Flow Control (RTS/CTS etc.)......................................................................................35
RTS/CTS, DTR, and DTR/DSR Flow Control...............................................................................35
Connecting up DTR or DTR/DSR Flow Control............................................................................35
Old RTS/CTS handshaking is different...........................................................................................36
Reverse Channel..............................................................................................................................36
11.8 Is Hardware Flow Control Done by Hardware ?...........................................................................36
11.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control.....................................................................36
12. Physical Connection.......................................................................................................................37
12.1 Introduction....................................................................................................................................37
12.2 Multiport I/O Cards (Adapters).....................................................................................................37
12.3 Direct Serial Cable Connection.....................................................................................................37
Pin numbering.................................................................................................................................37
Null Modem cable pin-out (3, 4, or 5 conductor)...........................................................................37
Standard Null Modem cable pin-out (7 conductor)........................................................................38
Overcoming length limitations.......................................................................................................39
Hardware Flow Control cables........................................................................................................40
Cable tips.........................................................................................................................................40
A kludge using twisted-pair cable..................................................................................................40
Cable grounding..............................................................................................................................40
12.4 Modem Connection........................................................................................................................40
Dialing out from a terminal.............................................................................................................41
Terminal gets dialed into.................................................................................................................41
12.5 Telnet and ssh................................................................................................................................41
12.6 Terminal Server Connection..........................................................................................................42
What is a terminal server ?..............................................................................................................42
Evolution of the "terminal server"...................................................................................................42
12.7 Connector and Adapter Types.......................................................................................................43
iii
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
Sex of connector/adapters...............................................................................................................43
Types of adapters.............................................................................................................................43
DB connectors................................................................................................................................44
RJ modular connectors...................................................................................................................44
6-conductors: RJ11/14, RJ12, and MMJ.........................................................................................44
8-conductors and 10-conductors.....................................................................................................45
12.8 Making or Modifying a Cable........................................................................................................45
Buy or make ?.................................................................................................................................45
Pin numbers of 9 and 25 pin connectors.........................................................................................46
Installing DB connectors on cable ends.........................................................................................46
Installing RJ connectors.................................................................................................................47
13. Set-Up (Configure) in General........................................................................................................47
13.1 Intro to Set-Up...............................................................................................................................47
13.2 Terminal Set-Up (Configure) Overview.......................................................................................48
13.3 Computer Set-Up (Configure) Overview.......................................................................................48
13.4 Many Options................................................................................................................................48
13.5 Communication Interface Options................................................................................................49
Speed..............................................................................................................................................49
Parity & should you use it ?...........................................................................................................49
Bits/Character.................................................................................................................................50
Which Flow Control (Handshaking) ?............................................................................................50
Port select.......................................................................................................................................50
13.6 Quick Attempt................................................................................................................................51
14. Terminal Set-Up (Configure) Details.............................................................................................51
14.1 Send Escape Sequences to the Terminal........................................................................................51
14.2 Older Terminals Set-Up.................................................................................................................52
14.3 Getting Into Set-Up (Configuration) Mode..................................................................................52
14.4 Communication Options................................................................................................................52
14.5 Saving the Set-up...........................................................................................................................53
14.6 Set-Up Options/Parameters...........................................................................................................53
14.7 Emulation {Personality} {{Terminal Modes}}.............................................................................53
14.8 Display Options.............................................................................................................................53
Character Cell Size {Char Cell}......................................................................................................53
Columns/Lines.................................................................................................................................54
Cursor..............................................................................................................................................54
Display Attributes (Magic Cookies)................................................................................................54
Display Control Characters {Monitor}...........................................................................................54
Double Width/Height......................................................................................................................54
Reverse Video {Display} (Background Light/Dark)......................................................................54
Status Line.......................................................................................................................................54
Upon 80/132 Change: Clear or Preserve?.......................................................................................55
14.9 Page Related Options.....................................................................................................................55
Page Size.........................................................................................................................................55
Coupling (of cursor & display).......................................................................................................55
14.10 Reporting and Answerback..........................................................................................................55
Answerback Message (String).........................................................................................................55
Auto Answerback............................................................................................................................55
iv
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
Answerback Concealed...................................................................................................................55
Terminal ID {ANSI ID}..................................................................................................................56
14.11 Keyboard Options........................................................................................................................56
Keyclick...........................................................................................................................................56
Caps Lock {Keylock}.....................................................................................................................56
Auto Repeat {Repeat}.....................................................................................................................56
Margin Bell......................................................................................................................................56
Remapping the Keys.......................................................................................................................56
Corner Key (for Wyse only)............................................................................................................56
Numeric Keypad or Arrow Keys Sends..........................................................................................57
What does shifted-del and shifted-bs send?....................................................................................57
PC Scan Codes................................................................................................................................57
Alternate Characters........................................................................................................................57
14.12 Meaning of Received Control Codes...........................................................................................57
Auto New Line {Newline}..............................................................................................................57
Auto Line Feed {Rcv CR}..............................................................................................................58
Recognize Del (Wyse Only ??) or Null..........................................................................................58
14.13 Where New Text Goes.................................................................................................................58
Line Wrap........................................................................................................................................58
Scrolling..........................................................................................................................................58
New Page?.......................................................................................................................................59
14.14 Function Keys.............................................................................................................................59
14.15 Block Mode Options....................................................................................................................59
Forms Display.................................................................................................................................59
Send Entire Block ?.........................................................................................................................59
Region to Send................................................................................................................................59
Block/Page terminator.....................................................................................................................60
14.16 Locks............................................................................................................................................60
14.17 Screen Saver {Scrn Saver}..........................................................................................................60
14.18 Printer...........................................................................................................................................60
15. Computer Set-Up (Configure) Details............................................................................................60
15.1 Getty (used in /etc/inittab)............................................................................................................60
Introduction to Getty.......................................................................................................................60
Getty exits after login (and can respawn)........................................................................................61
If getty run from command line: Programs get stopped.................................................................62
agetty (may be named getty)..........................................................................................................62
Agetty's auto-detection of parity problems.....................................................................................63
8-bit data bytes (plus parity)...........................................................................................................63
getty (part of getty_ps)...................................................................................................................64
mgetty..............................................................................................................................................65
15.2 Stty & Setserial.............................................................................................................................65
15.3 Setserial.........................................................................................................................................65
Setserial problems with linmodems, laptops...................................................................................65
Introduction.....................................................................................................................................65
Serial module unload.......................................................................................................................67
Giving the setserial command.........................................................................................................67
Configuration file............................................................................................................................67
v
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
Probing...........................................................................................................................................68
Boot-time Configuration................................................................................................................69
Edit a script (required prior to version 2.15)..................................................................................69
Configuration method using /etc/serial.conf, etc............................................................................70
IRQs.................................................................................................................................................71
Laptops: PCMCIA..........................................................................................................................71
15.4 Stty................................................................................................................................................71
Introduction.....................................................................................................................................71
Flow control options........................................................................................................................72
Using stty at a "foreign" terminal....................................................................................................73
Two interfaces at a terminal...........................................................................................................73
Where to put the stty command ?...................................................................................................74
Obsolete redirection method...........................................................................................................74
15.5 Terminfo & Termcap (brief).........................................................................................................75
15.6 Setting TERM and TERMINFO....................................................................................................75
What is the terminfo name of my terminal ?..................................................................................75
15.7 Rarely Needed /etc/ttytype File.....................................................................................................76
15.8 Login Restrictions.........................................................................................................................76
15.9 Run Command Only If TERM=my_term_type.............................................................................76
Example for ls Function.................................................................................................................76
15.10 Character Mapping: mapchan.....................................................................................................77
16. Terminfo and Termcap (detailed)...................................................................................................77
16.1 Intro to Terminfo............................................................................................................................77
16.2 Terminfo Database........................................................................................................................77
Introduction.....................................................................................................................................77
Where is the database located ?.......................................................................................................78
Compiled database locations..........................................................................................................78
Source-code database locations......................................................................................................78
Terminfo Compiler (tic).................................................................................................................78
Look at Your Terminfo..................................................................................................................78
Deleting Data Not Needed..............................................................................................................79
16.3 Bugs in Existing Terminfo Files (and Hardware)..........................................................................79
16.4 Modifying Terminfo Files.............................................................................................................79
16.5 Init String......................................................................................................................................79
16.6 TERM Variable.............................................................................................................................80
16.7 Terminfo/Termcap Documents.....................................................................................................80
17. Using the Terminal..........................................................................................................................80
17.1 Intro to Using the Terminal............................................................................................................80
17.2 Starting Up the Terminal...............................................................................................................81
17.3 Terminal (Serial) Device Driver....................................................................................................81
17.4 Problems with Editors....................................................................................................................81
emacs...............................................................................................................................................81
vi and Cursor-Keys.........................................................................................................................81
17.5 Problem with Slow Scrolling........................................................................................................82
17.6 Bugs in Bash.................................................................................................................................82
A fixed Bash bug.............................................................................................................................83
17.7 Color ls Corruption........................................................................................................................83
vi
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
17.8 Display Freezes (hung terminal)...................................................................................................83
17.9 Corrupted Terminal Interface.......................................................................................................84
Symptoms and some fixes..............................................................................................................84
Sent terminal binary characters......................................................................................................84
Reset command was broken but now fixed.....................................................................................85
Character corruption........................................................................................................................85
Abnormally exited a program.........................................................................................................85
17.10 Special (Control) Characters.......................................................................................................85
Command-Line Editing...................................................................................................................86
Interrupting (& Quit, Suspend, EOF, Flush)...................................................................................86
Stop/Start Scrolling.........................................................................................................................86
Take next character literally............................................................................................................87
17.11 Viewing Latin1 Files on a non-Latin1 terminal...........................................................................87
17.12 Eliminating Overstriking in Files................................................................................................87
17.13 Inspecting the Interface................................................................................................................87
17.14 Changing the Terminal Settings.................................................................................................87
setterm.............................................................................................................................................88
tput...................................................................................................................................................88
echo.................................................................................................................................................88
Saving changes................................................................................................................................88
17.15 Multiple Sessions.........................................................................................................................88
17.16 Logging Out.................................................................................................................................88
17.17 Chatting between Terminals, Spying...........................................................................................89
17.18 Sharing the Serial Port.................................................................................................................89
17.19 Browsers for Text-Terminals.......................................................................................................90
18. Special Uses for a Terminal.............................................................................................................90
18.1 Make a Serial Terminal the Console.............................................................................................91
For Kernels 2.2 or higher................................................................................................................91
For Kernels before 2.2.....................................................................................................................92
18.2 Run Linux without a Monitor........................................................................................................92
18.3 Use a Keyboardless Terminal as the Monitor...............................................................................92
How it works...................................................................................................................................92
Example configuration....................................................................................................................93
19. Trouble-Shooting............................................................................................................................93
19.1 Terminal Was Working OK..........................................................................................................94
19.2 Terminal Newly Installed.............................................................................................................94
19.3 Is the Terminal OK ?.....................................................................................................................95
19.4 Missing Text.................................................................................................................................95
19.5 All Keys Work Erratically; Must Hit a Key a Few Times............................................................95
19.6 ... respawning too fast: disabled for 5 minutes.............................................................................96
What's happening............................................................................................................................96
Getty line in /etc/inittab file incorrect.............................................................................................96
No modem control signal................................................................................................................96
No such serial device.......................................................................................................................96
No serial support.............................................................................................................................96
Key shorted.....................................................................................................................................97
19.7 Fails Just After Login...................................................................................................................97
vii
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
19.8 Can't Login....................................................................................................................................97
19.9 Garbled Login Prompt..................................................................................................................97
19.10 No Login Prompt........................................................................................................................98
Terminal was working OK..............................................................................................................98
More diagnose.................................................................................................................................98
Diagnose problem from the console...............................................................................................98
Measure voltages............................................................................................................................98
19.11 Displays Foreign/Weird Characters/Symbols.............................................................................99
19.12 Displays Escape Sequences........................................................................................................99
Telnet...............................................................................................................................................99
Terminal set to display escape sequences.....................................................................................100
19.13 Slow: pauses of several seconds between bursts of characters..................................................100
19.14 Cursor Jumps............................................................................................................................100
19.15 Terminal doesn't scroll..............................................................................................................100
19.16 Serial Monitoring/Diagnostics..................................................................................................101
19.17 Local Mode...............................................................................................................................101
19.18 Serial Electrical Test Equipment..............................................................................................101
Breakout Gadgets, etc....................................................................................................................101
Measuring voltages........................................................................................................................102
Taste voltage..................................................................................................................................102
20. Repair & Diagnose........................................................................................................................102
20.1 Repair Books & Websites...........................................................................................................102
Books.............................................................................................................................................102
Websites........................................................................................................................................102
20.2 Safety...........................................................................................................................................103
20.3 Appearance of Display.................................................................................................................103
20.4 Diagnose......................................................................................................................................104
Terminal Made a Noise or Smoked...............................................................................................104
Terminal Made No Noise..............................................................................................................104
20.5 Detective work.............................................................................................................................104
20.6 Error Messages on the Screen......................................................................................................105
Keyboard Error..............................................................................................................................105
Checksum Error in NVR...............................................................................................................105
20.7 Capacitors....................................................................................................................................105
20.8 Keyboards...................................................................................................................................106
Interchangeability..........................................................................................................................106
How They Work............................................................................................................................106
Modern vs Old Keyboards............................................................................................................106
One Press Types 2 Different Characters......................................................................................106
Keyboard doesn't work at all.........................................................................................................106
Typing b displays bb, etc. (doubled).............................................................................................107
Row upon row of the same character appears...............................................................................107
Key sticks in down position (individual switches)........................................................................107
Key electrically shorted.................................................................................................................107
Liquid spilled on the keyboard......................................................................................................107
Cleaning keyboard contacts..........................................................................................................108
Keyboards with membranes..........................................................................................................108
viii
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
Keyboards with individual switches.............................................................................................108
21. Appendix A: General.....................................................................................................................109
21.1 List of Linux Terminal Commands.............................................................................................109
Sending a command to the terminal..............................................................................................109
Configuring the terminal device driver.........................................................................................110
Terminfo........................................................................................................................................110
Other..............................................................................................................................................110
21.2 The Internet and Books................................................................................................................110
Terminal Info on the Internet.......................................................................................................110
Books related to terminals.............................................................................................................110
Entire books on terminals..............................................................................................................110
Books with chapters on terminals.................................................................................................111
21.3 Non-Linux OSs...........................................................................................................................111
22. Appendix B: Escape Sequence Commands Terminology............................................................112
22.1 Esc Sequence Lists......................................................................................................................112
22.2 8-bit Control Codes......................................................................................................................112
22.3 Printer Esc...................................................................................................................................113
22.4 Reports.........................................................................................................................................113
22.5 Cursor Movements.......................................................................................................................113
22.6 Pages (definition)........................................................................................................................113
23. Appendix C: Serial Communications on EIA-232 (RS-232)........................................................114
23.1 Intro to Serial Communication....................................................................................................114
23.2 Voltages.......................................................................................................................................114
Voltage for a bit.............................................................................................................................114
Voltage sequence for a byte.........................................................................................................115
23.3 Parity Explained..........................................................................................................................115
23.4 Forming a Byte (Framing)...........................................................................................................115
23.5 Limitations of EIA-232................................................................................................................116
Low Speed & Short Distance........................................................................................................116
Successors to EIA-232.................................................................................................................116
Line Drivers...................................................................................................................................116
23.6 Synchronization & Synchronous................................................................................................116
How "Asynchronous" is Synchronized.........................................................................................116
Defining Asynchronous vs Synchronous......................................................................................117
Synchronous Communication.......................................................................................................117
23.7 Block Mode.................................................................................................................................117
Introduction to Block Mode..........................................................................................................117
Types of Block Modes, Forms......................................................................................................118
Efficiency......................................................................................................................................118
Problems with block mode............................................................................................................118
23.8 EIA-232 (RS-232) Books...........................................................................................................119
23.9 Serial Software.............................................................................................................................119
24. Appendix D: Notes by Brand/Model.............................................................................................119
24.1 Adds.............................................................................................................................................119
24.2 CIT...............................................................................................................................................119
24.3 IBM Terminals............................................................................................................................119
IBM 3153......................................................................................................................................120
ix
Text-Terminal-HOWTO
Table of Contents
Text-Terminal-HOWTO
24.4 Teletypes.....................................................................................................................................120
24.5 VT (originally DEC, now Boundless)........................................................................................120
24.6 Links............................................................................................................................................121
24.7 Qume............................................................................................................................................121
24.8 Wyse Terminals..........................................................................................................................121
Wyse 50.........................................................................................................................................121
Wyse 60.........................................................................................................................................121
Wyse 85.........................................................................................................................................121
Wyse 99-GT..................................................................................................................................121
Wyse 150.......................................................................................................................................122
Wyse 185.......................................................................................................................................123
Low Emissions: -ES......................................................................................................................123
x
Text-Terminal-HOWTO
David S. Lawyer mailto:[email protected]
v1.41 February 2008
This document explains what text terminals are, how they work, how to install and configure them, and
provides some info on how to repair them. If you don't have a terminal manual, it may be of help. While it was
originally written for real terminals on a Linux system, much of it is also applicable to terminal emulation and
may be helpful for non-Linux systems.
1. Introduction
• 1.1 Copyright, Trademarks, Disclaimer, & Credits
• 1.2 Future Plans: You Can Help
• 1.3 New Versions of this HOWTO
• 1.4 Related HOWTOs, etc.
• 1.5 Terminology Used in this Document
• 1.6 What is a Terminal ?
• 1.7 What is a Text-Terminal ?
2. Types of Terminals
• 2.1 Dumb Terminals
• 2.2 Text Terminals
• 2.3 Graphic GUI Capabilities of Text Terminals
4. Quick 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 Terminals
• 5.7 Are Text Terminals Obsolete ?
Text-Terminal-HOWTO 1
Text-Terminal-HOWTO
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.7 Fails Just After Login
• 19.8 Can't Login
• 19.9 Garbled Login Prompt
• 19.10 No Login Prompt
• 19.11 Displays Foreign/Weird Characters/Symbols
• 19.12 Displays 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
1. Introduction
For a quick attempt to install a terminal see Quick Install.
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): [email protected].
2. License the derivative work in the spirit of this license or use GPL. Include a copyright notice and at
least a pointer to the license used.
3. Give due credit to previous authors and major contributors.
If you're considering making a derived work other than a translation, it's requested that you discuss your plans
with the current maintainer.
Disclaimer
While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please
let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally
responsible for any errors.
Trademarks.
Any brand names (starts with a capital letter such as MS Windows) should be assumed to be a trademark).
Such trademarks belong to their respective owners.
Credits
Greg Hankin's Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A Terminal Connected To My PC?"
was incorporated into v1.00 at various places (with Greg's permission). v1.09 has about 25 changes (and error
corrections) suggested by Alessandro Rubini who reviewed this terminal as a console for a monitorless PC
(using ttysnoop). (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.
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 solve this problem would be for terminal manufacturers put their manuals on the Internet.
For a full revision history going back to the first version in 1998 see the source file (in linuxdoc format): (cvs)
Text-Terminal-HOWTO.sgml
• v1.41 Feb. 2008" Better clarity re emulation. Illusion when revere-video is reversed. Problem with
slow scrolling. Wyse text terminals discontinued and Boundless was bankrupt. Update on text web
browsers. gtkterm, X Window now has many terminal emulators. Symantec no longer selling
Procomm.
• v1.40 Dec. 2006 Picocom is like minicom. Devfs obsolete so removed tts/1, etc. Updated pseudo
terminals. More about telnet, ssh, and non-serial port interfaces. IBM terminal emulation over telnet.
Kermit for MS does terminal emulation. Ports of minicom to Mac. Fixed/removed broken links.
Copyright 7
Text-Terminal-HOWTO
• Serial-HOWTO has info on Multiport Serial Cards used for both terminals and banks of modems. It
has general technical info on the serial port including troubleshooting it.
• Low-Level Terminal Interface part of "GNU C Library Reference Manual" (in libc (or glibc) docs
package). It covers the detailed meaning of "stty" commands, etc.
• NCURSES-Programming-HOWTO
• MacTerminal mini-HOWTO
• Modem-HOWTO
• Serial-Programming-HOWTO
• NC mini-HOWTO
• NCD-X-Terminal mini-HOWTO
• XDM-and-X-Terminal mini-HOWTO
• Connecting-X-Terminals-to-Linux-Mini-HOWTO
• NCD-HOWTO
• Thinclient-HOWTO
• Xterminals-HOWTO
• Xterm-Title-HOWTO (only for changing the title of a window)
Today, real terminals are becoming rarities and most people that use terminals use a personal computer to
emulate a terminal. Almost everyone who uses Linux 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.
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 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 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 a terminal and use the same computer simultaneously
with others. Such user interfaces are not "clients".
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.
The communication uses characters (letters) encoded using a code chart for the character set being used.
Usually, the first 128 bytes out of 256 possible bytes use ASCII codes. Terminals for Unix-like systems,
normally connect to computers via a cable running between the asynchronous serial ports (RS-232-C =
EIA-232-D) of the host computer and the terminal. Sometimes the connection is via modem or terminal
server, etc.
Other names for "text 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 the send key
(or the like) is pressed, a block of characters (sometimes just a line of characters) is sent to the computer all at
once. Block mode (as of late 1998) is not supported by Linux. See section Block Mode.
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.
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).
Such clients may be created from an ordinary PC by using software or may be a stand-alone piece of
hardware. But the stand-alone hardware will often use a conventional PC monitor plus a small box for the
computer part of the hardware. Linux seems to favor the use of PCs as a client.
Some claim that text-terminals are also thin clients but they are not really since they don't conform to the
client-server model. However, connecting a terminal via telnet does invoke the client-server model in the use
of telnet as a means of transport of data. But the relation of the text-terminal to it's host is not one of
client-server. The text-terminal is just another means of access to the computer just like the monitor and its
keyboard is. One could apply this same reasoning to a thin client and say that the client-server relationship is
only for the transport of data.
Thus a thin client is like a terminal. It has a GUI with a mouse that makes it seem like you are using a
computer. You are, but that computer may be far away and have many other people using it at the same time
you are. Communication is over a high speed network cable or even over the Internet. Some thin clients can,
in addition, emulate a text terminal and have a serial port connector for that purpose. One even has a USB
interface.
There are various types of thin clients. One type is the "Window Terminal" which runs under MS servers (and
software). Another type is the "network computer" which is supposed to be platform neutral. This implies they
should work with both MS Windows and Linux but early models may not be easy to use with Linux. For
Linux, the X Window protocol is used. See Thin clients and NCs under Linux
The server for these clients usually runs MS's Terminal Services (for Windows 2000 servers). Prior to this
there was Windows NT Terminal Server Edition (starting mid 1998 with codename "Hydra"). MS uses RDP
(Remote Desktop Protocol) which is based on the ITU T.120 protocol. In addition, there is an optional ICA
protocol (with added features) which can inter-operate with RDP.
Prior to this there was a modified Windows NT 3.51 (1995) called "WinFrame" by Citrix using the
proprietary ICA protocol (Independent Computing Architecture). After MS came out with its own terminal
server, Citrix still remained on the scene. It created MetaFrame software (formerly pICAsso) as an add-on to
MS's Terminal Server (or Services) so that it could support ICA-based terminals and provide other additional
features. Before MS got into the act, there were other proprietary systems for terminals that could display the
MS Windows GUI but later on they all switched to support Microsoft's system.
PCs running Linux can be turned into ICA based client terminals using "free" (in price only) proprietary ICA
client software from Citrix: Installing the Linux Client. Unfortunately, MS requires that you purchase a
license to cover the clients, even if the clients all run Linux. So if you want to save money on software costs
by using Linux, you'll have to go all-Linux and use both Linux servers and clients using the free X-Window
protocol.
The above is sometimes called "network computing" since the terminals and servers connect to each other
over a network (such as the common TCP/IP based network used by both Linux and MS). Network computers
may be somewhat different as described below.
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.
"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
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.
Hardware hookups
There are 3 different types of hardware arrangements for thin clients. The first type just uses a PC computer as
a thin client by emulating a thin client. It really isn't a thin client but it behaves like one. The second type
looks just like a text-terminal. It just looks like a monitor, with a connector for a keyboard and another
connector for a network cable. It's a dedicated thin client and can't be used for anything else. The third type
looks like a tiny computer. It uses a standard PC monitor and keyboard both of which plug into a small box
which is a "thin" computer. This box provides an interface between the monitor/keyboard and the network.
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.
3.3 Emulation on a PC
Since a PC has a screen and keyboard (as does a terminal) but also has much more computing power, it's easy
to use some of this computing power to make the PC computer behave like a text terminal. This is called
"terminal emulation". They usually emulate text-terminals. See Terminal Emulation
4. Quick Install
This is a quick procedure to install a terminal without going through a Setup procedure for both the terminal
and the host computer. It probably will not work right if the terminal happens to have been set up
incompatible with the computer. If you don't understand some of it you'll need to consult other parts of this
document for more info.
To install a terminal, first look in /etc/termcap or terminfo.src to find an entry for it (see Terminfo
and Termcap (detailed)). Figure out what serial port you'll connect it to and what the tty designation is for that
port e.g. ttyS1, 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.
"distributed" computing over a network is also a type of time sharing. It might be better described as
"centralized" computing. But the central computer may be connected to the rest of the world via a network so
that terminal users may send email, browse the Internet with the lynx browser, etc. So it's not exactly
"centralized" either.
Terminals have seldom been used with PC's because the popular operating systems used for them (Windows,
DOS, and Mac) were not multiuser until 1998 (available for MS Windows NT) and previously could not
support terminals very well. Now that Linux, a multiuser operating system, is freely available for PC's, the use
of terminals with PC's becomes more feasible. The drawback is that text terminals are not smart enough to
support the type of graphical user interface (GUI) that many computer users today normally expect.
If several people use the same computer as the same time, there is a reduction in the amount of hardware
needed for the same level of service. One type of savings is due to code sharing. The application files on hard
disks are shared as well as shared libraries in memory (even when people are running different programs
provided they use some of the same functions in their code). Another type of savings is due to reduction of
peak load. The hardware of a single PC may be idle most of the time as people slowly type in information,
think, talk, or are away from their desks. Having several people on the same computer at once makes good use
of much of this idle time which would otherwise be wasted.
These savings are substantial. One may roughly estimate (using statistical theory) that for 9 persons (8
terminals & 1 console) the shared PC only needs only about 3 times as much capacity (in memory, disk
storage, CPU power, etc.) as a single PC in order to provide the same level of service per person. Thus the
computational hardware for such a shared system should only cost about 1/3 as much per user. However, the
cost of the display hardware (CRT's, keyboards, video electronics, etc.) is about the same for both cases. The
terminals have the added cost of requiring additional serial ports at the host computer.
For a fair comparison with PC's, the terminals should have the same capabilities as the PC monitors.
Unfortunately, color graphic terminals for Linux (X Window) with high speed communication cost about as
much as a PC so in this case there not much (if any) savings in hardware costs. But for text terminals there
will be some savings, especially if the terminals are obtained used at low cost.
The reasons that text terminals are not fully obsolete are:
• The resolution of characters on the screen is better on monochrome terminals than for monitors in text
mode.
• Many people don't need full screen graphics.
• Since running a text-terminal (in contrast to a GUI-graphics terminal) doesn't consume much of a
modern PC's resources, a large number of terminals may be efficiently run from one PC.
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 log
in (after giving their passwords) and then have access to the computer. When it's time to shut the terminal
down, one normally logs out and turns the terminal off. See Login Restrictions regarding restricting logins
(including allowing the root user to log in at terminal).
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.
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.
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
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.
To send text to a terminal you may redirect standard output of some command-line command to the
appropriate special file. For example typing "echo test > /dev/ttyS1" at the command prompt should send the
word "test" to the terminal on ttyS1 (COM2) provided you have write permission on /dev/ttyS1. Similarly,
typing "cat my_file > /dev/ttyS0" will send the contents of the file my_file to COM1 (ttyS0).
6.8 Emulation 19
Text-Terminal-HOWTO
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:
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.
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).
Control codes
The control codes (or control characters) consist of the first 32 bytes of the ASCII alphabet. They include the
following: carriage-return (cursor to far left), line-feed (cursor down one line), backspace, escape-character,
tab, and bell. They do not normally show on the screen. There is usually a command which you may give to
your terminal which will result in them being displayed when they are received by the terminal. It's called
something like "Display Controls" or "Monitor". If you do this then the display may look a mess since escape
sequences, which all start with the ESC (escape) control character, are no longer executed. Words which
should appear at the top or bottom of the screen will show up in other locations. The escape sequences to
reposition the cursor display on the screen but the cursor doesn't move to where the escape sequence says.
Escape sequences
Since there are not nearly enough control codes to do everything (and for some reason, not all of them are
utilized) many escape sequences are used. They consist of the "escape" (ESC) control character followed by a
sequence of ordinary characters. Upon receiving an escape character, the terminal examines the characters
following it so that it may interpret the sequence and carry out the intended command from the computer.
Once it recognizes the end of a valid sequence, further characters received just display on the screen (unless
they are control codes or more escape sequences). Some escape sequences may take parameters (or
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.
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.
However, changing the brightness, etc. gives a lot of possibilities. For example, a black and white
(monochrome) terminal can have white, grey, and black by varying the brightness. Some words can be black
on a light grey background while other are highlighted by black on white. In addition there is white on black,
underlining, and blinking.
Color works like the color on a computer monitor or TV screen. The CRT has three colors of dots on it with
each color controlled by its own electron beam (3 beams). Monochrome has inherently better resolution since
it doesn't depend on dots permanently fixed on the screen. For text terminals the only use of color is to
differentiate text and this advantage is not always worth the cost of worse resolution. Thus monochrome may
be better since it also costs less.
Escape sequences 23
Text-Terminal-HOWTO
There is a program called vtprint which is designed to send a print job (text only) to your terminal to be
printed on a printer attached to the terminal. It's homepage is vtprint. It's also included in the Debian
distribution of Linux. xprt (also in Debian) seems to do something similar, but only for X Window terminals
??
Using the printer port to print may be useful if you don't have an extra port on your PC for a printer or for
"point of sale" use in a store. "Transparent print mode" is where whatever the PC sends out to the terminal
goes instead to the printer. If you want the printer to be able to send bytes to the PC (in the reverse direction)
then (per Wyse) it's "bidirectional mode". The Wyse "auxiliary print mode" is just transparent print mode
where the terminal screen monitors what's being printed.
9.4 Pages
Many terminals permit the storage of more than one page in their video memory. Sometimes the page size is
the same as the screen, but sometimes it is larger so that scrolling will reveal unseen parts of a page. So when
one looks at a screen, there may be hidden text on the same page above or below the display. In addition, if
there is more than just one page, there may be hidden text on these other pages. One use for pages is on
terminals that support dual sessions. Each session may have its own page and one may switch back and forth
between them.
Even if you only have a one-page-terminal with the page sized equal to what is displayed on the screen, you
will still see other pages of a file (etc.) as the host sends more data to the terminal. One advantage to having
additional pages stored in the terminal memory is so that you can jump to them instantly without waiting a
second or so for them to be transmitted from the host.
Multiple pages is supported by ncurses. There is also a commercial program called "Multiscreen" which
supports multiple pages but probably not for Linux ?? Multiscreen is reported to be part of SCO and is
something like the virtual terminals on a Linux PC console. The Linux program "screen" makes it look like
you have multiple pages but they are stored in the computer and but you can have only one page-like window
9.5 Character-Sets
A character-set is normally represented by a list (or table or chart) of characters along with the byte code
assigned to each character. The codes for a byte range from 0 to 255 (00 to FF in hexadecimal). In MS-DOS,
character-set tables are called "code-pages". You should examine such a table if you're not familiar with them.
They are sometimes included in printer and terminal manuals but also are found on the Internet.
Many character sets include letters from foreign languages. But they may also include special characters used
to draw boxes and other special characters.
ASCII was the traditional English character set used on text terminals It is a 7-bit code but will usually work
OK even if your terminal is set to 8-bit mode. In 8-bit mode with ASCII, the high order bit is always set to
zero. Other character-sets are usually available and usually use 8-bit codes (except on very old terminals
where the only choice is ASCII). The first half of most character-sets are the conventional 128 ASCII
characters and the second half (with the high-order bit set to 1) belong to a wide variety of character-sets.
Character sets are often ISO standards. To get specialized character sets on a terminal, you may need to
download a soft-font for that character-set into the memory of the terminal. Many terminals have a number of
built-in character sets (but perhaps not the one you need).
Here are some common 8-bit character sets. CP stands for Code Page character sets invented by IBM: CP-437
(DOS ECS), ISO-8859-1 (Latin-1), CP-850 (Multilingual Latin 1 --not the same as ISO Latin-1), CP-1252
(WinLatin1 = MS-ANSI). MS Windows uses CP-1252 (WinLatin1) while the Internet often uses Latin-1.
There are several ISO-8859- character sets in addition to Latin-1. These include Greek (-7), Arabic (-6),
Eastern European (-2), and a replacement for Latin-1 (-15) called Latin-9. There are many others. For
example, KOI8-R is more commonly used for Russian than IS0-8859-5. Unicode is a very large character-set
where each character is represented by 2 bytes instead on just one byte.
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.4 Pages 25
Text-Terminal-HOWTO
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.
There were a lot of problems with this, since it was done mostly by companies which sold computer terminals
with a resulting lack of standardization. Another problem was that sometimes the purged symbols were
needed. This problem was solved in the 1980's and 1990's with the adoption of 8-bits/byte character sets
which had many more letters.
Many West-European languages only needed several additional letters which were not in ASCII. To get them
in 7-bit code, they borrowed the codes for seldom used ASCII symbols:
@[\]^`{\}~
The symbols $ and # are sometimes used also. So when using these replacement character sets, you are
deprived of using certain of these ASCII symbols since they now are used for the new non-ASCII letters. Now
that 8-bit character codes have replaced 7-bit ones, it's better to use an 8-bit code which has both all the ASCII
symbols plus the non-ASCII characters for various languages. There's also Unicode which replaces 8-bit
codes with the same code scheme to cover all languages (well almost all significant ones).
ISO-646 (for 1972 and later) permitted using National Replacement Characters (7-bit). It specified that the
above mentioned character codes may be borrowed, but doesn't specify which national characters are to
replace them. Some countries standardized the replacements by registering them with ECMA.
Many terminals exist which support these national replacement characters but you probably don't want to
implement this support unless you have some old files to read. Very old terminals may only support the
national characters for the country in which they were sold. Later terminals offered a choice of languages.
Modem terminals are 8-bit and don't need "national replacements". Replacement characters exist for the
following languages/countries: British, Cuba (Spanish), Dutch, Finnish, French, French Canadian, German,
Hebrew, Hungarian, Italian, Norwegian/Danish, Portuguese, Spanish, Swedish, Swiss (German).
Here's tables for some character sets taken from Kermit and Unisys documents:
Swedish Danish
ASCII German Finnish Norwegian French
9.6 Fonts
Most terminals made after the mid 1980's can accept downloaded soft-font. This means that they can display
almost any character set provided that you can find the soft-font for it. If you can't find the needed soft-font,
you can always create your own. A free font editor for this is called BitFontEdit (written by the author of this
document) and 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
• 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.8 Mouse
A few text-terminals support a mouse. When the mouse is clicked, an escape sequence is sent to the host to
tell it where the mouse is. For a mouse on VT terminals see
http://www.cs.utk.edu/~shuford/terminal/dec_vt_mouse.html These escape codes for mice are called "DEC
Locator sequences". The FALCO Infinity Series of terminals, model ANSI-G supports it. Do any linux
applications support this ??
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, 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.
If you set it to something else you are fibbing to an application program. As a result, it will incorrectly
interpret certain escape sequences from the console resulting in a corrupted interface. Since the Linux console
behaves almost like a vt100 terminal, it could still work almost OK if you falsely claimed it was a vt100 (or
some other terminal which is close to a vt100). In this case it may seeming work OK most of the time but
once in a while will make a mistake.
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).
In X Window, using a terminal emulator give you the equivalent of a console and for the 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.
Minicom, picocom, or gtkterm 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, doesn't
have automatic dialout capability. Gtkterm might be called a "mini-mini-minicom".
Skip this paragraph if you use picocom. 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's a specialized Linux distribution: Serial Terminal Linux. It will turn a PC to into a minicom-like
terminal. It's small (fits on a floppy) and will not let you use the PC for any other purpose (when it's running).
See http://www.eskimo.com/~johnnyb/computers/stl/. It will let you have more than one session running
(similar to virtual terminals), one for each serial port you have.
TERM (non-free commercial software from Century Software) Terminal Emulator can emulate Wyse60, 50;
VT 220, 102, 100, 52: TV950, 925, 912; PCTERM; ANSI; IBM3101; ADM-1l; WANG 2110. Block mode is
available for IBM and Wyse. It runs on a Linux PC.
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.
Today Windows comes with "HyperTerminal" (formerly simply called "Terminal" in Windows 3.x and DOS).
Competing with this is "HyperTerminal Private Edition" http://www.hilgraeve.com/htpe/index.html which is
non-free to business. It can emulate vt-220. The Windows "terminals" are intended for calling out with a
modem but they should also work as directly connected terminals?? Turbosoft's TTWin can emulate over 80
different terminals under Windows. See http://www.ttwin.com/ or http://www.turbosoft.com.au/ (Australia).
See also WRQ
For using a Mac computer to emulate a common terminal use either Linux's "minicom" (ported to the Mac OS
X) or the old "zterm" (shareware). For very old Macs prior to OS X, see the mini-howto: Mac-Terminal.
Carnation Software has non-free software to emulate a wide variety of terminals on a Mac. Mac OS X has a
"terminal" program that gives you a terminal window just like the xterm window in Linux's X Window. In
that window you may run "minicom" (if it's available). Both the "fink" and "darwinports" projects have ported
minicom to the Mac, but they may not have the most recent version and you might need to compile minicom
yourself.
One place to check terminal emulation products is Shuford's site, but it seems to lists old products (which may
still work OK). The fact that most only run under DOS (and not Windows) indicates that this info is dated.
See http://www.cs.utk.edu/~shuford/terminal/term_emulator_products.txt.
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:
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.
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
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.
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.
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.
For older terminals, RTS may have this meaning and goes high when the terminal has data to send out. The
above use is a form of flow control since if the modem wants the computer to stop sending it drops CTS
(connected to CTS at the computer) and the computer stops sending.
Reverse Channel
Old hard-copy terminals may have a reverse channel pin (such as pin 19) which behaves like the RTS pin in
RTS/CTS flow control. This pin but will also be negated if paper or ribbon runs out. It's often feasible to
connect this pin to the CTS pin of the host computer. There may be a dip switch to set the polarity of this
signal.
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.
Make sure you have the right kind of cable. A null modem cable bought at a computer store may do it (if it's
long enough), but it probably will not work for hardware flow control. Such a cable may be labeled as a serial
printer cable. Only larger computer stores are likely to stock such cables. A "modem cable" will not work
since the wires go straight thru (and don't cross over). See Buy or Make your own cable. Make sure you are
connecting to your PC's serial port at the male DB25 or the DB9, and not to your parallel port (female DB25).
Pin numbering
Pin numbers are often printed on the plastic right next to the pins. You may need a bright light and/or a
magnifying glass to read them. Looking at the male pins of a DB connector with the wider row up, the pin in
the upper left is 1 (there is no pin 0). Then the next pin in this row is 2, etc. At the end of this row is pin 5 or
13. Then the next pin (6 or 14) is in the next row all the way to the left and below pin 1. If you look at the
female connector with the wider row up, then pin 1 is in the upper right corner.
If you have a DB9 connector on both your serial port and terminal:
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" ).
Alternatively, a full DB9-DB25 file-transfer (null-modem) cable (will not work with terminal hardware
handshaking; see above):
(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.
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
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.
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 ??
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.
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.
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.
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.
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.
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.
An adapter looks about like a connector but it has two ends with pins. It is just like a cable that is so short that
there is no cable part left at all --just different connectors on each end is all that remains. The adapter just
plugs in to two other connectors on each side of it. It allows two incompatible connectors to mate with each
other by going in between them. Except that even for two connectors that will mate with each other, an
adapter may be used to connect the cable conductors together in other than straight-thru. Obviously, one may
use a special cable (perhaps homemade) as a substitute for an adapter.
Sex of connector/adapters
Connectors (or one side of adapters) are either male or female. The connectors that have pins are male and the
ones that have sockets (sometimes also called pins) are female. For modular connectors, the ones with
exposed contacts are plugs while the ones with internal contacts (not easy to see) are jacks. Plugs are male;
jacks are female.
Types of adapters
There are three basic types of adapters: null modem, gender changers and port adapters. Some adapters
perform more than one of these three functions.
• gender changer: Changes the sex of a cable end. Two connectors of the same sex can now connect
(mate) with each other.
• port adapter: Goes from one type of connector to another (DB9 to DB 25, etc.)
DB connectors
(For how to install a DB connector on the ends of a cable see Installing DB Connectors.) These come in 9 or
25 pins. The EIA-232 specs. call for 25 pins but since most of these pins are not used on ordinary serial ports,
9 pins is sufficient. See DB9-DB25 for the pin-out. The pins are usually numbered if you look closely enough
or use a magnifying glass.
RJ modular connectors
RJ means Registered Jack. These look like modern telephone connectors but are sometimes not compatible
with telephone connectors. See also Installing RJ Connectors. For use with serial ports they may be 6 or 8
conductor. A few are 10-conductor but may not officially belong to the RJ series.
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.
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,
Types of adapters 44
Text-Terminal-HOWTO
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:
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.
___________ ________________________________________
\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/
------ -----------------------------------
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).
Buy or make ? 46
Text-Terminal-HOWTO
Perhaps you should have used another tip that fits tighter around the pin. Using this tool, one may readily
convert a straight-thru cable to a file-transfer (null-modem) cable, etc.
There can be problems using the "insertion/extraction" tool. If the tools will not insert on the back of the pin,
it could be that the pin was not neatly crimped to the wire and is sort of square where it should be round, etc.
If a pin starts to come out but will not pull out all the way, the pin may be bent. Look at it under a magnifying
glass. Straightening a pin with needle-nose pliers may damage the gold plating but you may have to straighten
it to remove it. Sometimes a stuck pin may be pushed out with a thick screwdriver blade tip (or the like) but if
you push too hard you may gouge the plastic hole or bend the pin:.
Don't try soldering unless you know what you're doing or have read about how to do it.
Installing RJ connectors
These are telephone modular connecters one type of which is used for most ordinary telephones. But there are
many different types (see RJ Modular Connectors).
These are not easy to reuse. You might be able to pull the wires out, push in something wedged that would lift
up the gold-colored contacts and reuse the connector. There are special crimping tools used to install them; a
different tool for each type.
If you don't have a crimping tool, installation is still possible (but difficult) using a small screwdriver (and
possibly a hammer). Push in the cable wires and then push each gold-colored contact down hard with a small
screwdriver that will just fit between the insulating ridges between the contacts. You may damage it if you fail
to use a screwdriver with a head almost the same thickness as the contacts or if the screwdriver slips off the
contact as you are pushing it down. You may also use a small hammer to pound on the screwdriver (push first
by hand).
Be sure to not hurt the "remove lever" on the connecter when you push in the contacts. Don't just set it down
on a table and push in the contacts. Instead, put a shim (about 1 mm thick) that fits snugly in the crevice
between the lever and the body. For such a shim you may use thick cardboard, several calling cards, or wood.
Since the bottom of the connector (that you will put on the table) isn't level (due to the "remove lever), make
sure that the table top has something a little soft on it (like a sheet of cardboard) to help support the non-level
connector. Even better would be to put another 1mm shim under the first 6mm of the connector, supporting it
just under where you see the contacts. A soft tabletop wouldn't hurt either. Another method (I've never done
this) is to hold the connector in a vice but be careful not to break the connector.
As compared to using a crimping tool, installing it per above takes a lot longer and is much more prone to
errors and failure but it's sometimes more expedient and a lot cheaper than buying a special tool if you only
have one or two connectors to install.
major sections cover in detail the configuration of the terminal (see Terminal Set-Up and the computer (see
Computer Set-Up (Configure) Details.
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.
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.
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.
The settings for both the computer and the terminal are:
• Speed (bits/second)
• Parity
• Bits per Character
• Flow Control
• Port Select
• Set communication to full duplex (=FDX on Wyse terminals)
If the Getty (used in /etc/inittab) program can't set up the computer side the way you want, then you may need
to use one (or both) of the Stty & Setserial commands.
Speed
These must be set the same on both the terminal and the computer. The speed is the bits/sec (bps or baud rate).
Use the highest speed that works without errors. Enabling flow control may make higher speeds possible.
There may be two speeds to set at the terminal: Transmit and Receive, sometimes abbreviated T and R.
Usually they are both set the same since stty in Linux doesn't seem to have the option yet of setting them
differently. (There is an option to do this with the "stty" command but it seems to actually set them both the
same.) Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ... The slower speeds (like 600)
are for printers and hard-copy terminals.
Should you use parity at all? Parity, while not really necessary, is nice to have. If you don't have parity, then
you may get an incorrect letter here and there and wind up trying to correct spelling errors that don't really
exist. However parity comes at a cost. First, it's more complicated to set up since the default is usually no
parity. Secondly, parity will slow down the speed with which bytes travel over the serial cable since there will
be one more bit per byte. This may or may not slow down the effective speed.
For example, a hard-copy terminal is usually limited by the mechanics of the printing process. Increasing the
bytes/sec when the computer (its UART chip) is transmitting only results in more flow-control "halt" signals
to allow the mechanical printing to catch up. Due to more flow-control waits the effective speed is no better
without parity than with it. The situation is similar for some terminals: After you implement parity there may
be fewer flow-control waits per unit time resulting in more bits/sec (average). However, due to the added
parity bits the bytes/sec (average) stays the same.
One option is to install terminals with no parity. Then if parity errors are noticed, it can be implemented later.
To spot possible errors with no parity, look for any spelling errors you don't think you made. If you spot such
an error, refresh the screen (retransmit from the computer). If the error goes away, then it's likely a parity
error. If too many such errors happen (such as more than one every few hundred screens) then corrective
action is needed such as: Enable parity and/or reduce speed, and/or use a shorter/better cable. Enabling parity
will not reduce the number of errors but it will tell you when an error has happened.
Just the opposite policy is to initially enable parity. Then if no parity errors (error symbols on the CRT) are
ever seen (over a reasonable period of time, say a month or two) it may be safely disabled.
Bits/Character
This is the character size (the number of data bits per character excluding any parity bit). To use international
character sets you need 8 bits. But it's not of much use unless your terminal has the fonts for them. See
Character-Sets If you are only going to use ASCII characters, then select 7-bits since it's faster to transmit 7
bits than 8. Some very old terminals only support 7-bit characters.
If you use software (Xon/Xoff) flow control and have users who don't know about it, then they may
accidentally send an Xoff to the host and lock up their terminal. While it's locked, they may type frantically in
a vain attempt to unlock it. Then when Xon is finally sent to restore communication, all that was typed in
haste gets executed, perhaps with unexpected results. They can't do this with hardware flow control. See Flow
Control for an explanation of flow control.
Port select
Since most terminals have two or more connectors on the back, it is usually possible to assign one of these
connecters to connect to the host computer and assign another connector to be the printer port. The connector
may have a name next to it (inspect it) and this name (such as Aux, Serial 2, or Modem) may be assigned to
either be the main host connection or the printer connection (or the like).
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.
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
Port select 51
Text-Terminal-HOWTO
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.
• 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).
• 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} ?
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 ??).
Columns/Lines
Usually 80 columns and 24 or 25 lines. This means that there may be up to 80 characters in a row (line) on the
screen. Many terminals have a 132 column option but unless you have a large screen, the tiny characters may
be hard to read. {{Set 132 column mode}}. If you set 25 lines, make sure that this is in the terminfo. You
should also put "export LINES=25" into /etc/profile and also use: "stty -F /dev/ttySx rows 25". If you don't it
might result in a scrolling problem (see Terminal doesn't scroll
Cursor
The cursor may be set to appear as a rectangle (= block) {Blk}. Other options are underline {Line} or
blinking. I prefer non-blinking {Steady} block since it's big enough to find quickly but there is no distractive
blinking. If you set it invisible (an option on some terminals) it will disappear but new letters will appear on
the screen as you type at the invisible cursor.
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.
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.
Columns/Lines 54
Text-Terminal-HOWTO
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.
Auto Answerback
If set, sends the answerback message to the host at power-on without the host asking for it. Do any "getty"
processes look for this ??
Answerback Concealed
If set, will never let anyone see the answerback message (except of course the host computer). If it needs to be
changed, deselect "answerback concealed" and the formerly concealed message will be destroyed so you then
may enter a new message (but you don't get to see the old one).
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.
• 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 ??
PC Scan Codes
Many terminals can emulate a PC keyboard by sending PC scancodes (see Keyboard-and-Console-HOWTO)
instead of ASCII codes. This is mostly used with special Multiuser DOS OSs. It won't work with ordinary MS
DOS. See Non-Linux OSs However, hardly any Linux programs that run via the serial port can accept
scancodes. If this is the latest version of this HOWTO, let me know if any programs do this. I think Foxpro
can do it. You need to define smsc and rmsc in the terminfo, and perhaps pctrm.
When using scancodes it's best to use hardware flow control since normal software flow control conflicts with
some of the codes (??). If you do use software flow control, you must use the XPC type of flow control. It
uses 0x65 and 0x67 for on and off characters. It must be set this way both in the terminal and by stty for the
PC.
Alternate Characters
Some keys may have alternative letters on them. When keys is set to "Typewriter" they send what they would
normally send on a typewriter. When keys is set to something else the alternative characters are sent.
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.
For an 80 col. screen, most terminals only wrap if the 81st character from the host is a graphic (printable)
character. This allows for the case where 81st character from the host might be "return" or a "newline"
(non-graphic characters) which means that the application is handing the wrapping OK and intervention by
the terminal is not needed.
Scrolling
Scrolling {Scrl} is where all the lines on the screen move up or down. Its also called "panning" which
includes movement sideways. In ordinary scrolling lines roll off the bottom or top of the screen and disappear,
and new lines from the host appear at the opposite edge (top or bottom). There are 3 types of this: smooth,
jump, or burst. Burst is not really scrolling since its an instant replacement of an old screenfull by a new one
(although some lines on the new screen may be from the old screen). Jump is where new lines jump into view
one at a time. Smooth {Smth} is where the text moves at a steady speed upward or downward. If the smooth
scroll rate is slow enough, one may read the newly visible lines when they are still scrolling (in motion).
If (auto)scrolling {Autoscrl} is disabled, then new text from the host must go somewhere so it is put at the top
of the display. If the old text is not erased, the new text merges (nonsensically) into the old. If the old text is
erased, then the new text is out of context. So keep (auto)scrolling enabled.
New Page?
See Pages and Pages for explanations of pages. When the current page is full (the last line is finished) should
the page scroll, or should a new page be created (leaving the previous page stored in the terminal's display
memory). If {Autopage} is set, then a new page is created. Since you are probably not using pages, you
should probably set this to off.
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)
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
Scrolling 59
Text-Terminal-HOWTO
is sent.
Block/Page terminator
What is the termination symbol to be appended to a block of data? {Blk End} or at the end of a page {Send
Term}ination.
14.16 Locks
There are various types of Locks. One is the Locked keyboard due to flow control. See Keyboard Lock
Another lock {Feature Lock} is that which prohibits the host computer from changing the terminal set-up by
sending certain escape sequences to the terminal. Placing such a lock may result in unexpected behavior as
application programs send escape sequences to the terminals that are ignored. Not all set-up parameters lock.
Unless you have a good reason to do so, you should not enable such locking.
A Function Key lock will prohibit the computer from redefining what a programmable function key sends.
You may want to use this if you have something important programmed into the function keys.
14.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.
Region to Send 60
Text-Terminal-HOWTO
Getty GETs a TTY (a terminal) going. Each terminal needs its own getty command. There is also at least one
getty command for the console in every /etc/inittab file. Find this and put the getty commands for the real
terminals next to it. This file may contain sample getty lines for text terminals that are commented out so that
all you need to do is to uncomment them (remove the leading #) and change a few arguments.
The arguments which are permitted depend on which getty you use:
Two gettys best for directly connected terminals are:
1. agetty (sometimes just called getty): Easy to set up with no config required. See agetty
2. getty (part of getty_ps) More advanced with config file.
Two gettys best for dial-in modems (avoid for directly connected terminals) are:
1. mgetty: the best one for modems; works for terminals too but inferior
2. uugetty: for modems only; part of the getty_ps package
Simple gettys to use if you don't use a real text-terminal. Most Linux users use one of these at their monitor:
1. mingetty
2. fbgetty
3. fgetty
4. rungetty
Your Linux distribution may come with either getty_ps or agetty for text-terminals. Some distributions supply
neither. Unfortunately, they often just call it "getty". If you need to determine which one you have look at the
man page for "getty". As of 2007 agetty (in the "util-linux package) seems to be more widely used then
getty_ps which was at: getty_ps
As a last resort to try to determine which getty you have, you might check out its executable code (usually in
/sbin). getty_ps has /etc/gettydefs embedded in this code. To search for it, go to /sbin and type:
strings getty | grep getty
If getty is actually agetty the above will result in nothing. However if you have agetty typing:
getty -h
should show the agetty options [-hiLmw].
The source codes for various gettys may be downloaded from Getty Software.
If you are not using modem control lines (for example if you only use the minimum number of 3 conductors:
transmit, receive, and common signal ground) you should let getty know this by using a "local" flag. The
format of this depends on which getty you use.
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
Introduction to Getty 61
Text-Terminal-HOWTO
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).
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.
S1 is from ttyS1. 23 means that getty is run upon entering run levels 2 or 3. respawn means that if getty (or a
process that replaced it such as bash) is killed, getty will automatically start up (respawn) again. /sbin/getty is
the getty command. The -L means Local (ignore modem control signals). -h (not shown in the example)
enables hardware flow control (same as stty crtscts). 19200 is the baud rate. ttyS1 means /dev/ttyS1 (COM2 in
MS-DOS). vt102 is the type of terminal and this getty will set the environment variable TERM to this value.
There are no configuration files. Type "init q" on the command line after editing getty and you should see a
login prompt.
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.
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:
When you are done editing /etc/gettydefs, you can verify that the syntax is correct by doing:
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):
Restart init:
linux# init q
At this point, you should see a login prompt on your terminal. You may have to hit return to get the terminal's
attention.
mgetty
The "m" stands for modem. This program is primarily for modems and as of mid 2000 it will require
recompiling to use it for text-terminals (unless you use hardware flow control --and that usually requires a
hand-made cable). For the documentation for directly connected terminals see the "Direct" section of the
manual: mgetty.texi.
Look at the last lines of /etc/mgetty/mgetty.config for an example of configuring it for a terminal.
Unless you say "toggle-dtr no" it will think that you have a modem and drop (negate) the DTR pin at the PC
in a vain attempt to reset the non-existent modem. In contrast to other gettys, mgetty will not attach itself to a
terminal until someone hits any key of that terminal so you'll see a ? for the terminal in top or ps until this
happens. The logs in /var/log/mgetty/ may show a few warning messages which are only applicable to
modems which you may ignore.
s1:23:respawn:/sbin/mgetty -r ttyS1
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.
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 old 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.
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.
mgetty 65
Text-Terminal-HOWTO
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 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 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 Kernel 2.4+) looks for a few "standard" legacy serial ports, for PnP ports on the
ISA bus, and for all supported port hardware on the PCI bus. If it finds your ports correctly, then there's no
need to use setserial. 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.
Introduction 66
Text-Terminal-HOWTO
For legacy ports, if you know the I/O address but don't know the IRQ you may command setserial to attempt
to determine the IRQ.
You can see a list of possible commands by just typing setserial with no arguments. This fails to show
you the one-letter options such as -v for verbose which you should normally use when troubleshooting. Note
that setserial calls an IO address a "port". If you type:
setserial -g /dev/ttyS*
You'll see some info about how the device driver is configured for your ports. In many cases you'll see some
ports displayed with what appears at first glance to be erroneous IRQs and addresses. But if you also see:
"UART: unknown" just ignore the entire line since no serial port exists at that address.
If you add -a to the option -g you will see more info although few people need to deal with (or understand)
this additional info since the default settings you see usually work fine. In normal cases the hardware is set up
the same way as "setserial" reports. But if you are having problems there is a good chance that setserial
has it wrong. In fact, you can run "setserial" and assign a purely fictitious I/O port address, any IRQ, and
whatever uart type you would like to have. Then the next time you type "setserial ..." it will display these
bogus values you've supplied to the driver. They will also be officially registered with the kernel as displayed
(at the top of the screen) by the "scanport" command (Debian). Of course the serial port driver will not work
correctly (if at all) if you attempt to use such a port. Thus, when giving parameters to setserial, "anything
goes". Well almost. If you assign one port a base address that is already assigned (such as 3e8) it may not
accept it. But if you use 3e9 it will accept it. Unfortunately 3e9 is actually assigned since it is within the range
starting at base address 3e8. Thus the moral of the story is to make sure your data is correct before assigning
resources with setserial.
Configuration file
While assignments made by setserial are lost when the PC is powered off, a configuration file may restore
them when the PC is started up again. In newer versions, what you change by setserial might get automatically
saved to a configuration file. When setserial runs it uses the info from the configuration file.
Where this configuration file resides depends on your distribution. Look at the start-up scripts somewhere in
the /etc/ tree (such as /etc/init.d/ or /etc/rc.d/) and read the startup script for "serial" or "setserial" or the like. It
should show where the configuration file(s) reside. In Debian there are 4 options for use of this configuration
file:
1. Don't use this file at all. At each boot, the serial driver alone detects the ports and setserial doesn't
ever run. ("kernel" option)
2. Save what setserial reports when the system is first shutdown and put it in the configuration file.
After that, don't ever make any changes to the configuration file, even if someone has made changes
by running the setserial command on the command line and then shuts down the system.
("autosave-once" option)
3. At every shutdown, save whatever setserial detects to the configuration file. ("autosave" option)
4. Manually edit the configuration file to set the configuration. Don't ever do any automatic saves to it.
("manual" option)
In olden days (perhaps before 2000), there wasn't any configuration file and the configuration was manually
set (hard coded) inside the shell script that ran setserial. See Edit a script (prior to version 2.15).
Probing
You probe for a port with setserial only when you suspect that it has been enabled (by PnP methods, the
BIOS, jumpers, etc.). Otherwise setserial probing will never find it since its address doesn't exist. A
problem is where the software looks for a port at specified I/O addresses. Prior to probing with "setserial", one
may run the "scanport" (Debian) command to check all possible ports in one scan. It makes crude guesses as
to what is on some ports but doesn't determine the IRQ. It's a fast first start. It may hang your PC but so far it's
worked fine for me. Note that non-Debian distributions don't seem to supply "scanport". Is there another scan
program?
With appropriate options, setserial can probe (at a given I/O address) for a serial port but you must guess
the I/O address. If you ask it to probe for /dev/ttyS2 for example, it will only probe at the address it thinks
ttyS2 is at (2F8). If you tell setserial that ttyS2 is at a different address, then it will probe at that address, etc.
See Probing
The purpose of such probing is to see if there is a uart there, and if so, what its IRQ is. Use setserial
mainly as a last resort as there are faster ways to attempt it such as wvdialconf to detect modems, looking at
very early boot-time messages, or using pnpdump --dumpregs, or lspci -vv. But if you want to detect
hardware with setserial use for example :
setserial /dev/ttyS2 -v autoconfig
If the resulting message shows a uart type such as 16550A, then you're OK. If instead it shows "unknown"
for the uart type, then there is supposedly no serial port at all at that I/O address. Some cheap serial ports don't
identify themselves correctly so if you see "unknown" you still might have a serial port there.
Besides auto-probing for a uart type, setserial can auto-probe for IRQ's but this doesn't always work right
either. In one case it first gave the wrong irq but when the command was repeated it found the correct irq. In
versions of setserial >= 2.15, the results of your last probe test could be automatically saved and put into a
distribution-specific configuration file such as /etc/serial.conf or /etc/sysconfig/serial or
/var/lib/setserial/autoserial.conf for Debian. This will be used next time you start Linux.
It may be that two serial ports both have the same IO address set in the hardware. Of course this is not
normally permitted for the ISA bus but it sometimes happens anyway. Probing detects one serial port when
actually there are two. However if they have different IRQs, then the probe for IRQs may show IRQ = 0. For
me, it only did this if I first used setserial to give the IRQ a fictitious value.
Configuration file 68
Text-Terminal-HOWTO
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..
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
Boot-time Configuration 69
Text-Terminal-HOWTO
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..
or, if you wanted setserial to automatically determine the uart and the IRQ for ttyS3 you would have used
something like this:
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.
Furthermore you may not even need to edit serial.conf (or the like) because using the "setserial" command on
the command line may automatically cause serial.conf to be edited appropriately. This was done so that you
may not need to edit any file in order to set up (or change) what setserial does each time that Linux is booted.
What often happens is this: When you shut down your PC the script that ran "setserial" at boot-time is run
again, but this time it only does what the part for the "stop" case says to do: It uses "setserial" to find out what
the current state of "setserial" is, and it puts that info into the serial configuration file such as serial.conf.
Thus when you run "setserial" to change the serial.conf file, it doesn't get changed immediately but only when
and if you shut down normally.
Now you can perhaps guess what problems might occur. Suppose you don't shut down normally (someone
turns the power off, etc.) and the changes don't get saved. Suppose you experiment with "setserial" and forget
to run it a final time to restore the original state (or make a mistake in restoring the original state). Then your
"experimental" settings are saved. And worst of all, unless you know which options were set in the
configuration file, you don't know what will happen. One option in Debian (and likely other distributions) is
known as "AUTOSAVE-ONCE" which saves changes only for the first time you make them with the setserial
command.
If the option "###AUTOSAVE###" is set and you manually edit serial.conf, then your editing is destroyed
when you shut down because it gets changed back to the state of setserial at shutdown. There is a way to
disable the changing of serial.conf at shutdown and that is to remove "###AUTOSAVE###" or the like from
first line of serial.conf. In the Debian distribution, the removal of "###AUTOSAVE###" from the first line
was once automatically done after the first time you shutdown just after installation. To retain this effect the
"AUTOSAVE-ONCE" option was created which only does a save when time the system is shut down for the
first time (just after you install or update the setserial program).
The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now
/etc/init.d/setserial (Debian) or /etc/init.d/serial (Redhat), or etc., but it should not normally be edited. For
2.15, Redhat 6.0 just had a file /usr/doc/setserial-2.15/rc.serial which you have to move to /etc/init.d/ if you
want setserial to run at boot-time.
To disable a port, use setserial to set it to "uart none". This will not be saved. The format of
/etc/serial.conf appears to be just like that of the parameters placed after "setserial" on the command line with
one line for each port. If you don't use autosave, you may edit /etc/serial.conf manually.
In order to force the current settings set by setserial to be saved to the configuration file (serial.conf) without
shutting down, do what normally happens when you shutdown: Run the shell-script
/etc/init.d/{set}serial stop. The "stop" command will save the current configuration but the
serial ports still keep working OK.
In some cases you may wind up with both the old and new configuration methods installed but hopefully only
one of them runs at boot-time. Debian labeled obsolete files with "...pre-2.15".
IRQs
By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and ttyS3 share IRQ 3. But while sharing serial
interrupts (using them in running programs) is OK for the PCI bus, it's not permitted for the ISA bus unless
you: 1. have kernel 2.2 or better, and 2. you've compiled in support for this, and 3. your serial hardware
supports it. See Serial-HOWTO: Interrupt sharing and Kernels 2.2+.
If you only have two serial ports, ttyS0 and ttyS1, you're still OK since IRQ sharing conflicts don't exist for
non-existent devices.
If you add a legacy internal modem (without plug-and-play) and retain ttyS0 and ttyS1, then you should
attempt to find an unused IRQ and set it in your serial port (or modem card) and then use setserial to assign it
to your device driver. If IRQ 5 is not being used for a sound card, this could be used for a modem.
Laptops: PCMCIA
If you have a Laptop, read PCMCIA-HOWTO for info on the serial configuration. For serial ports on the
motherboard, setserial is used just like it is for a desktop. But for PCMCIA cards (such as a modem) it's a
different story. The configuring of the PCMCIA system should automatically run setserial so you shouldn't
need to run it. If you do run it (by a script file or by /etc/serial.conf) it might be different and cause trouble.
The autosave feature for serial.conf shouldn't save anything for PCMCIA cards (but Debian did until 2.15-7).
Of course, it's always OK to use setserial to find out how the driver is configured for PCMCIA cards.
15.4 Stty
Introduction
stty does much of the configuration of the serial port but since application programs (and the getty program)
often handle this, you may not need to use it much. It's handy if you're having problems or want to see how
the port is set up. Try typing ``stty -a'' at your terminal/console to see how it's now set. Also try typing it
without the -a (all) for a short listing which shows how it's set different than normal. Don't try to learn all the
setting unless you want to become a serial historian since many of the settings are only for slow antique dumb
terminals of the 1970's. Most of the defaults should work OK.
stty is documented in the man pages with a more detailed account in the info pages. Type "man stty" or
"info stty".
Whereas setserial only deals with actual serial ports, stty is used both for serial ports and for virtual
terminals such as the standard Linux text interface at a PC monitor. For the PC monitor, many of the stty
settings are meaningless. Changing the baud rate, etc. doesn't appear to actually do anything.
Here are some of the items stty configures: speed (bits/sec), parity, bits/byte, # of stop bits, strip 8th bit?,
modem control signals, flow control, break signal, end-of-line markers, change case, padding, beep if buffer
overrun?, echo what you type to the screen, allow background tasks to write to terminal?, define special
(control) characters (such as what key to press for interrupt). See the stty man or info page for more details.
Also see the man page: termios which covers the same options set by stty but (as of mid 1999) covers
features which the stty man page fails to mention. For use of some special characters see Special (Control)
Characters
With some implementations of getty (getty_ps package), the commands that one would normally give to stty
are typed into a getty configuration file: /etc/gettydefs. Even without this configuration file, the getty
command line may be sufficient to set things up so that you don't need stty.
One may write C programs which change the stty configuration, etc. Looking at some of the documentation
for this may help one better understand the use of the stty command (and its many possible arguments).
Serial-Programming-HOWTO 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.
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".
Introduction 72
Text-Terminal-HOWTO
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.
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. Thus if one uses stty to change settings for the raw mode, such
settings will be permanently lost as soon as one hits the <return> key at the terminal that has supposedly been
"set".
Now when one types stty to look at the terminal interface, one may either get a view of the cooked mode or
the raw mode. You need to figure out which one you're looking at. It you use stty from a foreign terminal
(other than the terminal you are currently typing at) then you will see the raw mode settings. Any changes
made will only be made to the raw mode and will be lost when someone presses <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.
Your changes are saved and will still be there when the terminal goes back into raw mode (unless of course
it's a setting not allowed in raw mode).
This situation can create problems. For example, suppose you corrupt your terminal interface. To restore it
you go to another terminal and "stty -F dev/ttyS1 sane" (or the like). It will not work! Of course you can try to
type "stty sane ..." at the terminal that is corrupted but you can't see what you typed. All the above not only
applies to dumb terminals but to virtual terminals used on a PC Monitor as well as to the terminal windows in
X. In other words, it applies to almost everyone who uses Linux.
Luckily, when you start up Linux, any file that runs stty at boot-time will likely deal with a terminal (or serial
port with no terminal) that has no shell running on it so there's no problem for this special case.
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.
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.
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.
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).
To find it, try looking at the /etc/termcap... file (if you have it). If not, then either look at the terminfo trees
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.
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.
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 ?
For the Debian Distribution of Linux, several commonly used terminals (including the monitor-console) are in
the ncurses-term package. These are put into /etc/terminfo/. All of the terminals in the database are in the
ncurses-bin package and go into /usr/share/terminfo/.
If the compiled terminfo is in more than one location, everything is usually OK until someone installs new
terminfo files (from a newer distribution, from the net, by editing the old one, etc.). Each new terminfo file
needs replace all the existing older copies of that file (at various locations) unless you abolish redundant
locations. If you don't ensure this gets done, then some application programs could wind up still finding and
using the old (and possibly buggy) terminfo data that sill exists in a "possible" location. Setting the
environment variable TERMINFO to the up-to-date location (as mentioned above) would help avoid this
problem.
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/.
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.
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).
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).
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).
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.
emacs
If software flow control exists, then the ^S command in emacs will freeze the display. The ^Q command will
unfreeze the display. One fix is to map this to another key-press by configuring emacs that way. Some
terminals have meta keys although you may need to setup the terminal to create a meta key.
vi and Cursor-Keys
Vi uses the esc-key as a command to exit insert mode. Unfortunately for most terminals the arrow-keys send
an 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
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.
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.
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:
vi and Cursor-Keys 82
Text-Terminal-HOWTO
# Arrow keys in 8 bit keypad mode: Sends d0-d4. -ap means application.
$if term=wy60-25-ap
set enable-keypad on
"\xd0": backward-char
"\xd1": forward-char
"\xd2": next-history
"\xd3": previous-history
$endif
If the terminal is already in "application key mode" there's no need to "set enable-keypad on". enable-keypad
will send the terminal the escape sequence named smkx in terminfo (which for wyse60 is \E~3 and makes the
arrow keys send D1-D3). Many other application send this without needing to be told to do so.
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.
• 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:
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.
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.
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.
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.
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:
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.
Command-Line Editing 86
Text-Terminal-HOWTO
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".
One direct method of making such changes is to use the setup key (or the like) at the terminal and then use
menus (or the like) to make the changes. To do this you may need to be familiar with the terminal. The other
3 methods send an escape sequence from the computer to the terminal to make the changes. These 3 examples
show different methods of doing this to set reverse video:
1. setterm -reverse
2. tput -rev
3. echo ^[[7m
setterm
This is the easiest command to use. It uses long options (but doesn't use the normal -- before them). It consults
the terminfo database to determine what code to send. You may change the color, brightness, linewrap,
keyboard repeat, cursor appearance, etc.
tput
The "tput" command is similar to "setterm" but instead of using ordinary words as arguments, you must use
the abbreviations used by terminfo. Many of the abbreviations are quite terse and hard to remember.
echo
In the example "echo ^[[7m" to set reverse video, the ^[ is the escape character. To type it type ^V^[ (or ^V
followed by the escape key). To use this "echo" method you must find out what code to use from a terminal
manual or from terminfo or termcap. It's simpler to use setterm or tput if you are typing on the command line.
Since "echo ..." will execute faster (since it doesn't do any lookups) it's good for using in shell scripts which
run at start-up, etc.
Saving changes
When you turn off the terminal the changes you made will be lost (unless you saved them in non-volatile
terminal memory by going into set-up mode and saving it). If you want to use them again without having to
retype them, put the commands in a shell script or make it a shell function. Then run it when you want to
make the changes. One way to make the changes semi-permanent is to put the commands in a file that runs
each time you login or start up the computer.
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.
• 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
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.
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.
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.
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.
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).
#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */
Change 0x0c in the line above (depending on the baud rate you want):
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=".
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
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
One possible problem (which turns out to be no problem at all) is that normally, the type of spy terminal
should be the same as the type of terminal being spied upon. Since the monitor is normally declared as a
terminal of type "linux" (which is close to vt100), you might think that the real terminal should also be (or at
least emulate) a vt100. Not necessarily so! For example, if you have a wyse60 terminal you simply falsely
declare that you have a wyse terminal on tty1 (tell the getty program for tty1 that it's a wyse60).
Here's why you can get away with this. Go back the scenario where you have both the monitor and the
wyse60 terminal in front of you, both displaying the same thing (or trying to). Ttysnoop will be sending the
wyse60 the same bytes as are going to the monitor. If you've falsely claimed that the monitor is a wyse60,
then you'll have wyse60 escape sequences going to both the monitor and the wyse60 terminal (via ttysnoops).
The display on the wyse60 is fine but the display on the monitor is corrupted since it's getting wyse60 escape
sequences. Since you will not use the monitor (and are about to disconnect it) this corruption is never a
problem (you simply don't see it).
Example configuration
This is not the ideal setup since ttysnoop runs so late that the login prompt doesn't appear. This example is for
a wyse60 terminal on ttyS2 and the missing monitor/PC-keyboard on tty1. It uses the agetty program for getty
as supplied by the Debian distribution. Your getty may require a different format.
In /etc/inittab:
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:
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.
How it works 93
Text-Terminal-HOWTO
Here is a list of possible problems:
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.
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.
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
19. Trouble-Shooting 94
Text-Terminal-HOWTO
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.
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.
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.
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.
Another approach is to determine why CD is not being asserted. In many cases the cable to the terminal
simply doesn't have a wire for the CD pin so you must use the "local" option. If there is a wire for the CD pin
then there may not be any signal on it until the terminal is powered on. Note that the CD pin signal is
sometimes supplied by the DTR pin of the terminal (or the PC) by using jumper wires inside the connector.
No 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.5 All Keys Work Erratically; Must Hit a Key a Few Times 96
Text-Terminal-HOWTO
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).
You should also (at the console) try "stty < /dev/ttyS1" (if you use ttyS1) to see that it's set up correctly. It will
often be in raw mode (and this is probably OK) with -icanon and -echo etc. If the terminal incorrectly set at
half-duplex (HDX), then one set of the characters you see when you type are coming from the terminal itself.
If the characters are doubled, then the echos from the computer are OK and you may switch to full-duplex to
fix this. But if half-duplex is set and you only see what looks like normal "echos", then they are not coming
from the computer as they should be.
If you get a message saying something like "login failed" then if there is no error in typing or in the password,
there may be some restrictions on logins which will not allow you to log in. Unfortunately, this message, may
not tell you why it failed. See Login Restrictions
Key shorted 97
Text-Terminal-HOWTO
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.
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.
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).
Measure voltages
If you have a voltmeter handy check for a negative voltage (-4v to -15v) at pin 3 (receive data) at the terminal
side of the file-transfer cable. The positive lead of the meter should be connected to a good ground (the metal
connectors on the ends of cables are often not grounded). If there is no such negative voltage then check for it
If the serial port is alive, you may want to send a file to it (with modem controls disabled) and watch the
signal on a voltmeter (or other electronic gadget). To check for a transmitted signal with a voltmeter, check
for a steady negative voltage when the line is idle. Then start sending a file (or start getty). On an analog
meter you should see the needle dropping to almost 0 and fluttering about 0 as it measures short-run averages
of the bit stream. On a digital meter you will not see the fluctuations as well but you can switch to the AC
scale to see the AC voltage created by the flow of bits. If your meter fails to block out DC on the AC scale
(the default of most analog meters), then you could get a false high AC reading when looking at the idle DC
of -12 V on the AC scale. Without a meter, you could connect a known good device (such as another terminal
or an external modem) to the serial port and see if it works OK.
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.
What you see are escape sequences (or fragments of them) that were sent to your terminal in order to control
it, but your terminal didn't recognize them and passed them on to the screen. It's likely that the program you're
using erroneously thinks you are using another type of terminal. Thus it sends escape sequences that your
terminal doesn't understand. This can sometimes do strange things to your display. Check that the TERM
environment variable is set correctly (type: echo $TERM).
Telnet
The problem of getting TERM right can be a bit more complex if you use telnet. Telnet doesn't emulate a
terminal but passes the value of your TERM variable to the remote computer. If the remote computer doesn't
support your type of terminal, or changes the value of TERM to a wrong value (on the remote) then there's
trouble. Telnet should initially set the value of TERM correctly on the remote. But changes to the value of
TERM (on the remote) could be caused by an incorrect shell configuration file there. The first thing to do is to
Measure voltages 99
Text-Terminal-HOWTO
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).
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.
Telnet 100
Text-Terminal-HOWTO
You may already have the above programs. If not, go to Serial Software. When using these, bear in mind that
what you see is the state of the lines at the host computer. The situation at the terminal will be different since
some wires are often missing from cables while other wires cross over. As of June 1998, I know of no
diagnostic program in Linux for the serial port.
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.
Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called "RS-232 Line Tester") Cat.
#276-1401. It checks TD, RD, CD, RTS, CTS, DTR, and DSR. A green light means on (+12 v) while red
means off (-12 v). They also sell a "RS-232 Serial Jumper Box" Cat. #276-1403. This permits connecting the
pins anyway you choose. Both these items are under the heading of "Peripheral hookup helpers".
Unfortunately, they are not listed in the index to the printed catalog. They are on the same page as the D type
connecters so look in the index under "Connectors, Computer, D-Sub". A store chain named "Active
Components" may have them.
Measuring voltages
Any voltmeter or multimeter, even the cheapest that sells for about $10, should work fine. Trying to use other
methods for checking voltage is tricky. Don't use a LED unless it has a series resistor to reduce the voltage
across the LED. A 470 ohm resistor is used for a 20 ma LED (but not all LED's are 20 ma). The LED will
only light for a certain polarity so you may test for + or - voltages. Does anyone make such a gadget for
automotive circuit testing?? Logic probes may be damaged if you try to use them since the TTL voltages for
which they are designed are only 5 volts. Trying to use a 12 V incandescent light bulb is not a good idea. It
won't show polarity and due to limited output current of the UART it probably will not even light up.
To measure voltage on a female connector you may plug in a bent paper clip into the desired opening. The
paper clip's diameter should be no larger than the pins so that it doesn't damage the contact. Clip an alligator
clip (or the like) to the paper clip to connect up. Take care not to touch two pins at the same time with any
metal object.
Taste voltage
As a last resort, if you have no test equipment and are willing to risk getting shocked (or even electrocuted)
you can always taste the voltage. Before touching one of the test leads with your tongue, test them to make
sure that there is no high voltage on them. Touch both leads (at the same time) to one hand to see if they shock
you. Then if no shock, wet the skin contact points by licking and repeat. If this test gives you a shock, you
certainly don't want to use your tongue.
For the test for 12 V, Lick a finger and hold one test lead in it. Put the other test lead on your tongue. If the
lead on your tongue is positive, there will be a noticeable taste. You might try this with flashlight batteries
first so you will know what taste to expect.
Websites
The FAQ http://www.repairfaq.org for the newsgroup: sci.electronics.repair is long and comprehensive,
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.
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:
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).
Websites 103
Text-Terminal-HOWTO
20.4 Diagnose
Terminal Made a Noise or Smoked
If the terminal made some noise just before it failed (or when you turn it on after it failed) that noise is a clue
to what is wrong. If you hear a noise or see/smell smoke, immediately turn the terminal off to prevent further
damage. A pop noise may be a capacitor exploding or a fuse blowing. A buzzing noise is likely due to arcing.
The problem may be in the high voltage power supply of several thousand volts.
Remove the cover. Look for discoloration and bulging/cracked capacitors. If the bad spot is not evident, turn it
on again for a short time and look for smoking/arcing. For arcing, a dimly lit room will help find it. The high
voltage cable (runs between the flyback transformer and the side of the picture tube) may have broken
insulation that arcs to ground. Fix it with high-voltage insulating dope, or special electrical tape designed say
for 10,000 volts.
The flyback transformer (high voltage) may make only a faint clicking or sparking noise if it fails. You may
not hear it until you turn the terminal off for a while and then turn it back on again. To track down the noise
you may use a piece of small rubber tubing (such as used in automobiles) as a stethoscope to listen to it. But
while you are listening for the noise, the terminal is suffering more damage so try find it fast (but not so fast
as to risk getting shocked).
A shorted power supply may cause a fuse to blow. Replacing a blown fuse may not solve the problem as the
same short may blow the fuse again. Inspect for any darkened spots due to high heat and test those
components. Shorted power transistors may cause the fuse to blow. They may be tested with a transistor
checker or even with an ohm-meter. Use the low ohm scale on an ohm-meter so that the voltage applied by
the meter is low. This will reduce the possible damage to good components caused by this test voltage.
If the terminal has been exposed to dampness such as being stored in a damp place or near a kitchen with
steam from cooking, a fix may be to dry out the unit. Heating a "failed" flyback transformer with a blow dryer
for several minutes may restore it.
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.
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.
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.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
If the terminal display takes several minutes of warmup before it's OK then it's likely that you have one or
more bad electrolytic capacitors. One trick to find the bad one is to parallel each suspected bad one with a
good one (of at least the same voltage rating and capacitance of roughly the same order of magnitude). If the
display improves a lot when you do this, then you've likely found the bad capacitor. Be careful not to get
shocked when doing this. The actual voltage with respect to ground may be much higher than the voltage
rating of the capacitor.
20.8 Keyboards
Interchangeability
The keyboards for terminals are not the same as keyboards for PC's. The difference is not only in the key
layout but in the codes generated when a key is pressed. Also, keyboards for various brands and models of
terminals are not always interchangeable with each other. Sometimes one get an "incompatible" keyboard to
partially work on a terminal: All the ASCII keys will work OK, but special keys such as set-up and break will
not work correctly.
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.
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.
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.
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
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.
Terminfo
• Terminfo Compiler (tic) terminfo compiler & translator
• toe: shows list of terminals for which you have terminfo files
• infocmp compares or displays terminfo entries
Other
• gitkeys: shows what bytes each key sends to the host.
• tty: shows what tty port you are connected to.
• reset -q: shows the value of TERM, the terminfo entry name
• reset: sets TERM interactively and initializes
• Handbook of Interactive Computer Terminals by Duane E. Sharp; Reston Publishing Co. 1977.
(mostly obsolete)
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.
• 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.
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.
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.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.
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.
The serial port is more than just a physical connector on the back of a computer or terminal. It includes the
associated electronics which must produce signals conforming to the EIA-232 specification. The standard
connector has 25 pins, most of which are unused. An alternative connector has only 9 pins. One pin is used to
send out data bytes and another to receive data bytes. Another pin is a common signal ground. The other
"useful" pins are used mainly for signalling purposes with a steady negative voltage meaning "off" and a
steady positive voltage meaning "on".
The UART (Universal Asynchronous Receiver-Transmitter) chip does most of the work. Today, the
functionality of this chip is usually built into another chip.
23.2 Voltages
Voltage for a bit
At the EIA-232 serial port, voltages are bipolar (positive or negative with respect to ground) and should be
about 12 volts in magnitude (some are 5 or 10 volts). For the transmit and receive pins +12 volts is a 0-bit
(sometimes called "space") and -12 volts is a 1-bit (sometimes called "mark"). This is known as inverted logic
since normally a 0-bit is both false and negative while a one is normally both true and positive. Although the
receive and transmit pins are inverted logic, other pins (modem control lines) are normal logic with a positive
voltage being true (or "on" or "asserted") and a negative voltage being false (or "off" or "negated"). Zero
voltage has no meaning (except it usually means that the PC is powered off).
A range of voltages is allowed. The specs say the magnitude of a transmitted signal should be between 5 and
15 volts but must never exceed 25 V. Any voltage received under 3 V is undefined (but some terminals will
accept a lower voltage as valid). One sometimes sees erroneous claims that the voltage is commonly 5 volts
(or even 3 volts) but it's usually 11-12 volts. If you are using a EIA-422 port on a Mac computer as an
EIA-232 (requires a special cable) or EIA-423 then the voltage will actually be only 5 V. The discussion here
assumes 12 V. There is much confusion about voltages on the Internet.
Note that normal computer logic normally is just a few volts (5 volts was once the standard) so that if you try
to use test equipment designed for testing 3-5 volt computer logic (TTL) on the 12 volts of a serial port, it
may damage the test equipment.
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).
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.
It is somewhat tragic that the RS-232 standard from 1969 did not use twisted pair technology which could
operate about a hundred times faster. Twisted pairs have been used in telephone cables since the late 1800's.
In 1888 (over 110 years ago) the "Cable Conference" reported its support of twisted-pair (for telephone
systems) and pointed out its advantages. But over 80 years after this approval by the "Cable Conference",
RS-232 failed to utilize it. Since RS-232 was originally designed for connecting a terminal to a low speed
modem located nearby, the need for high speed and longer distance transmission was apparently not
recognized.
Successors to EIA-232
See the Serial-HOWTO section "Other Serial Devices" for a longer discussion about non-EIA-232 ports. A
number of EIA standards have been established for higher speeds and longer distances using twisted-pair
(balanced) technology. Balanced transmission can sometimes be a hundred times faster than unbalanced
EIA-232. For a given speed, the distance (maximum cable length) may be many times longer with twisted
pair. Few terminals seem to support them. While many terminals also support EIA-423 is is almost like
EIA-232 but is only 5 volts and somewhat higher speeds (without using twisted pair). Twisted pair includes
EIA-422, EIA-530-A, HSSI (High Speed Serial Interface), USB (Universal Serial Bus), and of course
ethernet.
Line Drivers
For a text terminal, the EIA-232 speeds are fast enough but the usable cable length is often too short.
Balanced technology could fix this. The common method of obtaining balanced communication with a text
terminal is to install 2@ line drivers in the serial line to convert unbalanced to balanced (and conversely).
They are a specialty item and are expensive if purchased new.
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.
In theory, synchronous means that bytes are sent out at a constant rate one after another in step with a clock
signal tick. There is often a separate wire or channel for sending the clock signal. Asynchronous bytes may be
sent out erratically with various time intervals between bytes (like someone typing characters at a keyboard).
There are borderline situations that need to be classified as either sync or async. The async serial port often
sends out bytes in a steady stream which would make this a synchronous case but since they still have the
start/stop bits (which makes it possible to send them out erratically) its called async. Another case is where
data bytes (without any start-stop bits) are put into packets with possible erratic spacing between one packet
and the next. This is called sync since the bytes within each packet must be transmitted synchronously.
Synchronous Communication
Did you ever wonder what all the unused pins are for on a 25-pin connector for the serial port? Most of them
are for use in synchronous communication which is seldom implemented on PC's. There are pins for sync
timing signals as well as for a sync reverse channel. The EIA-232 spec provides for both sync and async but
PC's use a UART (Universal Asynchronous Receiver/Transmitter) chip such as a 16450, 16550A, or 16650
and can't deal with sync. For sync one needs a USART chip or the equivalent where the "S" stands for
Synchronous. Since sync is a niche market, a sync serial port is likely to be quite expensive.
Besides the sync part of the EIA-232, there are various other EIA synchronous standards. For EIA-232, 3 pins
of the connector are reserved for clock (or timing) signals. Sometimes it's a modem's task to generate some
timing signals making it impossible to use synchronous communications without a synchronous modem (or
without a device called a "synchronous modem eliminator" which provides the timing signals).
Although few serial ports are sync, synchronous communication does often take place over telephone lines
using modems which use V.42 error correction. This strips off the start/stop bits and puts the date bytes in
packets resulting in synchronous operation over the phone line.
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.
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.
• 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.
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 and 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 sells (in 1997) some parts for models 224, 326, etc. but has nothing for
the 80 and 101.
To save the Set-Up parameters press ^S when in Set-Up mode. cit80: Contrast: knob on rear of terminal,
cit101e: Brightness: use up/down arrow keys in Set-Up mode.
While this IBM system is actually more efficient than what is normally used in Linux, terminals meeting this
IBM standard will not currently work with Linux. However, some IBM terminals are asynchronous ASCII
terminals and should work with Linux on PC's. The numbers 31xx may work with the exception that 317x and
319x are not ASCII terminals. Before getting an IBM terminal, make sure there is a termcap (terminfo) for it.
If their isn't, it likely will not work with Linux. Even if there is a terminfo, it may not work. For example,
there is a termcap for 327x but the 3270 is an EBCDIC synchronous terminal.
The 3270 series includes the 3278 (late 1970's), 3279 with color and graphics, and the 3274 terminal
controller (something like the 3174). They may be used for both BISYNC and SNA. The 3290 has a split
screen (splits into quarters).
The synchronous IBM terminals don't connect directly to the IBM mainframe, but connect to a "terminal
controller" (sometimes called "cluster controller" or "communication controller"). Some of these controllers
can convert a synchronous signal to asynchronous so that in this case a synchronous terminal could indirectly
connect to a Unix-like host computer via its serial port. But there is still a major problem and that is block
transmission. See section Block Mode.
IBM 3153
It's claimed that the Aux port is DCE and uses a straight-thru cable.
24.4 Teletypes
These are antiques and represent the oldest terminals. They are like remotely controlled typewriters but are
large and noisy. Made by the Teletype Corp., the first models were made in the 1920's and predate the
computer by over 30 years. Early models used electro-mechanical relays and rotating distributors instead of
electronics. Their Baudot code was only 5-bits per character as compared to 7-bit ASCII. See the book "Small
Computer Systems Handbook" by Sol Libes, Hayden Books, 1978: pp. 138-141 ("Teletypes").
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
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.
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.
Wyse 50
Reported not to last very long.
Wyse 60
Display adjustments (must remove cover): Brightness VR202, Height VR302, Width VR101 (also affects
height). If you want to use it in Native Personality, then the arrow-key codes will conflict with the codes used
in vi (such as ^L). To fix this set "Application key mode" with ESC ~ 3. This results in the arrow keys sending
0xd1 - 0xd4. Due to a bug in the readline interface of the Bash shell, you need to edit /etc/inputrc so that the
arrow keys will work in Bash. See Bugs in Bash
Wyse 85
Can emulate VT52/VT100/VT200. Press F3 for setup. After moving left/right to go a menu "icon", press
space to select it. Scroll thru setup menus with up/down keys. Press F3 at any time to reenter setup (without
loosing any settings).
Wyse 99-GT
Here is the setup Menus of the Wyse99GT (late 1980's). Note that TERM means "termination" (character) and
not "terminal".
F1 DISP:
HINTS on use of WY-99GT User's Guide: Note that much that is missing from this Guide may be found in
the WY-99GT Programmer's Guide. The VT100 emulation (personality) is known as ANSI and uses ANSI
key codes per p. A-10+ even though the keyboard may be ASCII. A sub-heading on p. A-13 "ASCII
Keyboard" also pertains to VT100 because it has an "ANSI KEY ..." super-heading a few pages previously.
But not all ASCII keyboard headings pertain to VT100 since they may fall under a non-ANSI personality
super-heading which may found be a few pages previously. Appendix H is the "ANSI Command Guide"
except for the VT52 (ANSI) personality which is found in Appendix G.
Wyse 150
When exiting set-up using F12, hitting space changes "no" to "yes" to save the set-up. The sentence to the left
of this no/yes is about "vertical alignment" and has nothing to do with this no/yes for saving the set-up
(confusing menu design).
Wyse 185
Has 10x20 character cells. Can emulate DEC VT320. Uses 45 watts power. Later models were 185e.
END OF Text-Terminal-HOWTO