Text-Terminal-HOWTO David S. Lawyer 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. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 Copyright, Trademarks, Disclaimer, & Credits 1.1.1 Copyright 1.1.2 Disclaimer 1.1.3 Trademarks. 1.1.4 Credits 1.2 Future Plans: You Can Help 1.3 New Versions of this HOWTO 1.4 Related HOWTOs, etc. 1.5 Terminology Used in this Document 1.6 What is a Terminal ? 1.7 What is a Text-Terminal ? 1.7.1 Real text terminals 2. Types of Terminals 2.1 Dumb Terminals 2.2 Text Terminals 2.3 Graphic GUI Capabilities of Text Terminals 2.3.1 Graphics GUI displays 3. Thin Clients Terminals 3.1 Introduction 3.2 MS Window terminals 3.2.1 Network computers (NCs) 3.2.2 Thin clients and NCs under Linux 3.2.3 Hardware hookups 3.2.4 History and the future 3.3 Emulation on a PC 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 ? 6. Overview of How Terminals Work (in Linux) 6.1 Device Names 6.2 Login/Logout 6.3 Half/Full Duplex 6.4 Terminal Memory 6.5 Commands for the Terminal 6.6 Lack of Standardization Solved by Terminfo 6.7 The Interface 6.8 Emulation 6.9 The Console 7. Terminal Special Files such as /dev/tty 7.1 Serial Port Terminals 7.2 Pseudo Terminals 7.3 The Controlling Terminal /dev/tty 7.4 /dev/ttyIN "Terminals" 7.5 The Console: ttyN or vc/N 7.6 Creating a Device with "mknod" 8. Some Details on How Terminals Work 8.1 Terminal Memory Details 8.2 Early Terminals 8.3 Escape Sequences and Control Codes (intro) 8.3.1 Control codes 8.3.2 Escape sequences 8.4 Display Attributes & Magic Cookies 9. Special Features of Some Terminals 9.1 Color 9.2 Multiple Sessions 9.3 Printer/Auxiliary Port 9.4 Pages 9.5 Character-Sets 9.5.1 Graphics (Line Drawing, etc.) 9.5.2 National Replacement Characters (obsolete) 9.6 Fonts 9.7 Keyboards & Special Keys 9.8 Mouse 10. Terminal Emulation (including the Console) 10.1 Intro to Terminal Emulation 10.2 Don't Try to Use TERM Variable for Emulation 10.3 Serial Communication (Dialing) programs 10.3.1 Emulation under X Window 10.3.2 Real terminals may be better 10.4 Testing Terminal Emulation 10.5 The Linux Console 10.6 Emulation Software 10.6.1 Make a Linux PC a serial port terminal 10.6.2 Make a Linux PC an IBM network terminal 10.6.3 Make a non-Linux PC a terminal 11. Flow Control (Handshaking) 11.1 Why Is Flow Control Needed ? 11.2 Padding 11.3 Overrunning a Serial Port 11.4 Stop Sending 11.5 Keyboard Lock 11.6 Resume Sending 11.7 Hardware Flow Control (RTS/CTS etc.) 11.7.1 RTS/CTS, DTR, and DTR/DSR Flow Control 11.7.2 Connecting up DTR or DTR/DSR Flow Control 11.7.3 Old RTS/CTS handshaking is different 11.7.4 Reverse Channel 11.8 Is Hardware Flow Control Done by Hardware ? 11.9 Obsolete ?? ETX/ACK or ENQ/ACK Flow Control 12. Physical Connection 12.1 Introduction 12.2 Multiport I/O Cards (Adapters) 12.3 Direct Serial Cable Connection. 12.3.1 Pin numbering 12.3.2 Null Modem cable pin-out (3, 4, or 5 conductor) 12.3.3 Standard Null Modem cable pin-out (7 conductor) 12.3.4 Overcoming length limitations 12.3.5 Hardware Flow Control cables 12.3.6 Cable tips 12.3.7 A kludge using twisted-pair cable 12.3.8 Cable grounding 12.4 Modem Connection 12.4.1 Dialing out from a terminal 12.4.2 Terminal gets dialed into 12.5 Telnet and ssh 12.6 Terminal Server Connection 12.6.1 What is a terminal server ? 12.6.2 Evolution of the "terminal server" 12.7 Connector and Adapter Types 12.7.1 Sex of connector/adapters 12.7.2 Types of adapters 12.7.3 DB connectors 12.7.4 RJ modular connectors 12.7.4.1 6-conductors: RJ11/14, RJ12, and MMJ 12.7.4.2 8-conductors and 10-conductors 12.8 Making or Modifying a Cable 12.8.1 Buy or make ? 12.8.2 Pin numbers of 9 and 25 pin connectors 12.8.3 Installing DB connectors on cable ends 12.8.4 Installing RJ connectors 13. Set-Up (Configure) in General 13.1 Intro to Set-Up 13.2 Terminal Set-Up (Configure) Overview 13.3 Computer Set-Up (Configure) Overview 13.4 Many Options 13.5 Communication Interface Options 13.5.1 Speed 13.5.2 Parity & should you use it ? 13.5.3 Bits/Character 13.5.4 Which Flow Control (Handshaking) ? 13.5.5 Port select 13.6 Quick Attempt 14. Terminal Set-Up (Configure) Details 14.1 Send Escape Sequences to the Terminal 14.2 Older Terminals Set-Up 14.3 Getting Into Set-Up (Configuration) Mode 14.4 Communication Options 14.5 Saving the Set-up 14.6 Set-Up Options/Parameters 14.7 Emulation {Personality} {{Terminal Modes}} 14.8 Display Options 14.8.1 Character Cell Size {Char Cell} 14.8.2 Columns/Lines 14.8.3 Cursor 14.8.4 Display Attributes (Magic Cookies) 14.8.5 Display Control Characters {Monitor} 14.8.6 Double Width/Height 14.8.7 Reverse Video {Display} (Background Light/Dark) 14.8.8 Status Line 14.8.9 Upon 80/132 Change: Clear or Preserve? 14.9 Page Related Options 14.9.1 Page Size 14.9.2 Coupling (of cursor & display) 14.10 Reporting and Answerback 14.10.1 Answerback Message (String) 14.10.2 Auto Answerback 14.10.3 Answerback Concealed 14.10.4 Terminal ID {ANSI ID} 14.11 Keyboard Options 14.11.1 Keyclick 14.11.2 Caps Lock {Keylock} 14.11.3 Auto Repeat {Repeat} 14.11.4 Margin Bell 14.11.5 Remapping the Keys 14.11.6 Corner Key (for Wyse only) 14.11.7 Numeric Keypad or Arrow Keys Sends 14.11.8 What does shifted-del and shifted-bs send? 14.11.9 PC Scan Codes 14.11.10 Alternate Characters 14.12 Meaning of Received Control Codes 14.12.1 Auto New Line {Newline} 14.12.2 Auto Line Feed {Rcv CR} 14.12.3 Recognize Del (Wyse Only ??) or Null 14.13 Where New Text Goes 14.13.1 Line Wrap 14.13.2 Scrolling 14.13.3 New Page? 14.14 Function Keys 14.15 Block Mode Options 14.15.1 Forms Display 14.15.2 Send Entire Block ? 14.15.3 Region to Send 14.15.4 Block/Page terminator 14.16 Locks 14.17 Screen Saver {Scrn Saver} 14.18 Printer 15. Computer Set-Up (Configure) Details 15.1 Getty (used in /etc/inittab) 15.1.1 Introduction to Getty 15.1.2 Getty exits after login (and can respawn) 15.1.3 If getty run from command line: Programs get stopped 15.1.4 agetty (may be named getty) 15.1.4.1 Agetty's auto-detection of parity problems 15.1.4.2 8-bit data bytes (plus parity) 15.1.5 getty (part of getty_ps) 15.1.6 mgetty 15.2 Stty & Setserial 15.3 Setserial 15.3.1 Setserial problems with linmodems, laptops 15.3.2 Introduction 15.3.3 Serial module unload 15.3.4 Giving the setserial command 15.3.5 Configuration file 15.3.6 Probing 15.3.7 Boot-time Configuration 15.3.8 Edit a script (required prior to version 2.15) 15.3.9 Configuration method using /etc/serial.conf, etc. 15.3.10 IRQs 15.3.11 Laptops: PCMCIA 15.4 Stty 15.4.1 Introduction 15.4.2 Flow control options 15.4.3 Using stty at a "foreign" terminal 15.4.4 Two interfaces at a terminal 15.4.5 Where to put the stty command ? 15.4.6 Obsolete redirection method 15.5 Terminfo & Termcap (brief) 15.6 Setting TERM and TERMINFO 15.6.1 What is the terminfo name of my terminal ? 15.7 Rarely Needed /etc/ttytype File 15.8 Login Restrictions 15.9 Run Command Only If TERM=my_term_type 15.9.1 Example for ls Function 15.10 Character Mapping: mapchan 16. Terminfo and Termcap (detailed) 16.1 Intro to Terminfo 16.2 Terminfo Database 16.2.1 Introduction 16.2.2 Where is the database located ? 16.2.2.1 Compiled database locations 16.2.2.2 Source-code database locations 16.2.3 Terminfo Compiler (tic) 16.2.4 Look at Your Terminfo 16.2.5 Deleting Data Not Needed 16.3 Bugs in Existing Terminfo Files (and Hardware) 16.4 Modifying Terminfo Files 16.5 Init String 16.6 TERM Variable 16.7 Terminfo/Termcap Documents 17. Using the Terminal 17.1 Intro to Using the Terminal 17.2 Starting Up the Terminal 17.3 Terminal (Serial) Device Driver 17.4 Problems with Editors 17.4.1 emacs 17.4.2 vi and Cursor-Keys 17.5 Problem with Slow Scrolling 17.6 Bugs in Bash 17.6.1 A fixed Bash bug 17.7 Color ls Corruption 17.8 Display Freezes (hung terminal) 17.9 Corrupted Terminal Interface 17.9.1 Symptoms and some fixes 17.9.2 Sent terminal binary characters 17.9.3 Reset command was broken but now fixed 17.9.4 Character corruption 17.9.5 Abnormally exited a program 17.10 Special (Control) Characters 17.10.1 Command-Line Editing 17.10.2 Interrupting (& Quit, Suspend, EOF, Flush) 17.10.3 Stop/Start Scrolling 17.10.4 Take next character literally 17.11 Viewing Latin1 Files on a non-Latin1 terminal 17.12 Eliminating Overstriking in Files 17.13 Inspecting the Interface 17.14 Changing the Terminal Settings 17.14.1 setterm 17.14.2 tput 17.14.3 echo 17.14.4 Saving changes 17.15 Multiple Sessions 17.16 Logging Out 17.17 Chatting between Terminals, Spying 17.18 Sharing the Serial Port 17.19 Browsers for Text-Terminals 18. Special Uses for a Terminal 18.1 Make a Serial Terminal the Console 18.1.1 For Kernels 2.2 or higher 18.1.2 For Kernels before 2.2 18.2 Run Linux without a Monitor 18.3 Use a Keyboardless Terminal as the Monitor 18.3.1 How it works 18.3.2 Example configuration 19. Trouble-Shooting 19.1 Terminal Was Working OK 19.2 Terminal Newly Installed 19.3 Is the Terminal OK ? 19.4 Missing Text 19.5 All Keys Work Erratically; Must Hit a Key a Few Times 19.6 ... respawning too fast: disabled for 5 minutes 19.6.1 What's happening 19.6.2 Getty line in /etc/inittab file incorrect 19.6.3 No modem control signal 19.6.4 No such serial device 19.6.5 No serial support 19.6.6 Key shorted 19.7 Fails Just After Login 19.8 Can't Login 19.9 Garbled Login Prompt 19.10 No Login Prompt 19.10.1 Terminal was working OK 19.10.2 More diagnose 19.10.3 Diagnose problem from the console 19.10.4 Measure voltages 19.11 Displays Foreign/Weird Characters/Symbols 19.12 Displays Escape Sequences 19.12.1 Telnet 19.12.2 Terminal set to display escape sequences 19.13 Slow: pauses of several seconds between bursts of characters 19.14 Cursor Jumps 19.15 Terminal doesn't scroll 19.16 Serial Monitoring/Diagnostics 19.17 Local Mode 19.18 Serial Electrical Test Equipment 19.18.1 Breakout Gadgets, etc. 19.18.2 Measuring voltages 19.18.3 Taste voltage 20. Repair & Diagnose 20.1 Repair Books & Websites 20.1.1 Books 20.1.2 Websites 20.2 Safety 20.3 Appearance of Display 20.4 Diagnose 20.4.1 Terminal Made a Noise or Smoked 20.4.2 Terminal Made No Noise 20.5 Detective work 20.6 Error Messages on the Screen 20.6.1 Keyboard Error 20.6.2 Checksum Error in NVR 20.7 Capacitors 20.8 Keyboards 20.8.1 Interchangeability 20.8.2 How They Work 20.8.3 Modern vs Old Keyboards 20.8.4 One Press Types 2 Different Characters 20.8.5 Keyboard doesn't work at all 20.8.6 Typing b displays bb, etc. (doubled) 20.8.7 Row upon row of the same character appears 20.8.7.1 Key sticks in down position (individual switches) 20.8.7.2 Key electrically shorted 20.8.8 Liquid spilled on the keyboard 20.8.9 Cleaning keyboard contacts 20.8.9.1 Keyboards with membranes 20.8.9.2 Keyboards with individual switches 21. Appendix A: General 21.1 List of Linux Terminal Commands 21.1.1 Sending a command to the terminal 21.1.2 Configuring the terminal device driver 21.1.3 Terminfo 21.1.4 Other 21.2 The Internet and Books 21.2.1 Terminal Info on the Internet 21.2.2 Books related to terminals 21.2.3 Entire books on terminals 21.2.4 Books with chapters on terminals 21.3 Non-Linux OSs 22. Appendix B: Escape Sequence Commands Terminology 22.1 Esc Sequence Lists 22.2 8-bit Control Codes 22.3 Printer Esc 22.4 Reports 22.5 Cursor Movements 22.6 Pages (definition) 23. Appendix C: Serial Communications on EIA-232 (RS-232) 23.1 Intro to Serial Communication 23.2 Voltages 23.2.1 Voltage for a bit 23.2.2 Voltage sequence for a byte 23.3 Parity Explained 23.4 Forming a Byte (Framing) 23.5 Limitations of EIA-232 23.5.1 Low Speed & Short Distance 23.5.2 Successors to EIA-232 23.5.3 Line Drivers 23.6 Synchronization & Synchronous 23.6.1 How "Asynchronous" is Synchronized 23.6.2 Defining Asynchronous vs Synchronous 23.6.3 Synchronous Communication 23.7 Block Mode 23.7.1 Introduction to Block Mode 23.7.2 Types of Block Modes, Forms 23.7.3 Efficiency 23.7.4 Problems with block mode 23.8 EIA-232 (RS-232) Books 23.9 Serial Software 24. Appendix D: Notes by Brand/Model 24.1 Adds 24.2 CIT 24.3 IBM Terminals 24.3.1 IBM 3153 24.4 Teletypes 24.5 VT (originally DEC, now Boundless) 24.6 Links 24.7 Qume 24.8 Wyse Terminals 24.8.1 Wyse 50 24.8.2 Wyse 60 24.8.3 Wyse 85 24.8.4 Wyse 99-GT 24.8.5 Wyse 150 24.8.6 Wyse 185 24.8.7 Low Emissions: -ES ______________________________________________________________________ 1. Introduction For a quick attempt to install a terminal see ``Quick Install''. 1.1. Copyright, Trademarks, Disclaimer, & Credits 1.1.1. Copyright Copyright 1998-2007 by David S. Lawyer. Please freely copy and distribute (sell or give away) this document in any format. Send any corrections and comments to the document maintainer. You may create a derivative work and distribute it provided that you: 1. If it's not a translation: Email a copy of your derivative work (in a format LDP accepts) to the author(s) and maintainer (could be the same person). If you don't get a response then email the LDP (Linux Documentation Project): submit@en.tldp.org. 2. License the derivative work in the spirit of this license or use GPL. Include a copyright notice and at least a pointer to the license used. 3. Give due credit to previous authors and major contributors. If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer. 1.1.2. Disclaimer While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally responsible for any errors. 1.1.3. Trademarks. Any brand names (starts with a capital letter such as MS Windows) should be assumed to be a trademark). Such trademarks belong to their respective owners. 1.1.4. Credits Greg Hankin's Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A Terminal Connected To My PC?" was incorporated into v1.00 at various places (with Greg's permission). v1.09 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. 1.2. Future Plans: You Can Help Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. But first, if the date is over a few months old, check to see that you have the latest version. Please send me any info that you think belongs in this document. 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. 1.3. New Versions of this HOWTO New versions of the Text-Terminal-HOWTO should be released every year or so. To get the latest version go to an LDP mirror sites (see: ). To quickly check the date of the latest version look at Text-Terminal-HOWTO.html . The version your are currently reading is: v1.41 February 2008 . 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. "reset" is an alias for "tset" · v1.39 Aug. 2006 Typo your -> you're; Termcap Manual = Termcap Library; Fixed several broken links. Found link to mapchan program. 1.4. Related HOWTOs, etc. Go to the nearest mirror site (per above) to get HOWTOs. · Serial-HOWTO has info on Multiport Serial Cards used for both terminals and banks of modems. It has general technical info on the serial port including troubleshooting it. · Low-Level Terminal Interface 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) 1.5. Terminology Used in this Document Configuration means the same as set-up. While Linux commands take options (using - or -- symbols), options in a broader sense include various other types of choices. Install in the broad sense includes setting up (configuring) software and hardware. A statement that I suspect is true (but may not be) ends with 2 question marks: ?? If you know for sure, let me know. 1.6. What is a Terminal ? A terminal consists of a screen and keyboard that one uses to communicate remotely with a (host) computer. One uses it almost like it was a personal computer but the terminal is remote from its host computer (on the other side of the room or even on the other side of the world). Programs execute on the host computer but the results display on the terminal screen. The terminal's computational ability is relatively low compared to the host computer but often the terminal is just a personal computer (PC) itself which has been programmed to behave like a terminal. It often doesn't allow the user full access to either the pc it runs on nor the host it is connected to. you formerly found this type of terminal at libraries and schools. But some terminals permitted the user to log into the host computer and provide access dependent on the user's status. 1.7. What is a Text-Terminal ? A text-terminal is a terminal which only displays text on the screen without pictures. Today, it's mostly done by PCs which emulate the terminals of olden days. 1.7.1. Real text terminals In the olden days of mainframes, from the mid 1970's to the mid 1980's, most people used real text-terminals to communicate with large computers. These real text-terminals were neither computers nor emulated text-terminals. They consisted only of a screen, keyboard, and only enough memory to store a screenfull or so of text (a few kilobytes). Users typed in programs, ran programs, wrote documents, issued printing commands, etc. A cable connected the terminal to the computer (often indirectly). It was called a terminal since it was located at the terminal end of this cable. Some text-terminals were called "graphic" but the resolution was poor and the speed slow by today's standards due to the high cost of memory and the limited speed of the conventional serial port, etc. Today, real terminals are 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. 2.2. Text Terminals For a text terminal, a 2-way flow of information between the computer and the terminal takes place over the cable that connects them together. This flow is in bytes (such as ASCII) where each byte usually represents a printable character. Bytes typed at the keyboard go to the computer and most bytes from the computer are displayed on the terminal screen. Special control bytes (or sequences of bytes) from the computer tell the terminal where to move the cursor to, what to erase, where to begin and end underlining and/or blinking and/or bold, etc. There are often hundreds of such special commands and most terminals can even change fonts. The communication uses characters (letters) encoded using a code chart for the character set being used. Usually, the first 128 bytes out of 256 possible bytes use ASCII codes. Terminals for Unix-like systems, normally connect to computers via a cable running between the asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer and the terminal. Sometimes the connection is via modem or terminal server, etc. Other names for "text 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''. 2.3. Graphic GUI Capabilities of Text Terminals Many text terminals can display bit-mapped images, but not in color. Unfortunately, the popular image formats used on the Internet are not supported. The protocols for terminal graphics include: Tektronix Vector Graphics, ReGIS (DEC), Sixel (DEC), and NAPLPS (North American Presentation Level Protocol Syntax). Even without bit-mapped images, ordinary text terminals can sort of display images. One may form arrows <--- and draw boxes with |__|, etc. With special graphic character sets that have a lot of special characters for line drawing, much more is possible. But even without a graphic character set, one may produce "ascii graphics" art. The term "graphics terminal" usually means a terminal that can display bit mapped images. However, this term is sometimes applied also to text- only terminals since text is a limited form of graphics. 2.3.1. Graphics GUI displays There are two basic types of graphics displays: raster and vector (rarely used). Raster graphics (bit-mapped) puts dots on the screen by horizontal scan lines drawn by an electron beam (or by activating pixels or dots on a flat screen). Vector graphic displays were intended to be used for monochrome screens that don't have any dots. They use smart electronics to draw lines and curves with an electron beam that can continuously move in any direction (just like a pen or pencil). True vector graphics draws high quality lines without noticeable zig-zags but is both rare and expensive. For more details see . Raster graphics is almost universally used today for both PCs and text terminals. For PCs, images encoded in vector graphic format can't be drawn as continuous lines due to the electronic limitations but they can be translated to raster graphics format for display (with a resulting drop in image quality). 3. Thin Clients Terminals 3.1. Introduction Since "thin clients" are not text terminals, this HOWTO only provides a brief overview of them. There are other HOWTOs that cover them in more detail. See ``Related HOWTOs, etc.''. Thin clients are thin (minimal) client computers that behave something like terminals. Since text terminals (except for very old ones) run an embedded operating system, they are also like a computer. Thin-clients need more computing power. In contrast to text-terminals thin clients all display a modern high-speed GUI. They are dependent on more powerful computers (servers) for their operation. For a true thin client terminal, the computing work and disk storage will all be done on the server. At the other extreme, most of this work and storage is done at the thin client but some things such as administration, still depend on the server. Since such a client is not really "thin" it may more correctly be called a "fat client". Such clients may be created from an ordinary PC by using software or may be a stand-alone piece of hardware. But the stand-alone hardware will often use a conventional PC monitor plus a small box for the computer part of the hardware. Linux seems to favor the use of PCs as a client. Some claim that text-terminals are also thin clients but they are not really since they don't conform to the client-server model. However, connecting a terminal via telnet does invoke the client-server model in the use of telnet as a means of transport of data. But the relation of the text-terminal to it's host is not one of client- server. The text-terminal is just another means of access to the computer just like the monitor and its keyboard is. One could apply this same reasoning to a thin client and say that the client-server relationship is only for the transport of data. Thus a thin client is like a terminal. It has a GUI with a mouse that makes it seem like you are using a computer. You are, but that computer may be far away and have many other people using it at the same time you are. Communication is over a high speed network cable or even over the Internet. Some thin clients can, in addition, emulate a text terminal and have a serial port connector for that purpose. One even has a USB interface. There are various types of thin clients. One type is the "Window Terminal" which runs under MS servers (and software). Another type is the "network computer" which is supposed to be platform neutral. This implies they should work with both MS Windows and Linux but early models may not be easy to use with Linux. For Linux, the X Window protocol is used. See ``Thin clients and NCs under Linux'' 3.2. MS Window terminals These are true terminals since all the computing work is done by a server running Windows. They are also called "Window-based Terminals" (WBT). These terminals (clients) are something like computers since they often run an embedded operating system such as Linux or Microsoft's CE, NT, or XP. It's often stored in flash memory so that it may be updated. Also, ordinary PCs can be used as clients (including, in some cases, Linux PCs) with the appropriate software, Some clients can support X Window (from a Linux server) and some can emulate text-terminals. Many so called "network computers" can also run X Window. This will be discussed in the next section. The server for these clients usually runs MS's Terminal Services (for Windows 2000 servers). Prior to this there was Windows NT Terminal Server Edition (starting mid 1998 with codename "Hydra"). MS uses RDP (Remote Desktop Protocol) which is based on the ITU T.120 protocol. In addition, there is an optional ICA protocol (with added features) which can inter-operate with RDP. Prior to this there was a modified Windows NT 3.51 (1995) called "WinFrame" by Citrix using the proprietary ICA protocol (Independent Computing Architecture). After MS came out with its own terminal server, Citrix still remained on the scene. It created MetaFrame software (formerly pICAsso) as an add-on to MS's Terminal Server (or Services) so that it could support ICA-based terminals and provide other additional features. Before MS got into the act, there were other proprietary systems for terminals that could display the MS Windows GUI but later on they all switched to support Microsoft's system. PCs running Linux can be turned into ICA based client terminals using "free" (in price only) proprietary ICA client software from Citrix: Installing the Linux Client . Unfortunately, MS requires that you purchase a license to cover the clients, even if the clients all run Linux. So if you want to save money on software costs by using Linux, you'll have to go all-Linux and use both Linux servers and clients using the free X-Window protocol. The above is sometimes called "network computing" since the terminals and servers connect to each other over a network (such as the common TCP/IP based network used by both Linux and MS). Network computers may be somewhat different as described below. 3.2.1. Network computers (NCs) These are neither true computers nor true terminals but are something in-between. One type of network computer (NC's) is a computer with a CPU but no hard Disk. The OS it needs to run is sent to it over a network. NCs are full-graphics and use the services of a server computer. They are a little different from terminals since some (or most) of the programs they run may execute on their own CPU chip. Running a browser was supposed to be one of their primary functions and thus Java code applets may be sent to them for execution. Many NCs support X Window so that one may use a Linux server to support it. Such a server may be called a "Linux Terminal Server". IBM called their NC a "NetStation" but now calls it "NetVista". They should work on Intranet type networks and NetVista can run the Linux OS. Wintel came out with a "NetPC" which, unlike the above, is almost a PC computer. However, it has no removable disks so users can't install their own software or obtain copies of anything. 3.2.2. Thin clients and NCs under Linux There is a "Linux Terminal Server Project" (LTSP or ltsp) to use Linux as a server for diskless thin clients. They use X Window and by default, applications run on the server. But with additional effort, one can set it up so that some or all applications run on the "terminal". See . "Terminal" in LTSP is actually a thin (or fat) client. This project's client can also run a telnet session and thus behave like a text- terminal. A software package named "lts" for the LTSP is available in the major Linux distributions. It's claimed that if one has only a few "terminals", they will work without the ltsp software. But if one has many "terminals", ltsp software is needed. So use ltsp if what you want to do is to use old PCs, etc. as diskless thin clients. It works OK on systems with over 100 thin-client workstations. Linux provides NFS (Network File System) so that if ordinary computers are connected to each other via a network, then a person on one computer can run programs on another computer. Such a program sends messages over the network so that it appears just like a program was being run by your local computer. But such a program is actually being run on another computer on the network. It works also with X Window so that one may see GUI images generated on another computer. Linux also allows a computer to be diskless and boot over a network. See the "Terminal Server Project" above which has special software for this purpose. Network-boot-HOWTO gives an overview. Older documents are Diskless-HOWTO and Diskless-root-NFS-HOWTO. Thus using a diskless computer which runs NFS enables you to run programs on another computer (the server). This is just like using a NC (Network Computer). It's not really a NC but it's emulating a type of NC. It's also often called a "terminal" and in some sense it is. Thus if you have an old PC with an ethernet card (NIC) you may be able to use it as a NC. One source of info on this is Thinclient-HOWTO. Even if your old PC doesn't have a NIC, you could still use it to emulate a text-terminal. See ``Terminal Emulation''. There are also a number of genuine Network Computers (NC) that will work with a Linux server. Today some NCs run the Linux OS inside the NC. Before Linux became popular, NCs didn't run the Linux OS but required some other OS. But even if the NC uses a non-linux OS, it's often possible to make it work with a Linux Server. The non-linux OS is simply stored as files on the Linux Server. Then when the NC starts up it sends a message to the Linux Server asking for the non- linux OS files. This non-linux OS is thus sent to the NC over the network and the NC boots. The Linux Server runs the NFS and X Window both of which must be supported by the NC. This enables one to use the NC as if it were an X Window terminal. There are some Linux HOWTOs for certain brands of NCs: · JavaStation-HOWTO (by Sun) · NC-HOWTO (IBM NetStation) · NCD mini-HOWTO (NCD-ThinSTAR) · NCD-X-Terminal mini-HOWTO · XDM-and-X-Terminal mini-HOWTO 3.2.3. 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. 3.2.4. History and the future Promoters of NCs and related Window-Terminals projected that they would soon replace millions of PCs. In 1998 about .7 million thin clients were sold worldwide with (about 27% of them being NCs). In 1999 it dropped to .6 million but went up to .9 million in 2000 (vs. 1.3 million predicted). In 2001 it reached 1.09 million with 1.4 million predicted for 2002. Microsoft servers (as of 2003) still dominate the market, but the clients may run Linux for which users still have to pay license fee for each Linux client to Microsoft. Thus free all-linux systems are gaining ground. A major reason why growth was not as rapid as predicted is that PCs have come down in price in recent years so that they are often not much more expensive than a thin client. However, it's argued that even though thin clients may cost the same as PCs, the maintenance and administration costs are less. Note that thin clients sometimes replace text terminals instead of PCs. 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''. 5. Why Use a Terminal ? 5.1. Intro to Why Use a Terminal PC's are so powerful today that just one PC can often support several persons using it at once, especially if they are doing low-load tasks such as text editing, data entry, etc. One way to do this is to connect a number of terminals to a single PC (or other host computer) by modems or direct cable connection. To do this, it's usually best to have a multi-user operating system such as Linux so that each user at a terminal can use the computer independently. This has been called "time sharing" but it's not good terminology today since "distributed" computing over a network is also a type of time sharing. It might be better described as "centralized" computing. But the central computer may be connected to the rest of the world via a network so that terminal users may send email, browse the Internet with the lynx browser, etc. So it's not exactly "centralized" either. Terminals have seldom been used with PC's because the popular operating systems used for them (Windows, DOS, and Mac) were not multiuser until 1998 (available for MS Windows NT) and previously could not support terminals very well. Now that Linux, a multiuser operating system, is freely available for PC's, the use of terminals with PC's becomes more feasible. The drawback is that text terminals are not smart enough to support the type of graphical user interface (GUI) that many computer users today normally expect. 5.2. Lower Hardware Costs ? When Computers (including PCs) were quite expensive, lower hardware costs was a significant advantage of using terminals. Today with cheap PCs, the cost savings is problematical. Here's what I wrote years ago when PCs were more expensive. It's still true today but of less significance. If several people use the same computer as the same time, there is a reduction in the amount of hardware needed for the same level of service. One type of savings is due to code sharing. The application files on hard disks are shared as well as shared libraries in memory (even when people are running different programs provided they use some of the same functions in their code). Another type of savings is due to reduction of peak load. The hardware of a single PC may be idle most of the time as people slowly type in information, think, talk, or are away from their desks. Having several people on the same computer at once makes good use of much of this idle time which would otherwise be wasted. These savings are substantial. One may roughly estimate (using statistical theory) that for 9 persons (8 terminals & 1 console) the shared PC only needs only about 3 times as much capacity (in memory, disk storage, CPU power, etc.) as a single PC in order to provide the same level of service per person. Thus the computational hardware for such a shared system should only cost about 1/3 as much per user. However, the cost of the display hardware (CRT's, keyboards, video electronics, etc.) is about the same for both cases. The terminals have the added cost of requiring additional serial ports at the host computer. For a fair comparison with PC's, the terminals should have the same capabilities as the PC monitors. Unfortunately, color graphic terminals for Linux (X Window) with high speed communication cost about as much as a PC so in this case there not much (if any) savings in hardware costs. But for text terminals there will be some savings, especially if the terminals are obtained used at low cost. 5.3. Control of Software For centralized computing, software (and the updates to software) only need be installed and configured on one host computer instead of several. The person in charge of this computer may control and configure the software which is installed on it. This is advantageous if the person controlling the host computer does an excellent job and knows about the needs and preferences of the other users. Users can be restricted in playing games or surfing the Internet by not installing the software (or by otherwise restricting access to it). Whether or not centralized control is desirable depends on the situation. 5.4. Hardware Upgrades With terminals, the computer hardware upgrades take place on only one computer instead of many. This saves installation labor effort. While the cost of the hardware for the host computer upgrade will be more than that for a single PC (since the host needs more computing power than a PC), the cost will be significantly less than upgrading the hardware of a number of PC's being used instead of terminals. 5.5. Other Advantages of Terminals · The elimination of noise from fans and disk drives (unless you're using a PC to emulate a terminal). · The users of the terminals can share data and files and send e-mail to each other. It's similar to a local network. 5.6. Major Disadvantages of Terminals · Text terminals have no high-speed graphic display (or high resolution graphics) although they can often use graphic character sets to draw boxes, etc. This lack limits the software that may be used on it. · If the host computer goes down, then no one can use the terminals either (unless there is a "standby" host computer to connect to). · A display of progress will sometimes greatly increase the time taken to do the job. For example, when copying a large number of files and displaying the name of each, the terminal may only be able to display the full path names of say 30 files per second so only 30 files per second will be copied. But the computer hardware is capable of copying at a rate many times higher. This can often be fixed by using options of application programs for a minimal display of progress. See ``Problem with Slow Scrolling'' 5.7. Are Text Terminals Obsolete ? Text terminals are technologically obsolete because for a slightly higher cost of hardware, one could build a smarter terminal (with the same quality of display). This wasn't always the case since around 1980 memory cost thousands of dollars per megabyte. Today with low costs for memory and processors, one could turn a text terminal into a GUI graphic terminal for only about a 10% or 20% increase in hardware cost. Since a PC can emulate a terminal, almost everyone using computers has a terminal emulator available. The reasons that text terminals are not fully obsolete are: · The resolution of characters on the screen is better on monochrome terminals than for monitors in text mode. · Many people don't need full screen graphics. · Since running a text-terminal (in contrast to a GUI-graphics terminal) doesn't consume much of a modern PC's resources, a large number of terminals may be efficiently run from one PC. 6. Overview of How Terminals Work (in Linux) See also section ``Some Details on How Terminals Work'' 6.1. Device Names Each terminal is connected to a serial port on the host computer (often just a PC). The ports have names/numbers. The first few are: ttyS0, ttyS1, ttyS2, etc. These are represented by special files found in the /dev (device) directory. ttyS0) corresponds to COM1 in DOS or Windows. ttyS1) is COM2, etc. See ``Terminal Special Files'' for details on these and related "devices". 6.2. Login/Logout When the host computer starts up it runs the program getty. The getty program runs the "login" program to log people in. See ``Getty (used in /etc/inittab)''. A "login:" prompt appears on the screen. People at the terminals 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). 6.3. Half/Full Duplex If one watches someone typing at a terminal, the letters one types simultaneously appear on the screen. A naive person might think that what one types is being sent directly from the keyboard to the screen with a copy going to the computer (half-duplex like, see next paragraph). What is usually going on is that what is typed at the keyboard is directly sent only to the host computer which in turn echoes back to the terminal each character it receives (called full- duplex). In some cases (such as passwords or terse editor commands) the typed letters are not echoed back. Full-duplex means that there are two (dual) one-way communication links. Full-duplex is the norm for terminals. Half-duplex is half of a duplex, meaning that there is only a single one-way communication link. This link must be shared by communications going in both directions and only one direction may be used at a time. In this case the computer would not be able to echo the characters you type (and send to it) so the terminal would need to also send each character you type directly to the terminal screen. Some terminals have a half- duplex mode of operation which is seldom used. 6.4. Terminal Memory The image on a CRT tube will fade away almost instantly unless it is frequently redrawn on the screen by a beam of electrons shot onto the face of the tube. Since text sent to a terminal needs to stay on the screen, the image on the screen must be stored in the memory chips of the terminal and the electron beam must repeatedly scan the screen (say 60 times per second) to maintain the image. See ``Terminal Memory Details'' for more details. 6.5. Commands for the Terminal The terminal is under the control of the computer. The computer not only sends the terminal text to display on the screen but also sends the terminal commands which are acted on. These are ``Control Codes'' (bytes) and ``escape sequences''. For example, the CR (carriage return) control code moves the cursor to the left hand edge of the screen. A certain escape sequence (several bytes where the first byte is the "escape" control code) can move the cursor to the location on the screen specified by parameters placed inside the escape sequence. The ``first terminals'' had only a few such commands but modern terminals have hundreds of them. The appearance of the display may be changed for certain regions: such as bright, dim, underline, blink, and reverse video. A speaker in a terminal can "click" when any key is pressed or beep if a mistake has occurred. Function keys may be programmed for special meanings. Various fonts may exist. The display may be scrolled up or down. Specified parts of the screen may be erased. Various types of flow control may be used to stop the flow of data when bytes are being sent to the terminal faster than the terminal can handle them. There are many more as you will see from looking over an advanced terminal manual or from the Internet links ``Esc Sequence List'' 6.6. Lack of Standardization Solved by Terminfo While terminals made for the US all used the same ASCII code for the alphabet (except for IBM terminals which used EBCDIC), they unfortunately did not all use the same escape sequences. This happened even after various ANSI (and ISO) standards were established since these standards were never quite advanced enough. Furthermore, older terminals often lacked the capabilities of newer terminals. This might cause problems. For example, the computer might send a terminal an escape sequence telling it to split the screen up into two windows of specified size, not realizing that the terminal was incapable of doing this. To overcome these problems a database called "termcap" (meaning "terminal capabilities") was established. Termcap was later superceded by "terminfo". This database resides in certain files on the computer and has a section of it (sometimes a separate file) for each model of terminal. For each model (such as VT100) a list of capabilities is provided including a list of certain escape sequences available. For example blink=\E5m means that to make the cursor start blinking the terminal must be sent: Escape 5 m. See Section ``Termcap and Terminfo (detailed)'' for more details. Application programs may utilize this database by calling certain C-Library functions. One large set of such programs (over 200) is named "ncurses" and are listed in the manual page for "ncurses" which comes with a developer's ncurses package. There is also a NCURSES-programming-HOWTO. 6.7. The Interface The environment variable TERM is the type of terminal Linux thinks you are using. Most application programs use this to look up the capabilities in the terminfo database so TERM needs to be set correctly. But there is more to a correct interface than the computer knowing about the capabilities of the terminal. For bytes to flow from the computer to the terminal the terminal must be set to receive the bytes at the same baud rate (bits per second) as they are sent out from the terminal. If the terminal is set to receive at 19,200 baud and the computer sends out characters at 9600 baud, only garbage (or perhaps nothing) will be seen on the screen. One selects the baud rate for a terminal (as well as many other features) from the terminals "set-up" menus at the terminal. Most terminals have a large number of options in their "set-up" menus (see ``Terminal Set-Up (Configure) Details''). The computer serial port has options also and these options must be set up in a compatible way (see ``Computer Set-Up (Configure) Details''. 6.8. Emulation Most terminals today have more than one emulation (personality or "terminal mode"). The terminal model numbers of terminals formerly made by DEC (Digital Equipment Corporation now Compaq) start with VT (e.g. VT100). Many other terminals which are not VT100 may be set up to emulate a VT100. Wyse was a major terminal manufacturer until about 2005. Most of their terminals can emulate various DEC terminals such at VT100 and VT220. Thus if you want to, say, use a VT320 terminal you may either use a real VT320 in "native" personality or possibly use some other terminal capable of emulating a VT320. The "native" personalities usually have more capabilities so, other things being equal, "native" is usually the best to use. But other things may not be equal. Since the Linux console emulates a VT102 it you may want to have a terminal emulate this (or something close to it such as VT100). This will help insure that some programs that may not handle terminals properly will still work OK on your terminal. Some programs will assume that you are using a VT102 if the program can't find a terminfo for your terminal (or can't find a certain capability). Thus the failure of a program to work correctly with your non-vt102 terminal may well be your fault if you don't provide a good terminfo file for your terminal. Using "native" and then reporting any bugs will help discover and fix bugs which might not otherwise get detected. The most common type of emulation is to use a PC like it was a vt100 terminal (or the like). Programs loaded into the PC's memory do the emulation. In Linux (unless you're in X Window) the PC monitor (called the console) emulates a terminal of type "Linux" (close to vt100). Even certain windows within X Window emulate terminals. See ``Terminal Emulation''. 6.9. The Console On a PC, the monitor is normally the console. It emulates a terminal of type "Linux". One logs on to it as a virtual terminal. See ``The Console''. It receives messages from the kernel regarding booting and shutdown progress. One may have the messages that normally go to the console, go to the terminal. To get this you must manually patch the kernel, except that for kernel 2.2 (or higher) it is a "make config" option. See ``Make a Serial Terminal the Console''. 7. Terminal Special Files such as /dev/tty "tty" is an abbreviation for "Teletype". The first terminals were Teletypes (like remotely controlled typewriters). See subsection ``Teletypes''. A list of Linux devices (the stuff in the /dev directory) may be found in "Linux Allocated Devices" which should be included with kernel sources. It "describes" what each device used for in only a word or two but doesn't tell you how to use them. 7.1. Serial Port Terminals The computer considers each serial port to be a "device". It's sometimes called a terminal device since at one time terminals were the most common use for a serial port. For each such serial port there is a special file in the /dev (device) directory. /dev/ttyS0) is the special file for the serial port known as COM1 in the DOS/Windows world. To send text to a terminal you may redirect standard output of some command-line command to the appropriate special file. For example typing "echo test > /dev/ttyS1" at the command prompt should send the word "test" to the terminal on ttyS1 (COM2) provided you have write permission on /dev/ttyS1. Similarly, typing "cat my_file > /dev/ttyS0" will send the contents of the file my_file to COM1 (ttyS0). 7.2. Pseudo Terminals Pseudo terminals are pairs of devices such as /dev/ptyp3 and /dev/ttyp3. There is no physical device directly associated with either of them, not even a serial port connector. But if a program treats ttyp3 like it was a serial port, what is read and written to that port appears on the other member of the pair ptyp3 which another program uses to read and write to. Thus two programs talk to each other via this method and one program on ttyp3 thinks it's talking to a serial port. It's something like a "pipe" between these two tty's. For talking to ttyp3, any program designed to talk to a serial port will do. But for the other program that talks to ptyp3, it must have been specially written to talk to it. It's mainly programmers that must concern themselves with pseudo terminals and most users don't need to worry about them. Here's an example: If someone connects via telnet to your computer over a network (you are a telnet server), the part of the telnet program handling this connection on your computer may wind up connected to the pseudo terminal ptyp2. A getty program should be running on the corresponding ttyp2. Getty thinks it's talking to a terminal. When telnet gets a character from the remote client, it goes thru ptyp2 to ttyp2 to getty which then sends back "login:" routed via ttyp2, ptyp2, your server telnet program, and then out to the network back to the client. Here the login program and the telnet server program talk to each other via a "pseudo terminal". Note that there is no pseudo terminal used on the client computer, just telnet. Of course the server allocates a pseudo terminal (on the server) for each client. In X Window, the terminal emulator programs (such as xterm) use pseudo terminals. Ham radio programs under Linux also use them. By using certain application software, it is possible to have 2 or more pseudo terminals attached to the same physical serial port. For a pseudo terminal pair such as ptyp3 and ttyp3, the pty... is the master or controlling terminal and the tty... is the slave. There are only 16 ttyp's: ttyp0-ttypf (f is a hexadecimal digit). To get more pairs, more letters such as q, r, s are used instead of p. For example the pair ttys8, ptys8 is a pseudo terminal pair. Later on, even more letters were added so as to allow even more pseudo terminals. And when z was reached, they wrapped around to a. This is confusing but old habits are difficult to change. Today Linux allow say ttyp189 but it's not used. The device file system, which was abandoned in 2004, would have used tty/s189. Be sure not to type say ttys2 if you mean ttyS2 (a real serial port). The master and slave are really the same "port" but the slave is used by the application program and the master is used by a network program (or the like) which supplies (and gets) data to/from the slave port. The program using the slave port can run "as is" since it thinks it is talking to a serial port. Unix98 pseudo terminals (available on Linux) is more advanced than the above but the basic concepts are the same (only the device names and methods of creating them change). It creates pseudo terminal devices on request so there is no need to check if the pseudo terminal you might want to use in in use. By opening /dev/ptmx a new pseudo terminal pair is created. The master doesn't show up as a device but is just a file descriptor number passed to the computer program that opened /dev/ptmx. But the slave is put into the /dev/pts directory: for example" /dev/pts/3. The /dev/pts directory is considered to be a file system of type devpts and appears in the lists of mounted filesystems. While the "file" /dev/pts/3 looks like an entry in the now obsolete device filesystem, /dev/pts Is really a wholly different kind of filesystem. See the Linux manual pages "pty" and "pts" (Unix 98 style) for more details. For programmers there's the man-page openpty/forkpty (either name displays the same man-page) which assumes that you already understand pseudo terminals. There is a usr/include/pty.h file for use by programmers. In earlier versions of Linux there was a pty.o module, but it now seems that it's been built into the kernel. Here's an example of some options available when you are compiling a Linux 2.6 kernel: CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 7.3. The Controlling Terminal /dev/tty /dev/tty stands for the controlling terminal (if any) for the current process. To find out which tty's are attached to which processes use the "ps -a" command at the shell prompt (command line). Look at the "tty" column. For the shell process you're in, /dev/tty is the terminal you are now using. Type "tty" at the shell prompt to see what it is (see manual pg. tty(1)). /dev/tty is something like a link to the actually terminal device name with some additional features for C-programmers: see the manual page tty(4). 7.4. /dev/ttyIN "Terminals" N stands for an integer. One use of these in Linux is with the ISDN driver package: isdn4linux. The ttyIN is something like ttySN but it emulates a modem and can be given modem commands. 7.5. The Console: ttyN or vc/N In Linux the PC monitor is usually called the console and has several device special files associated with it: vc/0 (tty0), vc/1 (tty1), vc/2 (tty2), etc. When you log in you are on vc/1. To go to vc/2 (on the same screen) press down the 2 keys Alt(left)-F3. For vc/3 use Left Alt-F3, etc. These (vc/1, vc/2, vc/3, etc.) are called "virtual terminals". vc/0 (tty0) is just an alias for the current virtual terminal and it's where messages from the system are sent. Thus messages from the system will be seen on the console (monitor) regardless of which virtual terminal it is displaying. You may log in to different virtual terminals and thus have a few different sessions with the computer going on at the same time. Only the system or the root user may write to /dev/vc/0 to which /dev/console is sometimes linked. For more info on the console see ``The Linux Console''. 7.6. Creating a Device with "mknod" The /dev directory comes supplied with many device special files. If you need something that's not there you may try to create it with the "mknod" command. See the manual page ttys(4) for how to do this for serial ports. To use mknod you must know the major and minor device numbers. You might be able to infer the numbers you need by using the "ls -l" command in the /dev directory. It will display the major and minor numbers of existing special files. 8. Some Details on How Terminals Work If you know almost nothing about terminals, it's suggested that you first read ``Introduction'' and also read ``Overview of How Terminals Work''. 8.1. Terminal Memory Details The terminal screen refreshes itself at perhaps 60 times per second from an image stored in the memory of the terminal. For a PC the monitor's image is stored on the video card inside the computer but for a terminal, the equivalent of the video card is inside the terminal. For a text terminal the storage of the image uses little memory. Instead of putting every dot (pixel) on the screen into memory and requiring the storage of about a quarter-million dots, a much more efficient method of storage is used. A screen-full of text may be represented inside the terminal memory by ASCII bytes, one for each character on the screen. An entire screen only takes about 2K ASCII bytes. To display these characters, the terminal must also know the bit-map (the shape) of each of the almost 100 printable ASCII characters. With a bit-map of a character using say 15 bytes, only about 1.5K of memory is needed for the bit-maps of all the ASCII characters (the font). This ASCII text and font memory is scanned so that the resulting image is put on the screen about 60 times each second. This is a form of shared memory where a single bit-map of a letter such as the letter e, is shared by all of the many letter e's which appear on a screen-full of text. Low memory requirements meant low costs to produce monitors in the early 1980's when the cost of memory was several thousand times higher than it is today (costing then several dollars per kilobyte). 8.2. Early Terminals The first terminals were something like remotely controlled typewriters which could only "display" (print on paper) the character stream sent to them from the computer. The earliest models were called ``Teletypes''. The name "tty" is just an abbreviation for "Teletype". Early terminals could do a line feed and a carriage return just like a typewriter and ring a bell when a bell character was received. Due to the lack of significant capabilities this was the first type of terminal to be labeled "dumb". This type of terminal interface (using a terminal type called "dumb") is sometimes used today when the computer can't figure out what kind of a terminal it is communicating with. 8.3. Escape Sequences and Control Codes (intro) Terminals have many capabilities some of which are always present and some of which require commands from the computer to change or activate. To exercise all these capabilities under the control of the computer requires that special codes be established so that the computer can tell the terminal what to do. There are two major type of such codes: escape sequences and control codes (control characters). There are many times more escape sequences than control codes. 8.3.1. Control codes The control codes (or control characters) consist of the first 32 bytes of the ASCII alphabet. They include the following: carriage- return (cursor to far left), line-feed (cursor down one line), backspace, escape-character, tab, and bell. They do not normally show on the screen. There is usually a command which you may give to your terminal which will result in them being displayed when they are received by the terminal. It's called something like "Display Controls" or "Monitor". If you do this then the display may look a mess since escape sequences, which all start with the ESC (escape) control character, are no longer executed. Words which should appear at the top or bottom of the screen will show up in other locations. The escape sequences to reposition the cursor display on the screen but the cursor doesn't move to where the escape sequence says. 8.3.2. Escape sequences Since there are not nearly enough control codes to do everything (and for some reason, not all of them are utilized) many escape sequences are used. They consist of the "escape" (ESC) control character followed by a sequence of ordinary characters. Upon receiving an escape character, the terminal examines the characters following it so that it may interpret the sequence and carry out the intended command from the computer. Once it recognizes the end of a valid sequence, further characters received just display on the screen (unless they are control codes or more escape sequences). Some escape sequences may take parameters (or arguments) such as the coordinates on the screen to move the cursor to. The parameters become a part of the escape sequence. An ``Esc Sequence List'' is on the web for some terminals, but it's terse. A list of the escape sequences for your terminal should be in the "programmers manual" for the terminal. Except for very old terminals, there may be two or three hundred such sequences. If you don't have a such manual it's not easy to find them. Some of the sequences are available on the Internet. One link is ``Esc Sequence List''. By searching the Internet for one sequence (such as ESC[5m) you may come across a long list of them. Another way to determine some of them is to find the terminfo entry (termcap) for the terminal and mentally decode it. See ``Terminfo and Termcap (detailed)'' in this document and/or the ``Termcap Manual'' on the Internet. Unfortunately, the terminfo (termcap) for a terminal often does not list all of the escape sequences which the terminal has available for use, but fortunately, the most important ones are usually there. 8.4. Display Attributes & Magic Cookies Terminals have various methods of generating character attributes such as bold, reverse-video, underlining, etc. There should be no need for the user to worry about how this is done, except that it creates problems for some old terminals and there is sometimes an option for this in the set-up menu of newer terminals. The magic cookie method is obsolete. It's the simplest (and worst) method of defining attributes: Use a certain byte for the start of an attribute and another to end that attribute. For example, a "start underlining" magic cookie byte is placed just before the first word to be underlined. These extra bytes are put into the memory of the screen page, just like character bytes that display as characters. But this might foul up the count of the number of characters per line since non-printable magic cookie characters are intermingled with other printable characters. This sometimes causes problems. A better method which uses more memory is to assign an attribute byte (or half=byte, etc.) to each displayed character. This method is used by PC video cards (for text) for the common PC monitor. 9. Special Features of Some Terminals 9.1. Color While the common monochrome terminal is not a color terminal it may have a fixed "color" display other than white such as green or amber. All terminals have black (electron beam turned off = zero brightness). A real color terminal can change the color of the text and background to many different colors while a monochrome terminal can only change the brightness of a fixed color. However, changing the brightness, etc. gives a lot of possibilities. For example, a black and white (monochrome) terminal can have white, grey, and black by varying the brightness. Some words can be black on a light grey background while other are highlighted by black on white. In addition there is white on black, underlining, and blinking. Color works like the color on a computer monitor or TV screen. The CRT has three colors of dots on it with each color controlled by its own electron beam (3 beams). Monochrome has inherently better resolution since it doesn't depend on dots permanently fixed on the screen. For text terminals the only use of color is to differentiate text and this advantage is not always worth the cost of worse resolution. Thus monochrome may be better since it also costs less. 9.2. Multiple Sessions For dual sessions the terminal has two serial ports of equal status. Each port is connected to a serial port on a different computer. Thus one may log in to two different computers with each session displaying in a split-screen window. Alternatively, each session may run full- screen with a "hot" key (or the like) to switch between sessions. One could also connect to two different serial ports on the same computer and log in twice (similar to "virtual terminals" at the console). The program "screen" will make any ordinary terminal (single session) connected to a single computer run two or more "sessions". 9.3. Printer/Auxiliary Port Many terminals have a connector on the rear for such a port. It may be labeled as "Aux" or "Printer", etc. Some printer ports are for parallel printers while others are for serial printers. If a printer is connected to the printer or auxiliary port, then pressing certain keys will print the screen. One may also have everything that displays on the screen go also to the printer. If the port is an auxiliary port, one may connect this to another computer and almost have dual sessions as above. However, the video memory inside the terminal may not retain both sessions so you may need to refresh the screen when switching to the other session. There will likely not be a hot key either but possibly a programmable function key may be programmed to do this. There exists various key combinations and escape sequences for controlling such a port. See ``Printer Esc''. There is a program called vtprint which is designed to send a print job (text only) to your terminal to be printed on a printer attached to the terminal. It's homepage is 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 for each running program. 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. More info re character-sets are: · Manual pages: charsets, iso_8859-l or latin1 (covers 8859 series), ascii · HOWTO's for various languages (often written in that language). · ISO-8859 Alphabet Soup More than just iso8859. Extensive. · A tutorial on character code issues Clearly written. · Languages, Countries and Character Sets · Languages of the World by Computers ... · ... International Character Sets Once you've found the character set name (or alpha-numeric designation) you are interested in, you may search for more info about it on the Internet. 9.5.1. Graphics (Line Drawing, etc.) There are special characters for drawing boxes, etc. There are also numerous non-ASCII symbols such as bullets. These may either be part of an 8-bit character set (such as WinLatin1 = CP-1252) or provided as a separate font (in vt100 terminals). Your terminfo may be set up to use them. But if you see a row of letters when there should be a line, it may mean that terminfo hasn't implemented them. You need to know the following if your graphics don't work right. The default graphic character set is the vt-100 ANSI graphics. Otherwise the string acsc must be defined in your terminfo. It establishes a map between the vt-100 graphic characters codes and the actual codes used on your terminal. So even if your terminal doesn't have the vt-100 graphics, it can likely still generate such graphics with some other character set. If terminfo has it right, this will happen automatically. If character sets must be switched then the terminfo variables: enacs, rmacs, and smacs should be defined. Note acs = Alternate Character Set. Even if the upper half of the normal character set contains the graphic characters it may be considered a separate 7-bit character set that needs to be switched to. 9.5.2. National Replacement Characters (obsolete) In the 1960's, the ASCII 7-bit code was devised to map 7-bit bytes to English letters, numbers, punctuation marks, etc. Other countries adopted ASCII, but most of them had some additional letters which were not present in the ASCII code. What to do? Various people decided to purge certain symbols (such as ^, }) from ASCII and to substitute national letters (ones with dots over them, etc.) for the ASCII letters. In other words they replaced ASCII letters with "National Replacement Characters" There were a lot of problems with this, since it was done mostly by companies which sold computer terminals with a resulting lack of standardization. Another problem was that sometimes the purged symbols were needed. This problem was solved in the 1980's and 1990's with the adoption of 8-bits/byte character sets which had many more letters. Many West-European languages only needed several additional letters which were not in ASCII. To get them in 7-bit code, they borrowed the codes for seldom used ASCII symbols: } ~ when using these replacement character sets, you are deprived of using certain of these ASCII symbols since they now are used for the new non-ASCII letters. Now that 8-bit character codes have replaced 7-bit ones, it's better to use an 8-bit code which has both all the ASCII symbols plus the non-ASCII characters for various languages. There's also Unicode which replaces 8-bit codes with the same code scheme to cover all languages (well almost all significant ones). ISO-646 (for 1972 and later) permitted using National Replacement Characters (7-bit). It specified that the above mentioned character codes may be borrowed, but doesn't specify which national characters are to replace them. Some countries standardized the replacements by registering them with ECMA. Many terminals exist which support these national replacement characters but you probably don't want to implement this support unless you have some old files to read. Very old terminals may only support the national characters for the country in which they were sold. Later terminals offered a choice of languages. Modem terminals are 8-bit and don't need "national replacements". Replacement characters exist for the following languages/countries: British, Cuba (Spanish), Dutch, Finnish, French, French Canadian, German, Hebrew, Hungarian, Italian, Norwegian/Danish, Portuguese, Spanish, Swedish, Swiss (German). Here's tables for some character sets taken from Kermit and Unisys documents: Swedish Danish ASCII German Finnish Norwegian French @ at-sign section ------- ------- a-grave [ left-bracket A-diaeresis A-diaeresis AE-digraph degree / backslash O-diaeresis O-diaeresis O-slash c-cedilla ] right-bracket U-diaeresis A-circle A-circle section ^ circumflex ------ U-diaeresis ------- ------- ` accent-grave ------ e-acute ------- ------- { left-brace a-diaeresis a-diaeresis ae-digraph e-acute | vertical-bar o-diaeresis o-diaeresis o-circle u-grave } right-brace u-diaeresis a-circle a-circle e-grave ~ tilde ess-zet u-diaeresis -------- diaeresis ASCII Italian Spanish @ at-sign section section [ left-bracket degree inverted-exclamation / backslash #-pound N-tilde ] right-bracket e-acute inverted-question-mark ^ circumflex ------- ------- ` accent-grave u-grave ------- { left-brace a-grave degree | vertical-bar o-grave n-tilde } right-brace e-grave -------- ~ tilde i-grave -------- 9.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 For mapping the keyboard (and screen) for use of various fonts see ``Character Mapping: mapchan'' 9.7. Keyboards & Special Keys Terminal keyboards often have a number of keys that one doesn't find on a PC keyboard. Few (if any) actual terminals will have all of these keys and most will have additional keys not listed here. Some have a large number of special purpose keys such as terminals made for use with cash registers. There are often many more key meanings than shown here since these keys often have extended meanings when used in conjunction with other keys (such as shift and control). · BREAK sends a very long 0 bit (space = +12 V) of duration 300 to 700 milliseconds to the host. The host may interpret this as an interrupt if stty has set brkint or ignore it if ignbrk is set. · NO SCROLL stops the screen from scrolling like ^S does. Depressing it again resumes scrolling. Uses flow control signals to do this. · REPEAT if held down with an other key, forces repeated output of that other key even if the auto-repeat option is set to off. · LINE FEED sends the line feed character ^J to the host. Seldom used. · SET-UP allows the manual configuration of the terminal via menus. Sometimes purposely disabled by putting a block under it so it can't be pressed down. Sometimes another key such as shift or control must be pressed at the same time. See ``Getting Into Set-Up (Configuration) Mode''. · LOCAL disconnects the terminal from the host. In local, what one types goes directly to the screen. Useful for testing. · RETURN is the same as the "enter" key on a PC. It usually sends a carriage return to the host which normally get translated to a new- line character by the host's device driver. On some terminals it may be set up to send something else. · F1, F2, ... or PF1, PF2, ... are function keys which 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 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 ?? 10. Terminal Emulation (including the Console) 10.1. Intro to Terminal Emulation Since a PC has a screen and keyboard (as does a real terminal) but also has much more computing power, it's easy to use some of this computing power to make the PC computer behave like a real text terminal. This is one type of terminal emulation. Another type of terminal emulation is where you set up a real terminal to emulate another brand/model of terminal. To do this you select the emulation you want (called "personality" in Wyse jargon) from the terminal's set-up menu. Still a third type is where you just use a text-based interface (at the console) to your Linux PC, either by a terminal screen in Xwindow or by a "virtual terminal". This section only covers the first case. 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. 10.2. Don't Try to Use TERM Variable for Emulation Some have erroneously thought that they could create an emulator at a Linux console (monitor) by setting the environment variable TERM to the type of terminal they would like to emulate. This does not work. The value of TERM only tells an application program what terminal you are using. This way it doesn't need to interactively ask you this question. If you're at a Linux PC monitor (command line interface) it's a terminal of type "Linux" and since you can't change this TERM must be set to "Linux". This should happen without you needing to do anything. 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. 10.3. Serial Communication (Dialing) programs Dialing programs for making a PPP connection to the Internet such as wvdial, don't normally include any terminal emulation. But some other programs (such as minicom or seyon) do both terminal emulation and modem dialing (without PPP so it's not easy to use them to connect to the internet). The program "picocom" just does terminal emulation although it's possible to type in a modem command and a phone number to dial out manually. These programs are also useful for testing modems. Seyon is only for use with X Window and can emulate Tektronix 4014 terminals. In the past one could use them to dial up some public libraries to use their catalogs and indexes, (or even read magazine articles on line). But today it's done on the Internet. The communication program C-Kermit (sometimes just called kermit) doesn't do terminal emulation for Linux (in 2006). But Kermit can emulate many terminals in its non-free MS Windows versions so you`ll see lots of claims that Kermit can do terminal emulation. With Linux, it's merely a semi-transparent pipe between whatever terminal you are on and the remote site you are connected to. Thus if you use kermit on a Linux PC the terminal type will be "Linux". If you have a Wyse60 connected to your PC and run kermit from that, you will appear as a Wyse60 to the remote computer (which may not be able to handle Wyse60 terminals). Minicom emulates a VT102 and if you use it on Wyse60 terminal vt102 the remote host will think you are a vt102 and send you vt102 escape sequences. These will flow into your computer's serial port and will get translated to the Wyse escape sequences before going out another serial port on your computer to your Wyse60 terminal. C- Kermit can't do this sort of thing. Emulators exist under DOS such as telix and procomm work just as well. The terminal emulated is often the old VT100, VT102, or ANSI (like VT100). 10.3.1. Emulation under X Window There are many terminal emulation programs (such as xterm, uxterm. gnome-terminal, and konsole) which may be run under X Window. They can usually emulate a VT102, but some may be able to emulate at VT220, or Tektronix 4014. They provide a command line interface to the computer but they don't communicate via the serial port like a text terminal. See Ubuntu -- x-terminal-emulator for a brief list of such emulators. Some are multilingual. Your Linux distribution has likely installed one for you. 10.3.2. Real terminals may be better Unless you are using X Window with a large display, a real terminal is often nicer to use than emulating one. It often has better resolution for text (since it's monochrome), and has no disk drives to make annoying noises. 10.4. Testing Terminal Emulation For the VT series terminals there is a test program: vttest to help determine if a terminal behaves correctly like a vt53, vt100, vt102, vt220, vt320, vt420 etc. There is no documentation but it has menus and is easy to use. To compile it run the configure script and then type "make". It may be downloaded from: 10.5. The Linux Console The console for a PC Linux system is normally the computer monitor in text mode. It emulates a terminal of type "Linux" and the escape sequences it uses are in the man page: console_codes. There is no way (unless you want to spend weeks rewriting the kernel code) to get it to emulate anything else. Setting the TERM environment variable to any type of terminal other than "Linux" will not result in emulating that other terminal. It will only result in a corrupted interface since you have falsely declared (via the TERM variable) that your "terminal" is of a type different from what it actually is: Linux. See ``Don't Use TERM For Emulation'' 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. 10.6. Emulation Software Emulators often don't work quite right so before purchasing software you should try to throughly check out what you will get. 10.6.1. Make a Linux PC a serial port terminal Unless you want to emulate the standard vt100 (or close to it) or a Wyse 60, there doesn't seem to be much free terminal emulation software available for Linux. The free programs minicom, picocom, and seyon (only for X Window) can emulate a vt100 (or close to it). Seyon can also emulate a Tektronix 4014 terminal. See Wyse 60 emulator . gtkterm doesn't use escape sequences, and might be said to emulate a terminal of type "dumb" so it would be quite slow if used as a text terminal for editing, etc. It's simple to set up, very weak in capabilities, but it does show its current status at the bottom of the screen. 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 . 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 . 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. 10.6.2. Make a Linux PC an IBM network terminal This happens automatically when you run programs like telnet or ssh, provided of course that your computer is connected to a network (perhaps via a modem). Telnet normally uses a network (often the Internet) to connect your console, which emulates a terminal of type "Linux", to a remote computer for you to log in to. However, there are some free programs that allow you to use telnet with IBM terminal emulation on your PC to connect with IBM mainframes. One IBM program emulates an IBM tn5250 terminal and printer and another emulates an IBM c3270. There's also one that emulates an IBM pr3287 printer (the mainframe thinks it's connected to the printer). The Debian distribution has these. It's reported that the tn5250 emulates a vt keyboard under Linux and not a 5250 keyboard like it should. Also, it's reported that the documentation and keyboard mapping for the MS Windows version are better than for the Linux version. 10.6.3. Make a non-Linux PC a terminal Emulators exist which run on non-Linux PCs. They permit you to use a non-Linux-PC as a terminal connected to a Linux-PC. Under DOS there were many programs that not only emulated a terminal but let you dial out with a modem so that you could connect to other computers over telephone lines (without getting connected to the Internet). Of historical interest is DOS Serial Communications (1994) . Today Windows comes with "HyperTerminal" (formerly simply called "Terminal" in Windows 3.x and DOS). Competing with this is "HyperTerminal Private Edition" 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 or (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 . 11. Flow Control (Handshaking) Flow control (= handshaking = pacing) is to prevent too fast of a flow of bytes from overrunning a terminal, computer, modem or other device. Overrunning is when a device can't process what it is receiving quickly enough and thus loses bytes and/or makes other serious errors. What flow control does is to halt the flow of bytes until the terminal (for example) is ready for some more bytes. Flow control sends its signal to halt the flow in a direction opposite to the flow of bytes it wants to stop. Flow control must both be set at the terminal and at the computer. There are 2 types of flow control: hardware and software (Xon/Xoff or DC1/DC3). Hardware flow control uses dedicated signal wires such as RTS/CTS or DTR/DSR while software flow control signals by sending DC1 or DC3 control bytes in the normal data wires. For hardware flow control, the cable must be correctly wired. The flow of data bytes in the cable between 2 serial ports is bi- directional so there are 2 different flows (and wires) to consider: 1. Byte flow from the computer to the terminal 2. Byte flow from the terminal keyboard to the computer. 11.1. Why Is Flow Control Needed ? You might ask: "Why not send at a speed slow enough so that the device will not be overrun and then flow control is not needed?" This is possible but it's usually significantly slower than sending faster and using flow control. One reason for this is that one can't just set the serial port baud rate at any desired speed such as 14,500, since only a discrete number of choices are available. The best choice is to select a rate that is a little higher than the device can keep up with but then use flow control to make things work right. If one decides to not use flow control, then the speed must be set low enough to cope with the worst case situation. For a terminal, this is when one sends escape sequences to it to do complex tasks that take more time than normal. In the case of a modem (with data compression but no flow control) the speed from the computer to the modem must be slow enough so that this same speed is usable on the phone line, since in the worst case the data is random and can't be compressed. If one failed to use flow control, the speed (with data compression turned on) would be no faster than without using any compression at all. Buffers are of some help in handling worst case situations of short duration. The buffer stores bytes that come in too fast to be processed at once, and saves them for processing later. 11.2. Padding Another way to handle a "worst case" situation (without using flow control or buffers) is to add a bunch of nulls (bytes of value zero) to escape sequences. Sometimes DEL's are used instead provided they have no other function. See ``Recognize Del''. The escape sequence starts the terminal doing something, and while the terminal is busy doing it, it receives a bunch of nulls which it ignores. When it gets the last null, it has completed its task and is ready for the next command. This is called null padding. These nulls formerly were called "fill characters". These nulls are added just to "waste" time, but it's not all wasted since the terminal is usually kept busy doing something else while the nulls are being received. It was much used in the past before flow control became popular. To be efficient, just the right amount of nulls should be added and figuring out this is tedious. It was often done by trial and error since terminal manuals are of little or no help. If flow control doesn't work right or is not implemented, padding is one solution. Some of the options to the stty command involve padding. 11.3. Overrunning a Serial Port One might wonder how overrunning is possible at a serial port since both the sending and receiving serial ports involved in a transmission of data bytes are set for the same speed (in bits/sec) such as 19,200. The reason is that although the receiving serial port electronics can handle the incoming flow rate, the hardware/software that fetches and processes the bytes from the serial port sometimes can't cope with the high flow rate. One cause of this is that the serial port's hardware buffer is quite small. Older serial ports had a hardware buffer size of only one byte (inside the UART chip). If that one received byte of data in the buffer is not removed (fetched) by CPU instructions before the next byte arrives, that byte is lost (the buffer is overrun). Newer UART's, namely most 16550's, have 16-byte buffers (but may be set to emulate a one-byte buffer) and are less likely to overrun. It may be set to issue an interrupt when the number of bytes in its buffer reaches 1, 4, 8, or 14 bytes. It's the job of another computer chip (usually the main CPU chip for a computer) to take these incoming bytes out of this small hardware buffer and process them (as well as perform other tasks). When contents of this small hardware receive buffer reaches the specified limit (one byte for old UART'S) an interrupt is issued. Then the computer interrupts what it was doing and software checks to find out what happened. It finally determines that it needs to fetch a byte (or more) from the serial port's buffer. It takes these byte(s) and puts them into a larger buffer (also a serial port buffer) that the kernel maintains in main memory. For the transmit buffer, the serial hardware issues an interrupt when the buffer is empty (or nearly so) to tell the CPU to put some more bytes into it to send out. Terminals also have serial ports and buffers similar to the computer. Since the flow rate of bytes to the terminal is usually much greater than the flow in the reverse direction from the keyboard to the host computer, it's the terminal that is most likely to suffer overrunning. Of course, if you're using a computer as a terminal (by emulation), then it is likewise subject to overrunning. Risky situations where overrunning is more likely are: 1. When another process has disabled interrupts (for a computer). 2. When the serial port buffer in main (or terminal) memory is about to overflow. 11.4. Stop Sending When its appears that the receiver is about to be overwhelmed by incoming bytes, it sends a signal to the sender to stop sending. That is flow control and the flow control signals are always sent in a direction opposite to the flow of data which they control (although not in the same channel or wire). This signal may either be a control character (^S = DC3 = Xoff) sent as an ordinary data byte on the data wire (in-band signalling), or a voltage transition from positive to negative in the dtr-to-cts (or other) signal wire (out-of-band signalling). Using Xoff is called "software flow control" and using the voltage transition in a dedicated signal wire (inside the cable) is called hardware flow control. 11.5. Keyboard Lock With terminals, the most common case of "stop sending" is where the terminal can't keep up with the characters being sent to it and it issues a "stop" to the PC. Another case of this is where someone presses control-S. Much less common is the opposite case where the PC can't keep up with your typing speed and tells the terminal to stop sending. The terminal "locks" its keyboard and a message or light should inform you of this. Anything you type at a locked keyboard is ignored. When the PC catches up on it's work, then the keyboard should unlock. When it doesn't, there is likely some sort of deadlock going on. Another type of keyboard lock happens when a certain escape sequence (or just the ^O control character for Wyse 60) is sent to the terminal. While the previous type of lock is done by the serial driver, this type of lock is done by the hardware of a real terminal. It's a catch-22 situation if this happens since you can't type any commands to escape out of this lock. Going into setup and resetting might work (but it failed on my Wyse 60 and I had to cycle power to escape). One could also send an "unlock keyboard" escape sequence from another terminal. The term "locked" is also sometimes used for the common case of where the computer is told to stop sending to a terminal. The keyboard is not locked so that whatever you type goes to the computer. Since the computer can't send anything back to you, characters you type don't display on the screen and it may seem like the keyboard is locked. Scrolling is locked (scroll lock) but the keyboard is not locked. 11.6. Resume Sending When the receiver has caught up with its processing and is ready to receive more data bytes it signals the sender. For software flow control this signal is the control character ^Q = DC1 = Xon which is sent on the regular data line. For hardware flow control the voltage in a signal line goes from negative (negated) to positive (asserted). If a terminal is told to resume sending the keyboard is then unlocked and ready to use. 11.7. Hardware Flow Control (RTS/CTS etc.) Some older terminals have no hardware flow control while others used a wide assortment of different pins on the serial port for this. For a list of various pins and their names see ``Standard Null Modem Cable Pin-out''. The most popular pin to use seems to be the DTR pin (or both the DTR pin and the DSR pin). 11.7.1. RTS/CTS, DTR, and DTR/DSR Flow Control Linux PC's use RTS/CTS flow control, but DTR/DSR flow control (used by some terminals) behaves similarly. DTR flow control (in one direction only and also used by some terminals) is only the DTR part of DTR/DSR flow control. RTS/CTS uses the pins RTS and CTS on the serial (EIA-232) connector. RTS means "Request To Send". When this pin stays asserted (positive voltage) at the receiver it means: keep sending data to me. If RTS is negated (voltage goes negative) it negates "Request To Send" which means: request not to send to me (stop sending). When the receiver is ready for more input, it asserts RTS requesting the other side to resume sending. For computers and terminals (both DTE type equipment) the RTS pin sends the flow control signal to the CTS pin (Clear To Send) on the other end of the cable. That is, the RTS pin on one end of the cable is connected to the CTS pin at the other end. For a modem (DCE equipment) it's a different scheme since the modem's RTS pin receives the signal and its CTS pin sends. While this may seem confusing, there are valid historical reasons for this which are too involved to discuss here. Terminals usually have either DTR or DTR/DSR flow control. DTR flow control is the same as DTR/DSR flow control but it's only one-way and the DSR pin is not used. For DTR/DSR flow control at a terminal, the DTR signal is like the signal sent from the RTS pin and the DSR pin is just like the CTS pin. 11.7.2. Connecting up DTR or DTR/DSR Flow Control Some terminals use only DTR flow control. This is only one-way flow control to keep the terminal from being overrun. It doesn't protect the computer from someone typing too fast for the computer to handle it. In a standard file-transfer serial cable the DTR pin at the terminal is connected to the DSR pin at the computer. But Linux doesn't support DTR/DSR flow control (although drivers for some multiport boards may support DTR/DSR flow control.) A way around this problem is to simply wire the DTR pin at the terminal to connect to the CTS pin at the computer and set RTS/CTS flow control (stty crtscts). The fact that it's only one way will not affect anything so long as the host doesn't get overwhelmed by your typing speed and drop RTS in a vain attempt to lock your keyboard. See ``Keyboard Lock''. For DTR/DSR flow control (if your terminal supports this two-way flow control) you do the above. But you also connect the DSR pin at the terminal to the RTS pin at the computer. Then you are protected if you type too fast. 11.7.3. Old RTS/CTS handshaking is different What is confusing is that there is the original use of RTS where it means about the opposite of the previous explanation above. This original meaning is: I Request To Send to you. This request was intended to be sent from a terminal (or computer) to a modem which, if it decided to grant the request, would send back an asserted CTS from its CTS pin to the CTS pin of the computer: You are Cleared To Send to me. Note that in contrast to the modern RTS/CTS bi-directional flow control, this only protects the flow in one direction: from the computer (or terminal) to the modem. For older terminals, RTS may have this meaning and goes high when the terminal has data to send out. The above use is a form of flow control since if the modem wants the computer to stop sending it drops CTS (connected to CTS at the computer) and the computer stops sending. 11.7.4. Reverse Channel Old hard-copy terminals may have a reverse channel pin (such as pin 19) which behaves like the RTS pin in RTS/CTS flow control. This pin but will also be negated if paper or ribbon runs out. It's often feasible to connect this pin to the CTS pin of the host computer. There may be a dip switch to set the polarity of this signal. 11.8. Is Hardware Flow Control Done by Hardware ? Some think that hardware flow control is done by hardware but only a small part of it is done by hardware. Most of it is actually done by your operating system software. UART chips and associated hardware usually know nothing at all about hardware flow control. When a hardware flow control signal is received (due to the signal wire flipping polarity) the hardware gives an electrical interrupt signal to the CPU. However, the hardware has no idea what this interrupt means. The CPU stops what it was doing and jumps to a table in main memory that tells the CPU where to go to find a program which will find out what happened and determine what to do about it. In this case this program stops the outgoing flow of bytes. But even before this program stops the flow, it was already stopped by the interrupt which interrupted the work of the CPU. This is one reason why hardware flow control stops the flow faster. It doesn't need to wait for a program to do it. But if that program didn't command that the flow be stopped, the flow would resume once that program exited. So the program is essential to stop the flow even though it is not the first to actually stop the flow. After the interrupt happens any bytes (up to 16) which were already in the serial port's hardware transmit buffer will still get transmitted. So even with hardware flow control the flow doesn't instantly stop. Using software flow control requires that each incoming byte be checked to see if it's an "off" byte. These bytes are delayed by passing thru the 16-byte receive buffer. If the "off" byte was the first byte into this buffer, there could be a wait while 15 more bytes were received. Then the 16 bytes would get read and the "off" byte found. This extra delay doesn't happen with hardware flow control. 11.9. Obsolete ?? ETX/ACK or ENQ/ACK Flow Control This is also software flow control and requires a device driver that knows about it. Bytes are sent in packets (via the async serial port) with each packet terminated by an ETX (End of Text) control character. When the terminal gets an ETX it waits till it is ready to receive the next packet and then returns an ACK (Acknowledge). When the computer gets the ACK, it then send the next packet. And so on. This is not supported by Linux ?? Some HP terminals use the same scheme but use ENQ instead of ETX. 12. Physical Connection 12.1. Introduction A terminal may be connected to its host computer either by a direct cable connection, via a modem, or via a terminal server. The flow of data may be either a direct sequence of bytes (such as from a serial port) or packets on a network (such as TCP/IP). 12.2. Multiport I/O Cards (Adapters) Additional serial cards may be purchased which have many serial ports on them called "multiport boards". These boards are not covered in this HOWTO but there is a list of some of them (with URLs) in the Serial-HOWTO. 12.3. Direct Serial Cable Connection. The simplest way to connect a terminal to a host computer is via a direct connection to a serial port on the computer. You may also use some the info in this section for connecting one computer to another (via the serial port). Most desktop PC's come with a serial port or two, one of which may be used by a mouse. For the EIA-232 port, you need a null modem cable (PC-to-PC cable) that crosses over the transmit and receive wires. In ethernet terminology it would be called a "crossover cable" (but the ethernet cable will not work for the serial port). If you want hardware flow control, you will probably use the DTR pin (or both the DTR and DSR pins). Make sure you have the right kind of cable. A null modem cable bought at a computer store may do it (if it's long enough), but it probably will not work for hardware flow control. Such a cable may be labeled as a serial printer cable. Only larger computer stores are likely to stock such cables. A "modem cable" will not work since the wires go straight thru (and don't cross over). See ``Buy or Make'' your own cable. Make sure you are connecting to your PC's serial port at the male DB25 or the DB9, and not to your parallel port (female DB25). 12.3.1. Pin numbering Pin numbers are often printed on the plastic right next to the pins. You may need a bright light and/or a magnifying glass to read them. Looking at the male pins of a DB connector with the wider row up, the pin in the upper left is 1 (there is no pin 0). Then the next pin in this row is 2, etc. At the end of this row is pin 5 or 13. Then the next pin (6 or 14) is in the next row all the way to the left and below pin 1. If you look at the female connector with the wider row up, then pin 1 is in the upper right corner. 12.3.2. Null Modem cable pin-out (3, 4, or 5 conductor) These 3 diagrams are for real text-terminals. But you could use them to connect up 2 PCs if you substitute RTS for DTR and CTS for DSR. (Don't use 4-conductors for PC-to-PC). For terminals, if you only have DTR flow control (one-way) you may eliminate the RTS-to-DSR wire. If you have no hardware flow control, then you may also eliminate the CTS-to-DTR wire. Then if you have 2@ twisted pairs, you may then use 2 wires for signal ground per ``A Kludge using Twisted-Pair Cable''. For a DB25 connector on your PC, you need: PC male DB25 Terminal DB25 TxD Transmit Data 2 --> 3 RxD Receive Data RxD Receive Data 3 <-- 2 TxD Transmit Data SG Signal Ground 7 --- 7 SG Signal Ground CTS Clear To Send 5 <--20 DTR Data Terminal Ready RTS Request To Send 4 --> 6 DSR Data Set Ready If you have a DB9 connector on your PC, try the following: PC DB9 Terminal DB25 RxD Receive Data 2 <-- 2 TxD Transmit Data TxD Transmit Data 3 --> 3 RxD Receive Data SG Signal Ground 5 --- 7 SG Signal Ground CTS Clear To Send 8 <--20 DTR Data Terminal Ready RTS Request To Send 7 --> 6 DSR Data Set Ready ** If you have a DB9 connector on both your serial port and terminal: PC DB9 Terminal DB9 RxD Receive Data 2 <-- 3 TxD Transmit Data TxD Transmit Data 3 --> 2 RxD Receive Data SG Signal Ground 5 --- 5 SG Signal Ground CTS Clear To Send 8 <-- 4 DTR Data Terminal Ready RTS Request To Send 7 --> 6 DSR Data Set Ready ** The above don't have modem control lines so be sure to give a "local" option to getty (which is equivalent to "stty clocal"). Also if you need hardware flow control it must be enabled at your computer (use a -h flag with agetty) ( equivalent to "stty crtscts" ). 12.3.3. Standard Null Modem cable pin-out (7 conductor) The following 3 diagrams show full "standard" null modem cables. One that you purchase may be wired this way. Another pinout is for 20 and 6 to cross over and to have 8 cross over to both 4 and 5. This will not provide hardware flow control (RTS/CTS) for directly connected computers. Both of the above will work for terminals using software (Xon/Xoff) flow control (or no flow control). None of these cables will work for terminal hardware flow control since most real terminals support DTR or DTR/DSR flow control (handshaking) but Linux doesn't yet (2000). PC male DB25 Terminal DB25 DSR Data Set Ready 6 <--| DCD Carrier Detect 8 <--|- 20 DTR Data Terminal Ready TxD Transmit Data 2 ----> 3 RxD Receive Data RxD Receive Data 3 <---- 2 TxD Transmit Data RTS Request To Send 4 ----> 5 CTS Clear To Send CTS Clear To Send 5 <---- 4 RTS Request To Send SG Signal Ground 7 ----- 7 SG Signal Ground DTR Data Terminal Ready 20 -|--> 8 DCD Carrier Detect |--> 6 DSR Data Set Ready Alternatively, a full DB9-DB25 file-transfer (null-modem) cable (will not work with terminal hardware handshaking; see above): PC DB9 Terminal DB25 RxD Receive Data 2 <---- 2 Tx