8488 lines
443 KiB
HTML
8488 lines
443 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
|
|
<TITLE>
|
|
Text-Terminal-HOWTO
|
|
</TITLE>
|
|
</HEAD>
|
|
<BODY BGCOLOR=white>
|
|
|
|
<HR>
|
|
<H1> Text-Terminal-HOWTO</H1>
|
|
|
|
<H2>David S. Lawyer
|
|
<A HREF="mailto:dave@lafn.org">mailto:dave@lafn.org</A></H2> v1.43 March 2013
|
|
<HR>
|
|
<EM>This document was originally written for real text terminals which were
|
|
like monitors (with keyboards), but could only display text with a command
|
|
line interface (no pictures). They were widely used to access mainframe
|
|
computers in the late 1970's and 1980's but use of them declined in the
|
|
1990's and they are seldom used anymore. However much of this howto
|
|
also applies to command-line interfaces on Linux PC's which are in wide
|
|
use today. It's not about the user programs one might run on the
|
|
command line, but about setting up, managing, and understanding the
|
|
interface itself Such as using a monitor as a virtual (text-only)
|
|
console, using a text-window in a GUI such as xterm, connecting to a
|
|
remote computer over a network via ssh, telnet, etc., or even using
|
|
software on another PC to turn it into a serial-port text-terminal. All
|
|
these 4 methods are known as "text-terminal emulation".
|
|
But unfortunately, the main emphasis in this howto is real text
|
|
terminals and the coverage of emulation is inadequate for the first 3
|
|
methods of emulation mentioned above. The Keyboard-and-Console-HOWTO
|
|
filled much this gap but it was written for Linux 2.0 and now needs
|
|
rewriting (or merging into this Text-Terminal howto). A new author is
|
|
needed that has time to do all this.
|
|
For the seldom used real text-terminals, it explains how they work, explains how
|
|
to install and configure them, and provides some info on how to repair
|
|
them. This HOWTO also provides a brief overview of modern GUI
|
|
terminals.</EM>
|
|
<HR>
|
|
<P>
|
|
<H2><A NAME="toc1">1.</A> <A HREF="#s1">Introduction </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc1.1">1.1</A> <A HREF="#ss1.1">Copyright, Trademarks, Disclaimer, & Credits</A>
|
|
<LI><A NAME="toc1.2">1.2</A> <A HREF="#ss1.2">Future Plans: You Can Help</A>
|
|
<LI><A NAME="toc1.3">1.3</A> <A HREF="#ss1.3">New Versions of this HOWTO</A>
|
|
<LI><A NAME="toc1.4">1.4</A> <A HREF="#ss1.4">Related HOWTOs </A>
|
|
<LI><A NAME="toc1.5">1.5</A> <A HREF="#ss1.5">Terminology Used in this Document</A>
|
|
<LI><A NAME="toc1.6">1.6</A> <A HREF="#ss1.6">What is a Terminal ?</A>
|
|
<LI><A NAME="toc1.7">1.7</A> <A HREF="#ss1.7">Real Text Terminals</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc2">2.</A> <A HREF="#s2">Types of Terminals</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc2.1">2.1</A> <A HREF="#ss2.1">Dumb Terminals</A>
|
|
<LI><A NAME="toc2.2">2.2</A> <A HREF="#ss2.2">Text Terminals</A>
|
|
<LI><A NAME="toc2.3">2.3</A> <A HREF="#ss2.3">Graphic GUI Capabilities of Text Terminals </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc3">3.</A> <A HREF="#s3">Thin Clients Terminals </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc3.1">3.1</A> <A HREF="#ss3.1">Introduction </A>
|
|
<LI><A NAME="toc3.2">3.2</A> <A HREF="#ss3.2">MS Window terminals</A>
|
|
<LI><A NAME="toc3.3">3.3</A> <A HREF="#ss3.3">Network computers (NC's) </A>
|
|
<LI><A NAME="toc3.4">3.4</A> <A HREF="#ss3.4">Thin clients and NCs under Linux </A>
|
|
<LI><A NAME="toc3.5">3.5</A> <A HREF="#ss3.5">Hardware hookups </A>
|
|
<LI><A NAME="toc3.6">3.6</A> <A HREF="#ss3.6">History and the future</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc4">4.</A> <A HREF="#s4">Quick Text-Terminal Install </A></H2>
|
|
|
|
<P>
|
|
<H2><A NAME="toc5">5.</A> <A HREF="#s5">Why Use a Terminal ?</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc5.1">5.1</A> <A HREF="#ss5.1">Intro to Why Use a Terminal </A>
|
|
<LI><A NAME="toc5.2">5.2</A> <A HREF="#ss5.2">Lower Hardware Costs ? </A>
|
|
<LI><A NAME="toc5.3">5.3</A> <A HREF="#ss5.3">Control of Software </A>
|
|
<LI><A NAME="toc5.4">5.4</A> <A HREF="#ss5.4">Hardware Upgrades </A>
|
|
<LI><A NAME="toc5.5">5.5</A> <A HREF="#ss5.5">Other Advantages of Terminals </A>
|
|
<LI><A NAME="toc5.6">5.6</A> <A HREF="#ss5.6">Major Disadvantages of Text Terminals </A>
|
|
<LI><A NAME="toc5.7">5.7</A> <A HREF="#ss5.7">Major Disadvantages of All Terminals </A>
|
|
<LI><A NAME="toc5.8">5.8</A> <A HREF="#ss5.8">Are Text Terminals Obsolete ? </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc6">6.</A> <A HREF="#s6">Overview of How Text Terminals Work (in Linux) </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc6.1">6.1</A> <A HREF="#ss6.1">Device Names </A>
|
|
<LI><A NAME="toc6.2">6.2</A> <A HREF="#ss6.2">Login/Logout </A>
|
|
<LI><A NAME="toc6.3">6.3</A> <A HREF="#ss6.3">Half/Full Duplex </A>
|
|
<LI><A NAME="toc6.4">6.4</A> <A HREF="#ss6.4">Terminal Memory </A>
|
|
<LI><A NAME="toc6.5">6.5</A> <A HREF="#ss6.5">Commands for the Terminal </A>
|
|
<LI><A NAME="toc6.6">6.6</A> <A HREF="#ss6.6">Lack of Standardization Solved by Terminfo </A>
|
|
<LI><A NAME="toc6.7">6.7</A> <A HREF="#ss6.7">The Interface </A>
|
|
<LI><A NAME="toc6.8">6.8</A> <A HREF="#ss6.8">Emulation</A>
|
|
<LI><A NAME="toc6.9">6.9</A> <A HREF="#ss6.9">The Console</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc7">7.</A> <A HREF="#s7">Terminal Special Files such as /dev/tty </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc7.1">7.1</A> <A HREF="#ss7.1">Serial Port Terminals </A>
|
|
<LI><A NAME="toc7.2">7.2</A> <A HREF="#ss7.2">Pseudo Terminals</A>
|
|
<LI><A NAME="toc7.3">7.3</A> <A HREF="#ss7.3">The Controlling Terminal /dev/tty </A>
|
|
<LI><A NAME="toc7.4">7.4</A> <A HREF="#ss7.4">/dev/ttyIN "Terminals" </A>
|
|
<LI><A NAME="toc7.5">7.5</A> <A HREF="#ss7.5">The Console: ttyN or vc/N</A>
|
|
<LI><A NAME="toc7.6">7.6</A> <A HREF="#ss7.6">Creating a Device with "mknod" </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc8">8.</A> <A HREF="#s8">Some Details on How Terminals Work </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc8.1">8.1</A> <A HREF="#ss8.1">Terminal Memory Details </A>
|
|
<LI><A NAME="toc8.2">8.2</A> <A HREF="#ss8.2">Early Terminals </A>
|
|
<LI><A NAME="toc8.3">8.3</A> <A HREF="#ss8.3">Escape Sequences and Control Codes (intro) </A>
|
|
<LI><A NAME="toc8.4">8.4</A> <A HREF="#ss8.4">Display Attributes & Magic Cookies </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc9">9.</A> <A HREF="#s9">Special Features/Types of Some Terminals</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc9.1">9.1</A> <A HREF="#ss9.1">Terminal Uses a PC Monitor</A>
|
|
<LI><A NAME="toc9.2">9.2</A> <A HREF="#ss9.2">Color </A>
|
|
<LI><A NAME="toc9.3">9.3</A> <A HREF="#ss9.3">Multiple Sessions </A>
|
|
<LI><A NAME="toc9.4">9.4</A> <A HREF="#ss9.4">Printer/Auxiliary Port </A>
|
|
<LI><A NAME="toc9.5">9.5</A> <A HREF="#ss9.5">Pages </A>
|
|
<LI><A NAME="toc9.6">9.6</A> <A HREF="#ss9.6">Character-Sets </A>
|
|
<LI><A NAME="toc9.7">9.7</A> <A HREF="#ss9.7">Fonts</A>
|
|
<LI><A NAME="toc9.8">9.8</A> <A HREF="#ss9.8">Keyboards & Special Keys</A>
|
|
<LI><A NAME="toc9.9">9.9</A> <A HREF="#ss9.9">Mouse</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc10">10.</A> <A HREF="#s10">Terminal Emulation (including the Console) </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc10.1">10.1</A> <A HREF="#ss10.1">Intro to Terminal Emulation</A>
|
|
<LI><A NAME="toc10.2">10.2</A> <A HREF="#ss10.2">Don't Try to Use TERM Variable for Emulation</A>
|
|
<LI><A NAME="toc10.3">10.3</A> <A HREF="#ss10.3">Serial Communication programs </A>
|
|
<LI><A NAME="toc10.4">10.4</A> <A HREF="#ss10.4">Testing Terminal Emulation</A>
|
|
<LI><A NAME="toc10.5">10.5</A> <A HREF="#ss10.5">The Linux Console </A>
|
|
<LI><A NAME="toc10.6">10.6</A> <A HREF="#ss10.6">Emulation Software</A>
|
|
<LI><A NAME="toc10.7">10.7</A> <A HREF="#ss10.7">Colors on Emulated Terminals </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc11">11.</A> <A HREF="#s11">Flow Control (Handshaking) </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc11.1">11.1</A> <A HREF="#ss11.1">Why Is Flow Control Needed ?</A>
|
|
<LI><A NAME="toc11.2">11.2</A> <A HREF="#ss11.2">Padding </A>
|
|
<LI><A NAME="toc11.3">11.3</A> <A HREF="#ss11.3">Overrunning a Serial Port</A>
|
|
<LI><A NAME="toc11.4">11.4</A> <A HREF="#ss11.4">Stop Sending</A>
|
|
<LI><A NAME="toc11.5">11.5</A> <A HREF="#ss11.5">Keyboard Lock </A>
|
|
<LI><A NAME="toc11.6">11.6</A> <A HREF="#ss11.6">Resume Sending</A>
|
|
<LI><A NAME="toc11.7">11.7</A> <A HREF="#ss11.7">Hardware Flow Control (RTS/CTS etc.) </A>
|
|
<LI><A NAME="toc11.8">11.8</A> <A HREF="#ss11.8">Is Hardware Flow Control Done by Hardware ?</A>
|
|
<LI><A NAME="toc11.9">11.9</A> <A HREF="#ss11.9">Obsolete ?? ETX/ACK or ENQ/ACK Flow Control</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc12">12.</A> <A HREF="#s12">Physical Connection </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc12.1">12.1</A> <A HREF="#ss12.1">Introduction</A>
|
|
<LI><A NAME="toc12.2">12.2</A> <A HREF="#ss12.2">Multiport I/O Cards (Adapters)</A>
|
|
<LI><A NAME="toc12.3">12.3</A> <A HREF="#ss12.3">Direct Serial Cable Connection.</A>
|
|
<LI><A NAME="toc12.4">12.4</A> <A HREF="#ss12.4">Modem Connection</A>
|
|
<LI><A NAME="toc12.5">12.5</A> <A HREF="#ss12.5">Telnet and ssh</A>
|
|
<LI><A NAME="toc12.6">12.6</A> <A HREF="#ss12.6">Terminal Server Connection</A>
|
|
<LI><A NAME="toc12.7">12.7</A> <A HREF="#ss12.7">Connector and Adapter Types</A>
|
|
<LI><A NAME="toc12.8">12.8</A> <A HREF="#ss12.8">Making or Modifying a Cable</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc13">13.</A> <A HREF="#s13">Set-Up (Configure) in General </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc13.1">13.1</A> <A HREF="#ss13.1">Intro to Set-Up</A>
|
|
<LI><A NAME="toc13.2">13.2</A> <A HREF="#ss13.2">Terminal Set-Up (Configure) Overview </A>
|
|
<LI><A NAME="toc13.3">13.3</A> <A HREF="#ss13.3">Computer Set-Up (Configure) Overview</A>
|
|
<LI><A NAME="toc13.4">13.4</A> <A HREF="#ss13.4">Many Options</A>
|
|
<LI><A NAME="toc13.5">13.5</A> <A HREF="#ss13.5">Communication Interface Options </A>
|
|
<LI><A NAME="toc13.6">13.6</A> <A HREF="#ss13.6">Quick Attempt</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc14">14.</A> <A HREF="#s14">Terminal Set-Up (Configure) Details </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc14.1">14.1</A> <A HREF="#ss14.1">Send Escape Sequences to the Terminal</A>
|
|
<LI><A NAME="toc14.2">14.2</A> <A HREF="#ss14.2">Older Terminals Set-Up</A>
|
|
<LI><A NAME="toc14.3">14.3</A> <A HREF="#ss14.3">Getting Into Set-Up (Configuration) Mode </A>
|
|
<LI><A NAME="toc14.4">14.4</A> <A HREF="#ss14.4">Communication Options</A>
|
|
<LI><A NAME="toc14.5">14.5</A> <A HREF="#ss14.5">Saving the Set-up</A>
|
|
<LI><A NAME="toc14.6">14.6</A> <A HREF="#ss14.6">Set-Up Options/Parameters </A>
|
|
<LI><A NAME="toc14.7">14.7</A> <A HREF="#ss14.7">Emulation {Personality} {{Terminal Modes}}</A>
|
|
<LI><A NAME="toc14.8">14.8</A> <A HREF="#ss14.8">Display Options</A>
|
|
<LI><A NAME="toc14.9">14.9</A> <A HREF="#ss14.9">Page Related Options</A>
|
|
<LI><A NAME="toc14.10">14.10</A> <A HREF="#ss14.10">Reporting and Answerback</A>
|
|
<LI><A NAME="toc14.11">14.11</A> <A HREF="#ss14.11">Keyboard Options</A>
|
|
<LI><A NAME="toc14.12">14.12</A> <A HREF="#ss14.12">Meaning of Received Control Codes</A>
|
|
<LI><A NAME="toc14.13">14.13</A> <A HREF="#ss14.13">Where New Text Goes</A>
|
|
<LI><A NAME="toc14.14">14.14</A> <A HREF="#ss14.14">Function Keys </A>
|
|
<LI><A NAME="toc14.15">14.15</A> <A HREF="#ss14.15">Block Mode Options</A>
|
|
<LI><A NAME="toc14.16">14.16</A> <A HREF="#ss14.16">Locks</A>
|
|
<LI><A NAME="toc14.17">14.17</A> <A HREF="#ss14.17">Screen Saver {Scrn Saver}</A>
|
|
<LI><A NAME="toc14.18">14.18</A> <A HREF="#ss14.18">Printer</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc15">15.</A> <A HREF="#s15">Computer Set-Up (Configure) Details </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc15.1">15.1</A> <A HREF="#ss15.1">Getty (used in /etc/inittab) </A>
|
|
<LI><A NAME="toc15.2">15.2</A> <A HREF="#ss15.2">Stty & Setserial </A>
|
|
<LI><A NAME="toc15.3">15.3</A> <A HREF="#ss15.3">Setserial </A>
|
|
<LI><A NAME="toc15.4">15.4</A> <A HREF="#ss15.4">Stty </A>
|
|
<LI><A NAME="toc15.5">15.5</A> <A HREF="#ss15.5">Terminfo & Termcap (brief) </A>
|
|
<LI><A NAME="toc15.6">15.6</A> <A HREF="#ss15.6">Setting TERM and TERMINFO</A>
|
|
<LI><A NAME="toc15.7">15.7</A> <A HREF="#ss15.7">Rarely Needed /etc/ttytype File</A>
|
|
<LI><A NAME="toc15.8">15.8</A> <A HREF="#ss15.8">Login Restrictions </A>
|
|
<LI><A NAME="toc15.9">15.9</A> <A HREF="#ss15.9">Run Command Only If TERM=my_term_type</A>
|
|
<LI><A NAME="toc15.10">15.10</A> <A HREF="#ss15.10">Character Mapping: mapchan </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc16">16.</A> <A HREF="#s16">Terminfo and Termcap (detailed) </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc16.1">16.1</A> <A HREF="#ss16.1">Intro to Terminfo</A>
|
|
<LI><A NAME="toc16.2">16.2</A> <A HREF="#ss16.2">Terminfo Database </A>
|
|
<LI><A NAME="toc16.3">16.3</A> <A HREF="#ss16.3">Bugs in Existing Terminfo Files (and Hardware)</A>
|
|
<LI><A NAME="toc16.4">16.4</A> <A HREF="#ss16.4">Modifying Terminfo Files</A>
|
|
<LI><A NAME="toc16.5">16.5</A> <A HREF="#ss16.5">Init String </A>
|
|
<LI><A NAME="toc16.6">16.6</A> <A HREF="#ss16.6">TERM Variable </A>
|
|
<LI><A NAME="toc16.7">16.7</A> <A HREF="#ss16.7">Terminfo/Termcap Documents </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc17">17.</A> <A HREF="#s17">Using the Terminal</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc17.1">17.1</A> <A HREF="#ss17.1">Intro to Using the Terminal</A>
|
|
<LI><A NAME="toc17.2">17.2</A> <A HREF="#ss17.2">Starting Up the Terminal</A>
|
|
<LI><A NAME="toc17.3">17.3</A> <A HREF="#ss17.3">Terminal (Serial) Device Driver</A>
|
|
<LI><A NAME="toc17.4">17.4</A> <A HREF="#ss17.4">Problems with Editors</A>
|
|
<LI><A NAME="toc17.5">17.5</A> <A HREF="#ss17.5">Problem with Slow Scrolling </A>
|
|
<LI><A NAME="toc17.6">17.6</A> <A HREF="#ss17.6">Bugs in Bash ? </A>
|
|
<LI><A NAME="toc17.7">17.7</A> <A HREF="#ss17.7">Color ls Corruption</A>
|
|
<LI><A NAME="toc17.8">17.8</A> <A HREF="#ss17.8">Display Freezes (hung terminal) </A>
|
|
<LI><A NAME="toc17.9">17.9</A> <A HREF="#ss17.9">Corrupted Terminal Interface </A>
|
|
<LI><A NAME="toc17.10">17.10</A> <A HREF="#ss17.10">Special (Control) Characters </A>
|
|
<LI><A NAME="toc17.11">17.11</A> <A HREF="#ss17.11">Viewing Latin1 Files on a non-Latin1 terminal</A>
|
|
<LI><A NAME="toc17.12">17.12</A> <A HREF="#ss17.12">Eliminating Overstriking in Files</A>
|
|
<LI><A NAME="toc17.13">17.13</A> <A HREF="#ss17.13">Inspecting the Interface</A>
|
|
<LI><A NAME="toc17.14">17.14</A> <A HREF="#ss17.14">Changing the Terminal Settings </A>
|
|
<LI><A NAME="toc17.15">17.15</A> <A HREF="#ss17.15">Multiple Sessions</A>
|
|
<LI><A NAME="toc17.16">17.16</A> <A HREF="#ss17.16">Logging Out</A>
|
|
<LI><A NAME="toc17.17">17.17</A> <A HREF="#ss17.17">Chatting between Terminals, Spying</A>
|
|
<LI><A NAME="toc17.18">17.18</A> <A HREF="#ss17.18">Sharing the Serial Port</A>
|
|
<LI><A NAME="toc17.19">17.19</A> <A HREF="#ss17.19">Browsers for Text-Terminals</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc18">18.</A> <A HREF="#s18">Special Uses for a Terminal</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc18.1">18.1</A> <A HREF="#ss18.1">Make a Serial Terminal the Console </A>
|
|
<LI><A NAME="toc18.2">18.2</A> <A HREF="#ss18.2">Run Linux without a Monitor</A>
|
|
<LI><A NAME="toc18.3">18.3</A> <A HREF="#ss18.3">Use a Keyboardless Terminal as the Monitor </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc19">19.</A> <A HREF="#s19">Trouble-Shooting </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc19.1">19.1</A> <A HREF="#ss19.1">Terminal Was Working OK </A>
|
|
<LI><A NAME="toc19.2">19.2</A> <A HREF="#ss19.2">Terminal Newly Installed </A>
|
|
<LI><A NAME="toc19.3">19.3</A> <A HREF="#ss19.3">Is the Terminal OK ? </A>
|
|
<LI><A NAME="toc19.4">19.4</A> <A HREF="#ss19.4">Missing Text </A>
|
|
<LI><A NAME="toc19.5">19.5</A> <A HREF="#ss19.5">All Keys Work Erratically; Must Hit a Key a Few Times</A>
|
|
<LI><A NAME="toc19.6">19.6</A> <A HREF="#ss19.6">... respawning too fast: disabled for 5 minutes</A>
|
|
<LI><A NAME="toc19.7">19.7</A> <A HREF="#ss19.7">Fails Just After Login </A>
|
|
<LI><A NAME="toc19.8">19.8</A> <A HREF="#ss19.8">Can't Login </A>
|
|
<LI><A NAME="toc19.9">19.9</A> <A HREF="#ss19.9">Garbled Login Prompt </A>
|
|
<LI><A NAME="toc19.10">19.10</A> <A HREF="#ss19.10">No Login Prompt </A>
|
|
<LI><A NAME="toc19.11">19.11</A> <A HREF="#ss19.11">Displays Foreign/Weird Characters/Symbols</A>
|
|
<LI><A NAME="toc19.12">19.12</A> <A HREF="#ss19.12">Displays Escape Sequences </A>
|
|
<LI><A NAME="toc19.13">19.13</A> <A HREF="#ss19.13">Slow: pauses of several seconds between bursts of characters</A>
|
|
<LI><A NAME="toc19.14">19.14</A> <A HREF="#ss19.14">Cursor Jumps </A>
|
|
<LI><A NAME="toc19.15">19.15</A> <A HREF="#ss19.15">Terminal doesn't scroll </A>
|
|
<LI><A NAME="toc19.16">19.16</A> <A HREF="#ss19.16">Serial Monitoring/Diagnostics </A>
|
|
<LI><A NAME="toc19.17">19.17</A> <A HREF="#ss19.17">Local Mode </A>
|
|
<LI><A NAME="toc19.18">19.18</A> <A HREF="#ss19.18">Serial Electrical Test Equipment </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc20">20.</A> <A HREF="#s20">Repair & Diagnose </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc20.1">20.1</A> <A HREF="#ss20.1">Repair Books & Websites </A>
|
|
<LI><A NAME="toc20.2">20.2</A> <A HREF="#ss20.2">Safety</A>
|
|
<LI><A NAME="toc20.3">20.3</A> <A HREF="#ss20.3">Appearance of Display</A>
|
|
<LI><A NAME="toc20.4">20.4</A> <A HREF="#ss20.4">Diagnose</A>
|
|
<LI><A NAME="toc20.5">20.5</A> <A HREF="#ss20.5">Detective work</A>
|
|
<LI><A NAME="toc20.6">20.6</A> <A HREF="#ss20.6">Error Messages on the Screen</A>
|
|
<LI><A NAME="toc20.7">20.7</A> <A HREF="#ss20.7">Capacitors</A>
|
|
<LI><A NAME="toc20.8">20.8</A> <A HREF="#ss20.8">Keyboards </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc21">21.</A> <A HREF="#s21">Appendix A: General</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc21.1">21.1</A> <A HREF="#ss21.1">List of Linux Terminal Commands</A>
|
|
<LI><A NAME="toc21.2">21.2</A> <A HREF="#ss21.2">The Internet and Books</A>
|
|
<LI><A NAME="toc21.3">21.3</A> <A HREF="#ss21.3">Non-Linux OSs </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc22">22.</A> <A HREF="#s22">Appendix B: Escape Sequence Commands Terminology </A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc22.1">22.1</A> <A HREF="#ss22.1">Esc Sequence Lists </A>
|
|
<LI><A NAME="toc22.2">22.2</A> <A HREF="#ss22.2">8-bit Control Codes</A>
|
|
<LI><A NAME="toc22.3">22.3</A> <A HREF="#ss22.3">Printer Esc </A>
|
|
<LI><A NAME="toc22.4">22.4</A> <A HREF="#ss22.4">Reports</A>
|
|
<LI><A NAME="toc22.5">22.5</A> <A HREF="#ss22.5">Cursor Movements</A>
|
|
<LI><A NAME="toc22.6">22.6</A> <A HREF="#ss22.6">Pages (definition) </A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc23">23.</A> <A HREF="#s23">Appendix C: Serial Communications on EIA-232 (RS-232)</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc23.1">23.1</A> <A HREF="#ss23.1">Intro to Serial Communication</A>
|
|
<LI><A NAME="toc23.2">23.2</A> <A HREF="#ss23.2">Voltages</A>
|
|
<LI><A NAME="toc23.3">23.3</A> <A HREF="#ss23.3">Parity Explained </A>
|
|
<LI><A NAME="toc23.4">23.4</A> <A HREF="#ss23.4">Forming a Byte (Framing)</A>
|
|
<LI><A NAME="toc23.5">23.5</A> <A HREF="#ss23.5">Limitations of EIA-232</A>
|
|
<LI><A NAME="toc23.6">23.6</A> <A HREF="#ss23.6">Synchronization & Synchronous </A>
|
|
<LI><A NAME="toc23.7">23.7</A> <A HREF="#ss23.7">Block Mode </A>
|
|
<LI><A NAME="toc23.8">23.8</A> <A HREF="#ss23.8">EIA-232 (RS-232) Books </A>
|
|
<LI><A NAME="toc23.9">23.9</A> <A HREF="#ss23.9">Serial Software</A>
|
|
</UL>
|
|
<P>
|
|
<H2><A NAME="toc24">24.</A> <A HREF="#s24">Appendix D: Notes by Brand/Model</A></H2>
|
|
|
|
<UL>
|
|
<LI><A NAME="toc24.1">24.1</A> <A HREF="#ss24.1">Adds</A>
|
|
<LI><A NAME="toc24.2">24.2</A> <A HREF="#ss24.2">CIT</A>
|
|
<LI><A NAME="toc24.3">24.3</A> <A HREF="#ss24.3">IBM Terminals </A>
|
|
<LI><A NAME="toc24.4">24.4</A> <A HREF="#ss24.4">Teletypes </A>
|
|
<LI><A NAME="toc24.5">24.5</A> <A HREF="#ss24.5">VT (originally DEC, now Boundless) </A>
|
|
<LI><A NAME="toc24.6">24.6</A> <A HREF="#ss24.6">Links</A>
|
|
<LI><A NAME="toc24.7">24.7</A> <A HREF="#ss24.7">Qume</A>
|
|
<LI><A NAME="toc24.8">24.8</A> <A HREF="#ss24.8">Wyse Terminals </A>
|
|
</UL>
|
|
<HR>
|
|
<H2><A NAME="intro"></A> <A NAME="s1">1.</A> <A HREF="Text-Terminal-HOWTO.html#toc1">Introduction </A></H2>
|
|
|
|
<P> For a quick attempt to install a text-terminal see
|
|
<A HREF="#quick_install">Quick Install</A>.</P>
|
|
|
|
<H2><A NAME="ss1.1">1.1</A> <A HREF="Text-Terminal-HOWTO.html#toc1.1">Copyright, Trademarks, Disclaimer, & Credits</A>
|
|
</H2>
|
|
|
|
<H3>Copyright</H3>
|
|
|
|
<P> Copyright 1998-2010 by David S. Lawyer.
|
|
<A HREF="mailto:dave@lafn.org">mailto:dave@lafn.org</A></P>
|
|
<P>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:</P>
|
|
<P>
|
|
<OL>
|
|
<LI> 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.</LI>
|
|
<LI>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.</LI>
|
|
<LI>Give due credit to previous authors and major contributors.</LI>
|
|
</OL>
|
|
</P>
|
|
<P>If you're considering making a derived work other than a
|
|
translation, it's requested that you discuss your plans with the
|
|
current maintainer.</P>
|
|
|
|
<H3>Disclaimer</H3>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H3>Trademarks.</H3>
|
|
|
|
<P> 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. </P>
|
|
|
|
|
|
<H3>Credits</H3>
|
|
|
|
<P>
|
|
Greg Hankin's Serial-HOWTO v.1.11 (1997) section "How Do I Set Up A
|
|
Terminal Connected To My PC?" was incorporated into v1.00 at various
|
|
places (with Greg's permission). v1.09 of Text-Terminal-HOWTO had
|
|
about 25 changes (and error corrections) suggested by Alessandro
|
|
Rubini. For v1.26 I fixed about 25 typos, etc. found by Alain
|
|
Cochard. Jeremy Spykerman told me about using a keyboardless terminal
|
|
as a console for a monitorless PC (using ttysnoop). Numerous other
|
|
people have made a suggestion or two or found a few typos. Thanks.</P>
|
|
|
|
<H2><A NAME="ss1.2">1.2</A> <A HREF="Text-Terminal-HOWTO.html#toc1.2">Future Plans: You Can Help</A>
|
|
</H2>
|
|
|
|
<P>The author is looking for someone to take over maintaining this
|
|
howto. Since real text terminals are pretty much obsolete, there is not
|
|
a lot of work to do except that links sometimes disappear and
|
|
automatically finding devices such a dumb terminals on a serial port may
|
|
not work right. One project is to rewrite this howto oriented towards
|
|
text-terminal emulation with the command line interface. Another
|
|
project would be to start with the brief overview of GUI terminals in
|
|
this HOWTO and create a new and up-to-date HOWTO on thin clients or the
|
|
like.</P>
|
|
<P>Please let me know of any errors in facts, opinions, logic,
|
|
spelling, grammar, clarity, links, etc. But first, if the date is
|
|
over a couple of years old, check to see that you have the latest version.
|
|
Please send me any info that you think belongs in this document.</P>
|
|
<P>In order to fully utilize all the features of a certain real terminal,
|
|
one needs the terminal manuals that came with the terminal when it was
|
|
new. If you don't have a manual, this HOWTO may be of some help. One
|
|
way to have solved this problem would be for terminal manufacturers to
|
|
put their manuals on the Internet but they never did. Except that Wyse
|
|
made available some of their user manuals and someone scanned old VT-100
|
|
manuals. </P>
|
|
|
|
<H2><A NAME="ss1.3">1.3</A> <A HREF="Text-Terminal-HOWTO.html#toc1.3">New Versions of this HOWTO</A>
|
|
</H2>
|
|
|
|
<P> New versions of the Text-Terminal-HOWTO should be released every
|
|
couple of years. To get the latest version go to an LDP mirror sites (see:
|
|
<A HREF="http://www.tldp.org/mirrors.html">http://www.tldp.org/mirrors.html</A>). To quickly check the date
|
|
of the latest version look at
|
|
<A HREF="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Text-Terminal-HOWTO.html">Text-Terminal-HOWTO.html</A>. The version your are currently
|
|
reading is: v1.43 March 2013 . </P>
|
|
<P>For a full revision history going back to the first version in
|
|
1998 see the source file (in linuxdoc format):
|
|
<A HREF="http://cvs.tldp.org/go.to/LDP/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml?view=markup">(cvs) Text-Terminal-HOWTO.sgml</A></P>
|
|
<P>
|
|
<UL>
|
|
<LI> v1.43 Mar. 2013 Putty's pterm emulation. Cleanup. Shuford's website
|
|
now defunct. Looking for a new maintainer. Wyse data missing from
|
|
Internet. Rewrote abstract. Clarity in stty raw problem. Links to Wikipedia.</LI>
|
|
<LI>v1.42 Jan. 2010 PuTTY serial terminal emulator, cutecom (dumb
|
|
emulator), colors, links to wikipedia, Boundless still selling
|
|
terminals, small footprint terminals, link to art. on text browsers.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="related_howtos"></A> <A NAME="ss1.4">1.4</A> <A HREF="Text-Terminal-HOWTO.html#toc1.4">Related HOWTOs </A>
|
|
</H2>
|
|
|
|
<P> Go to the nearest mirror site (per above) to get HOWTOs.
|
|
<UL>
|
|
<LI> 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.</LI>
|
|
<LI> NCURSES-Programming-HOWTO</LI>
|
|
<LI> MacTerminal mini-HOWTO</LI>
|
|
<LI> Modem-HOWTO</LI>
|
|
<LI> Serial-Programming-HOWTO</LI>
|
|
<LI> NC mini-HOWTO</LI>
|
|
<LI> NCD-X-Terminal mini-HOWTO</LI>
|
|
<LI> XDM-and-X-Terminal mini-HOWTO</LI>
|
|
<LI> Connecting-X-Terminals-to-Linux-Mini-HOWTO</LI>
|
|
<LI> NCD-HOWTO</LI>
|
|
<LI> Thinclient-HOWTO</LI>
|
|
<LI> Xterminals-HOWTO </LI>
|
|
<LI> Xterm-Title-HOWTO (only for changing the title of a window)</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss1.5">1.5</A> <A HREF="Text-Terminal-HOWTO.html#toc1.5">Terminology Used in this Document</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="ss1.6">1.6</A> <A HREF="Text-Terminal-HOWTO.html#toc1.6">What is a Terminal ?</A>
|
|
</H2>
|
|
|
|
<P> A terminal consists of a screen and keyboard that one uses to
|
|
communicate remotely with a computer (the host). One uses it almost
|
|
like it was a personal computer but the terminal is remote from its
|
|
host computer that it communicates with (on the other side of the room
|
|
or even on the other side of the world). Programs execute on the host
|
|
computer but the results display on the terminal screen. Originally
|
|
terminals were stand-alone devices with no computational ability and
|
|
thus they were once much cheaper in cost than computers. They had no
|
|
pictures or audio, but could only display text and were thus called
|
|
"text terminals". Today, the cost of PC computers is so low that one
|
|
may use a PC like a text terminal by running a software program to
|
|
make it behave like an old text terminal. You formerly found real
|
|
text terminals at libraries and schools.</P>
|
|
|
|
<H2><A NAME="ss1.7">1.7</A> <A HREF="Text-Terminal-HOWTO.html#toc1.7">Real Text Terminals</A>
|
|
</H2>
|
|
|
|
<P> In the olden days of mainframes, from the mid 1970's to the mid
|
|
1980's, most communication with large computers was done by people
|
|
sitting in front of real text-terminals. And in the 1970's, before
|
|
the advent of personal computers, it was the only way to interactively
|
|
communicate with any computer. These real text-terminals were neither
|
|
computers nor emulated text-terminals. They consisted only of a
|
|
screen, keyboard, and only enough memory to store a screenfull or so
|
|
of text (a few kilobytes). Users typed in programs, ran programs,
|
|
wrote documents, issued printing commands, etc. A cable connected the
|
|
terminal to the computer (often indirectly). It was called a terminal
|
|
since it was located at the terminal end of this cable. Some
|
|
text-terminals were called "graphic" but the resolution was poor, the
|
|
speed slow, and little software was available to support such
|
|
graphics.</P>
|
|
<P>Today, real terminals are becoming rarities for most all computer
|
|
users. But there is still some specialized uses for them as
|
|
point-of-sale devices and for access to mainframes and servers where
|
|
graphics and pictures are not needed. However, if a text terminal is
|
|
needed people will sometimes use a personal computer to emulate a
|
|
terminal.</P>
|
|
<P>Almost everyone who uses Linux also uses terminal emulation. When you are
|
|
not using an X Window GUI at a Linux PC, you are likely using a text
|
|
interface (virtual terminal). It's also called a "command line
|
|
interface". In X Window one can also get a command line interface
|
|
using one or more terminal windows by using an x-terminal-emulator
|
|
with names such as xterm, gnome-terminal, or konsole (KDE). All these
|
|
use software to emulate a real terminal. However in these cases, one
|
|
doesn't need most of the information provided by this HOWTO since such
|
|
emulation is automatically set up for the user. However if one
|
|
emulates a terminal using a software program and then connects that
|
|
emulated terminal to another computer via a serial port cable, then
|
|
this HOWTO should be more useful (provided your PC has a serial port
|
|
on it --almost all recent PCs made after 2009 didn't have them anymore).</P>
|
|
<P>A real text-terminal is different from a monitor or
|
|
x-terminal-emulator because the simple character images that get
|
|
displayed on the text-terminal are stored right inside the terminal in
|
|
it's memory. For a monitor or x-terminal-emulator, the images are
|
|
stored in the video card of the PC and/or in the PC's memory itself.
|
|
The text-terminal's keyboard plugs into the terminal and is part
|
|
of the terminal while a PC's keyboard plugs into the computer.</P>
|
|
<P>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.</P>
|
|
<P>In network client-server terminology, one might think that a real
|
|
terminal is the client and that the host computer is the server. The
|
|
terminal has been called a "thin client" by some. But it is not
|
|
actually a "client" nor is the host a "server". The only "service"
|
|
the host provides is to receive every letter typed at the keyboard and
|
|
react to this just like a computer would if you typed at its own
|
|
keyboard. The terminal is like a "window" into the computer just like
|
|
a monitor (and keyboard) are. You may have already used virtual
|
|
terminals in Linux (by pressing Left Alt-F2, etc.). A real terminal
|
|
is just like running such a virtual terminal but you run it on its own
|
|
terminal screen instead of having to share the monitor screen. In
|
|
contrast to using a virtual terminal at the console (monitor), this
|
|
allows another person to sit at another real terminal and use the same
|
|
computer simultaneously with others. Such multi-user interfaces are
|
|
not "clients" and a server..</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s2">2.</A> <A HREF="Text-Terminal-HOWTO.html#toc2">Types of Terminals</A></H2>
|
|
|
|
<H2><A NAME="ss2.1">2.1</A> <A HREF="Text-Terminal-HOWTO.html#toc2.1">Dumb Terminals</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="ss2.2">2.2</A> <A HREF="Text-Terminal-HOWTO.html#toc2.2">Text Terminals</A>
|
|
</H2>
|
|
|
|
<P> For a text terminal, a 2-way flow of information between the
|
|
computer and the terminal takes place over the cable that connects
|
|
them together. This flow is in bytes (such as ASCII) where each byte
|
|
is an integer that usually represents a printable character. Bytes
|
|
typed at the keyboard go to the host computer and most bytes from the
|
|
computer are displayed on the terminal screen. Special control bytes
|
|
(or sequences of bytes) from the computer tell the terminal where to
|
|
move the cursor to, what to erase, where to begin and end underlining
|
|
and/or blinking and/or bold, etc. There are often hundreds of such
|
|
special coded commands and most real terminals can even change fonts.</P>
|
|
<P>The communication uses characters (letters) encoded using a code chart
|
|
for the character set being used. Usually, the first 128 bytes out of
|
|
256 possible bytes use ASCII codes. Terminals for Unix-like systems,
|
|
normally connect to computers via a cable running between the
|
|
asynchronous serial ports (RS-232-C = EIA-232-D) of the host computer
|
|
and the terminal. Prior to about 2004, most new PCs had serial ports,
|
|
but today (2009) almost no new PCs come with serial ports. Sometimes
|
|
the connection is via modem or terminal server, etc.</P>
|
|
<P>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.</P>
|
|
<P>"Block mode" was used exclusively by old IBM mainframe terminals but
|
|
many modern terminals also have this capability (which is not used
|
|
much). In block mode, the characters you type are temporarily
|
|
retained in the terminal memory (and may possibly be edited by a
|
|
built-in editor at the terminal). Then when one presses the send key
|
|
(or the like) a block of characters (sometimes just a line of
|
|
characters) is sent to the computer all at once. Block mode (as of
|
|
late 1998) is not supported by Linux. See section
|
|
<A HREF="#block">Block Mode</A>.</P>
|
|
|
|
<H2><A NAME="ss2.3">2.3</A> <A HREF="Text-Terminal-HOWTO.html#toc2.3">Graphic GUI Capabilities of Text Terminals </A>
|
|
</H2>
|
|
|
|
<P> While emulated text terminals don't display images, many real text
|
|
terminals can display bit-mapped images, but not in color.
|
|
Unfortunately, the popular image formats used on the Internet are not
|
|
supported. Thus the display of images is seldom used. The protocols
|
|
for terminal graphics include: Tektronix Vector Graphics, ReGIS (DEC),
|
|
Sixel (DEC), and NAPLPS (North American Presentation Level Protocol
|
|
Syntax).</P>
|
|
<P>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.</P>
|
|
|
|
<H3><A NAME="vector_graphics"></A> Graphics GUI displays </H3>
|
|
|
|
<P> 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
|
|
<A HREF="http://www.cca.org/vector/">http://www.cca.org/vector/</A>. 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).</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s3">3.</A> <A HREF="Text-Terminal-HOWTO.html#toc3">Thin Clients Terminals </A></H2>
|
|
|
|
<H2><A NAME="ss3.1">3.1</A> <A HREF="Text-Terminal-HOWTO.html#toc3.1">Introduction </A>
|
|
</H2>
|
|
|
|
<P> Since "thin clients" are not text terminals, this HOWTO only
|
|
provides a brief overview of them. There are other HOWTOs that cover
|
|
them in more detail but (as of 2010) they are unfortunately not up to
|
|
date. See
|
|
<A HREF="#related_howtos">Related HOWTOs, etc.</A>. Thin
|
|
clients are thin (minimal) client computers that behave something like
|
|
terminals. Since text terminals (except for very old ones) run an
|
|
embedded operating system, they are also like a computer. In contrast
|
|
to text-terminals, thin clients all display a modern high-speed GUI.
|
|
They are dependent on more powerful computers (servers) for their
|
|
operation. </P>
|
|
<P>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".</P>
|
|
<P>Instead of "thin client" they could have been simply called "graphic
|
|
terminals" but promoters of this technology wanted a catchy name to
|
|
get customers to believe that it was perhaps a totally different
|
|
technology. This trend of renaming what is basically just graphic
|
|
terminals (with new features) continues unabated. Some of these names
|
|
are "Virtual Desktop" and "Cloud Computing".</P>
|
|
<P>Thin clients may be created from an ordinary PC by using software or
|
|
may be a stand-alone piece of hardware. But such stand-alone hardware
|
|
may often be just a conventional PC monitor plus a small box for the
|
|
computer part of the hardware. Linux seems to favor the use of PCs as
|
|
clients.</P>
|
|
<P>Some claim that text-terminals are also a type of thin client but they
|
|
are not really since they don't conform to the client-server model.
|
|
However, connecting a terminal via telnet does invoke the
|
|
client-server model in the use of telnet as a means of transport of
|
|
data. But the relation of the text-terminal to it's host is not one
|
|
of client-server. The text-terminal is just another means of access
|
|
to the computer just like the monitor and its keyboard is to access a
|
|
PC. One could apply this same reasoning to a thin client and say that
|
|
the client-server relationship is only for the transport of data.</P>
|
|
<P>Thus a thin client is like a terminal. It has a GUI with a mouse that
|
|
makes it seem like you are using a computer. You are, but that
|
|
computer may be far away and have many other people using it at the
|
|
same time you are. Communication is over a high speed network
|
|
(wireless and/or cable) or even over the Internet. Some thin clients
|
|
can, in addition, emulate a text terminal and have a serial port
|
|
connector for that purpose. Recent ones also have USB interfaces as
|
|
well as ethernet.</P>
|
|
<P>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
|
|
<A HREF="#linux_thin_clients">Thin clients and NCs under Linux</A></P>
|
|
|
|
<H2><A NAME="ss3.2">3.2</A> <A HREF="Text-Terminal-HOWTO.html#toc3.2">MS Window terminals</A>
|
|
</H2>
|
|
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>PCs running Linux can be turned into ICA based client terminals using
|
|
"free" (in price only) proprietary ICA client software from Citrix:
|
|
<A HREF="http://support.citrix.com/article/CTX879408">Installing the Linux Client</A>. 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss3.3">3.3</A> <A HREF="Text-Terminal-HOWTO.html#toc3.3">Network computers (NC's) </A>
|
|
</H2>
|
|
|
|
<P>See
|
|
<A HREF="http://en.wikipedia.org/wiki/Network_Computer">Network Computer - Wikipedia</A> which claims that NC's are
|
|
defunct as a type of hardware, but that NC is used as a synonym for
|
|
"thin client".</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="linux_thin_clients"></A> <A NAME="ss3.4">3.4</A> <A HREF="Text-Terminal-HOWTO.html#toc3.4">Thin clients and NCs under Linux </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="http://www.ltsp.org/">http://www.ltsp.org/</A>. </P>
|
|
<P>"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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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
|
|
<A HREF="#term_emulation">Terminal Emulation</A>.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>There are some Linux HOWTOs for certain brands of NCs:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> JavaStation-HOWTO (by Sun) </LI>
|
|
<LI> NC-HOWTO (IBM NetStation)</LI>
|
|
<LI> NCD HOWTO (NCD-ThinSTAR)</LI>
|
|
<LI> NCD-X-Terminal HOWTO </LI>
|
|
<LI> XDM-and-X-Terminal HOWTO</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss3.5">3.5</A> <A HREF="Text-Terminal-HOWTO.html#toc3.5">Hardware hookups </A>
|
|
</H2>
|
|
|
|
<P> There are 3 different types of hardware arrangements for thin
|
|
clients. The first type just uses a PC computer as a thin client by
|
|
emulating a thin client. It really isn't a thin client but it behaves
|
|
like one. The second type (no longer made ?) looks just like a
|
|
text-terminal. It just looks like a monitor, with a connector for a
|
|
keyboard and another connector for a network cable. It's a dedicated
|
|
thin client and can't be used for anything else. The third type looks
|
|
like a tiny computer. It uses a standard PC monitor and keyboard both
|
|
of which plug into a small box which is a "thin" computer. This box
|
|
provides an interface between the monitor/keyboard and the network.</P>
|
|
|
|
<H2><A NAME="ss3.6">3.6</A> <A HREF="Text-Terminal-HOWTO.html#toc3.6">History and the future</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="quick_install"></A> <A NAME="s4">4.</A> <A HREF="Text-Terminal-HOWTO.html#toc4">Quick Text-Terminal Install </A></H2>
|
|
|
|
<P> This is a quick procedure to install a terminal without going
|
|
through a
|
|
<A HREF="#setup_">Setup</A> 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.</P>
|
|
<P>To install a terminal, first look in <CODE>/etc/termcap</CODE> or
|
|
<CODE>terminfo.src</CODE> to find an entry for it (see
|
|
<A HREF="#termcap2">Terminfo and Termcap (detailed)</A>). Figure out what serial port
|
|
you'll connect it to and what the tty designation is for that port
|
|
e.g. ttyS1, see
|
|
<A HREF="#dev_names">Device Names</A>). As the
|
|
root user, edit <CODE>/etc/inittab</CODE> and add a getty command next to
|
|
the other getty commands. The format of the getty command depends on
|
|
which getty program you use. <CODE>agetty</CODE> (called just <CODE>getty</CODE> in
|
|
the Debian distribution) is the easiest (no configuration file). See
|
|
the "<CODE>info</CODE>" or "<CODE>man</CODE> re <CODE>getty</CODE>. 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
|
|
<A HREF="#flow_control">Flow Control</A>).</P>
|
|
<P>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
|
|
<A HREF="#trouble_shoot">Trouble-Shooting</A>.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s5">5.</A> <A HREF="Text-Terminal-HOWTO.html#toc5">Why Use a Terminal ?</A></H2>
|
|
|
|
<H2><A NAME="ss5.1">5.1</A> <A HREF="Text-Terminal-HOWTO.html#toc5.1">Intro to Why Use a Terminal </A>
|
|
</H2>
|
|
|
|
<P>Many of these arguments apply also to GUI "thin-client" type of
|
|
terminal. The case for such terminals is frequently being made today
|
|
and promoters are devising new slogans and names in an attempt to
|
|
market the modern terminal concept under another name. For example "Cloud Computing". </P>
|
|
<P>PC's are so powerful today that just one PC can often support
|
|
several persons using it at once, especially if they are doing
|
|
low-load tasks such as text editing, data entry, etc. One way to do
|
|
this is to connect a number of terminals to a single PC (or other host
|
|
computer) by modems or direct cable connection. To do this, it's
|
|
usually best to have a multi-user operating system such as Linux so
|
|
that each user at a terminal can use the computer independently. This
|
|
has been called "time sharing" but it's not good terminology today
|
|
since "distributed" computing over a network is also a type of time
|
|
sharing. It might be better described as "centralized" computing.
|
|
But the central computer may be connected to the rest of the world via
|
|
a network so that terminal users may send email, browse the Internet,
|
|
etc. So it's not exactly "centralized" either.</P>
|
|
<P>Prior to about 2000, terminals were seldom used with PC's because the
|
|
popular operating systems used for them (Windows, DOS, and Mac) were
|
|
not multiuser until 1998 (available for MS Windows NT) and previously
|
|
could not support terminals very well. Now that Linux, a multiuser
|
|
operating system, is freely available for PC's, the use of terminals
|
|
with PC's becomes more feasible. While text terminals are not smart
|
|
enough to support the type of graphical user interface (GUI) that most
|
|
computer users today expect, thin client type terminals are.</P>
|
|
|
|
<H2><A NAME="ss5.2">5.2</A> <A HREF="Text-Terminal-HOWTO.html#toc5.2">Lower Hardware Costs ? </A>
|
|
</H2>
|
|
|
|
<P> When Computers (including PCs) were quite expensive, lower
|
|
hardware costs was a significant advantage of using terminals. Today
|
|
with cheap PCs, the cost savings is problematical. I wrote the next
|
|
three paragraphs years ago when PCs were more expensive. They are still
|
|
valid today but of less significance:</P>
|
|
<P>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.</P>
|
|
<P>These savings are substantial. One may roughly estimate (using
|
|
statistical theory) that for 9 persons (8 terminals & 1 console) the
|
|
shared PC only needs only about 3 times as much capacity (in memory,
|
|
disk storage, CPU power, etc.) as a single PC in order to provide the
|
|
same level of service per person. Thus the computational hardware for
|
|
such a shared system should only cost about 1/3 as much per user.
|
|
However, the cost of the display hardware (CRT's, keyboards, video
|
|
electronics, etc.) is about the same for both cases. The terminals
|
|
have the added cost of requiring additional physical cable connectors
|
|
(such as serial ports) at the host computer.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss5.3">5.3</A> <A HREF="Text-Terminal-HOWTO.html#toc5.3">Control of Software </A>
|
|
</H2>
|
|
|
|
<P> For centralized computing, software (and the updates to software)
|
|
only need be installed and configured on one host computer instead of
|
|
several. The person in charge of this computer may control and
|
|
configure the software which is installed on it. This is advantageous
|
|
if the person controlling the host computer does an excellent job and
|
|
knows about the needs and preferences of the other users. Users can
|
|
be restricted in playing games or surfing the Internet, etc.
|
|
Whether or not centralized control is desirable depends on the
|
|
situation. It's in a sense depriving users of their "right" to
|
|
controls what they do with their computer including things that would
|
|
improve their efficiency at work and/or entertain them.</P>
|
|
|
|
<H2><A NAME="ss5.4">5.4</A> <A HREF="Text-Terminal-HOWTO.html#toc5.4">Hardware Upgrades </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="ss5.5">5.5</A> <A HREF="Text-Terminal-HOWTO.html#toc5.5">Other Advantages of Terminals </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> The elimination of noise from fans and disk drives (unless
|
|
you're using a PC to emulate a terminal).</LI>
|
|
<LI> The users of the terminals can share data and files and send
|
|
e-mail to each other. But they could also do this if the used PC on a
|
|
local network or via email over the internet.
|
|
</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss5.6">5.6</A> <A HREF="Text-Terminal-HOWTO.html#toc5.6">Major Disadvantages of Text Terminals </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> For the case of text terminals there is no high-speed graphic
|
|
display (or high resolution graphics) although they can often use
|
|
graphic character sets to draw boxes, etc. This lack limits the
|
|
software that may be used on it.</LI>
|
|
<LI> A detailed display of progress will sometimes greatly increase
|
|
the time taken to do the job. For example, when copying a large
|
|
number of files and displaying the name of each, the terminal may
|
|
only be able to display the full path names of say 30 files per
|
|
second so only 30 files per second will be copied. But the computer
|
|
hardware is capable of copying at a rate many times higher. This
|
|
can often be fixed by using options of application programs for a
|
|
minimal display of progress. See
|
|
<A HREF="#slow_scroll">Problem with Slow Scrolling</A></LI>
|
|
<LI>Most new computers don't have serial ports anymore, making it
|
|
difficult to use them to emulate text terminals that connect over a
|
|
serial line. One could perhaps connect by dialup using an analog
|
|
modem, but with high speed cable or DSL modems, the analog modem is
|
|
becoming obsolete.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss5.7">5.7</A> <A HREF="Text-Terminal-HOWTO.html#toc5.7">Major Disadvantages of All Terminals </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> If the host computer goes down, then no one can use the
|
|
terminals either (unless there is a "standby" host computer to connect
|
|
to).</LI>
|
|
<LI>As compared to a laptop, it's not portable. That is, you can't
|
|
easily take it around with you, unless you have some way of connecting
|
|
to your host computer where ever you go.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss5.8">5.8</A> <A HREF="Text-Terminal-HOWTO.html#toc5.8">Are Text Terminals Obsolete ? </A>
|
|
</H2>
|
|
|
|
<P> Text terminals are technologically obsolete because for a slightly
|
|
higher cost of hardware, one can build a smarter terminal (with the
|
|
same quality of display). This wasn't always the case since around
|
|
1980 memory cost thousands of dollars per megabyte. Today with low
|
|
costs for memory and processors, one could turn a text terminal into a
|
|
GUI graphic terminal for only about a 10% or 20% increase in hardware
|
|
cost.</P>
|
|
<P>Since a PC can emulate a terminal, almost everyone using computers had
|
|
a terminal emulator available until PCs started removing the serial
|
|
port from new models during the 2000-2010 decade. You might think
|
|
that now text terminals would be more in demand since emulating a
|
|
directly connected terminal is only feasible with newer PC's (with no
|
|
serial ports) only if one purchases such ports. But if one wants to
|
|
connect text terminals (including emulated ones) to a PC via the
|
|
serial port they will be out of luck if the Linux PC doesn't have a
|
|
serial port. Thus the disappearing serial port tends to make the text
|
|
terminal even more obsolete.</P>
|
|
<P>The reasons that text terminals are (or were) not fully obsolete are:
|
|
<UL>
|
|
<LI> The resolution of characters on the screen was better on
|
|
monochrome terminals than for cheaper PC monitors in text mode.
|
|
But for high resolution monitors the character resolution is fine.</LI>
|
|
<LI> Some people don't need full screen graphics.</LI>
|
|
<LI> 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.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="overview"></A> <A NAME="s6">6.</A> <A HREF="Text-Terminal-HOWTO.html#toc6">Overview of How Text Terminals Work (in Linux) </A></H2>
|
|
|
|
<P> See also section
|
|
<A HREF="#HowTermsWorkDetail">Some Details on How Terminals Work</A></P>
|
|
|
|
<H2><A NAME="dev_names"></A> <A NAME="ss6.1">6.1</A> <A HREF="Text-Terminal-HOWTO.html#toc6.1">Device Names </A>
|
|
</H2>
|
|
|
|
<P> 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. </P>
|
|
<P>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
|
|
<A HREF="#devices_">Terminal Special Files</A> for
|
|
details on these and related "devices". </P>
|
|
|
|
<H2><A NAME="ss6.2">6.2</A> <A HREF="Text-Terminal-HOWTO.html#toc6.2">Login/Logout </A>
|
|
</H2>
|
|
|
|
<P> When the host computer starts up it runs the program getty. The
|
|
getty program runs the "login" program to log people in. See
|
|
<A HREF="#getty_">Getty (used in /etc/inittab)</A>. A "login:" prompt
|
|
appears on the screen. People at the terminals and/or console log in
|
|
(after giving their passwords) and then have access to the computer.
|
|
When it's time to shut the terminal down, everyone must log off and
|
|
(and power off their terminal). See
|
|
<A HREF="#login_restr">Login Restrictions</A> regarding restricting logins (including allowing the
|
|
root user to log in at terminal).</P>
|
|
|
|
<H2><A NAME="half_duplex"></A> <A NAME="ss6.3">6.3</A> <A HREF="Text-Terminal-HOWTO.html#toc6.3">Half/Full Duplex </A>
|
|
</H2>
|
|
|
|
<P> If one watches someone typing at a terminal, the letters one
|
|
types simultaneously appear on the screen. A naive person might think
|
|
that what one types is being sent directly from the keyboard to the
|
|
screen with a copy going to the computer (half-duplex like, see next
|
|
paragraph). What is usually going on is that what is typed at the
|
|
keyboard is directly sent only to the host computer which in turn
|
|
echoes back to the terminal each character it receives (called
|
|
full-duplex). In some cases (such as passwords or terse editor
|
|
commands) the typed letters are intentionally not echoed back.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss6.4">6.4</A> <A HREF="Text-Terminal-HOWTO.html#toc6.4">Terminal Memory </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#term_mem_detail">Terminal Memory Details</A> for more details.</P>
|
|
|
|
<H2><A NAME="ss6.5">6.5</A> <A HREF="Text-Terminal-HOWTO.html#toc6.5">Commands for the Terminal </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#control_codes">Control Codes</A> (bytes) and
|
|
<A HREF="#esc_seq">escape sequences</A>. 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.</P>
|
|
<P>The
|
|
<A HREF="#early_terms">first terminals</A> 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
|
|
<A HREF="#esc_seq_lists">Esc Sequence List</A></P>
|
|
|
|
<H2><A NAME="ss6.6">6.6</A> <A HREF="Text-Terminal-HOWTO.html#toc6.6">Lack of Standardization Solved by Terminfo </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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
|
|
<A HREF="#termcap2">Termcap and Terminfo (detailed)</A> 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.</P>
|
|
|
|
<H2><A NAME="ss6.7">6.7</A> <A HREF="Text-Terminal-HOWTO.html#toc6.7">The Interface </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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
|
|
<A HREF="#term_conf_details">Terminal Set-Up (Configure) Details</A>). The computer serial port has options also and these
|
|
options must be set up in a compatible way (see
|
|
<A HREF="#comp_conf_details">Computer Set-Up (Configure) Details</A>.</P>
|
|
|
|
<H2><A NAME="ss6.8">6.8</A> <A HREF="Text-Terminal-HOWTO.html#toc6.8">Emulation</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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
|
|
<A HREF="#term_emulation">Terminal Emulation</A>.</P>
|
|
|
|
<H2><A NAME="ss6.9">6.9</A> <A HREF="Text-Terminal-HOWTO.html#toc6.9">The Console</A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#console_dev">The Console</A>. 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
|
|
<A HREF="#term_as_console">Make a Serial Terminal the Console</A>.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="devices_"></A> <A NAME="s7">7.</A> <A HREF="Text-Terminal-HOWTO.html#toc7">Terminal Special Files such as /dev/tty </A></H2>
|
|
|
|
<P> "tty" is an abbreviation for "Teletype". The first terminals were
|
|
Teletypes (like remotely controlled typewriters). See subsection
|
|
<A HREF="#teletype">Teletypes</A>. 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.</P>
|
|
|
|
<H2><A NAME="ss7.1">7.1</A> <A HREF="Text-Terminal-HOWTO.html#toc7.1">Serial Port Terminals </A>
|
|
</H2>
|
|
|
|
<P> 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. </P>
|
|
<P>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).</P>
|
|
|
|
<H2><A NAME="ss7.2">7.2</A> <A HREF="Text-Terminal-HOWTO.html#toc7.2">Pseudo Terminals</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>For a pseudo terminal pair such as ptyp3 and ttyp3, the pty... is the
|
|
master or controlling terminal and the tty... is the slave.</P>
|
|
<P>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).</P>
|
|
<P>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.</P>
|
|
<P>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. </P>
|
|
<P>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.</P>
|
|
<P>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:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y
|
|
CONFIG_LEGACY_PTY_COUNT=256
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss7.3">7.3</A> <A HREF="Text-Terminal-HOWTO.html#toc7.3">The Controlling Terminal /dev/tty </A>
|
|
</H2>
|
|
|
|
<P> /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).</P>
|
|
|
|
<H2><A NAME="ss7.4">7.4</A> <A HREF="Text-Terminal-HOWTO.html#toc7.4">/dev/ttyIN "Terminals" </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="console_dev"></A> <A NAME="ss7.5">7.5</A> <A HREF="Text-Terminal-HOWTO.html#toc7.5">The Console: ttyN or vc/N</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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
|
|
<A HREF="#console_">The Linux Console</A>.</P>
|
|
|
|
<H2><A NAME="ss7.6">7.6</A> <A HREF="Text-Terminal-HOWTO.html#toc7.6">Creating a Device with "mknod" </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<CODE>mknod</CODE> you must know the major and minor device numbers. You
|
|
might be able to infer the numbers you need by using the "<CODE>ls -l</CODE>"
|
|
command in the /dev directory. It will display the major and minor
|
|
numbers of existing special files.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="HowTermsWorkDetail"></A> <A NAME="s8">8.</A> <A HREF="Text-Terminal-HOWTO.html#toc8">Some Details on How Terminals Work </A></H2>
|
|
|
|
<P> If you know almost nothing about terminals, it's suggested that
|
|
you first read
|
|
<A HREF="#intro">Introduction</A> and also read
|
|
<A HREF="#overview">Overview of How Terminals Work</A>.</P>
|
|
|
|
<H2><A NAME="term_mem_detail"></A> <A NAME="ss8.1">8.1</A> <A HREF="Text-Terminal-HOWTO.html#toc8.1">Terminal Memory Details </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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).</P>
|
|
|
|
<H2><A NAME="early_terms"></A> <A NAME="ss8.2">8.2</A> <A HREF="Text-Terminal-HOWTO.html#toc8.2">Early Terminals </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#teletype">Teletypes</A>. 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.</P>
|
|
|
|
<H2><A NAME="ss8.3">8.3</A> <A HREF="Text-Terminal-HOWTO.html#toc8.3">Escape Sequences and Control Codes (intro) </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H3><A NAME="control_codes"></A> Control codes </H3>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H3><A NAME="esc_seq"></A> Escape sequences </H3>
|
|
|
|
<P> 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
|
|
<A HREF="#esc_seq_lists">Esc Sequence List</A> is on the web for some
|
|
terminals, but it's terse.</P>
|
|
<P>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
|
|
<A HREF="#esc_seq_lists">Esc Sequence List</A>. By searching the Internet for one sequence
|
|
(such as ESC[5m) you may come across a long list of them.</P>
|
|
<P>Another way to determine some of them is to find the terminfo entry
|
|
(termcap) for the terminal and mentally decode it. See
|
|
<A HREF="#termcap2">Terminfo and Termcap (detailed)</A> in this document
|
|
and/or the
|
|
<A HREF="#termcap_docs">Termcap Manual</A> 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.</P>
|
|
|
|
<H2><A NAME="display_attributes"></A> <A NAME="ss8.4">8.4</A> <A HREF="Text-Terminal-HOWTO.html#toc8.4">Display Attributes & Magic Cookies </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s9">9.</A> <A HREF="Text-Terminal-HOWTO.html#toc9">Special Features/Types of Some Terminals</A></H2>
|
|
|
|
<H2><A NAME="ss9.1">9.1</A> <A HREF="Text-Terminal-HOWTO.html#toc9.1">Terminal Uses a PC Monitor</A>
|
|
</H2>
|
|
|
|
<P>One may use a PC (including it's monitor) to emulate a terminal.
|
|
But PCs have become so powerful that only a small portion of the PC's
|
|
capacity is utilized to run the emulation. So why not make a tiny PC
|
|
that has low computing capability so it is barely able do the task of
|
|
emulating a terminal. Then call this tiny device a text terminal and
|
|
point out that one must supply and plug in a PC monitor in order to
|
|
use this terminal. Such devices exist and are only about an inch
|
|
high. They are sometimes referred to as small footprint terminals.
|
|
Their advantage is that they are cheap, take up little space, and
|
|
might be able to use surplus monitors that otherwise might be
|
|
discarded.</P>
|
|
|
|
<H2><A NAME="ss9.2">9.2</A> <A HREF="Text-Terminal-HOWTO.html#toc9.2">Color </A>
|
|
</H2>
|
|
|
|
<H3>Emulated text terminals</H3>
|
|
|
|
<P>In contrast to the monochrome or most real text terminals, an
|
|
emulated text terminal usually has colors since it displays on a PC
|
|
color monitor. See
|
|
<A HREF="#colors">Colors on Emulated Terminals</A></P>
|
|
|
|
<H3>Old real text terminal</H3>
|
|
|
|
<P>Some real terminals had color displays but most had either no color
|
|
or fixed "color" displays other than white such as green or amber. All
|
|
terminals had black (electron beam turned off = zero brightness). A
|
|
real color terminal can change the color of the text and background to
|
|
many different colors while a monochrome terminal can only change the
|
|
brightness of a fixed color.</P>
|
|
<P>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.</P>
|
|
<P>Real color works like the color on a computer monitor or TV screen.
|
|
The CRT has three colors of dots permanently on it with the brightness
|
|
of each color controlled by its own electron beam (3 beams). The
|
|
monochrome of real text terminals had inherently better resolution
|
|
since it didn't depend on dots permanently fixed on the screen. For
|
|
text terminals the only use of color is to differentiate text and this
|
|
advantage was often not worth the cost of worse resolution. Thus
|
|
monochrome may have historically been better since it also cost less.
|
|
But today color displays have are ubiquitous and have improved in
|
|
resolution since the olden days of the real text terminal.</P>
|
|
|
|
<H2><A NAME="ss9.3">9.3</A> <A HREF="Text-Terminal-HOWTO.html#toc9.3">Multiple Sessions </A>
|
|
</H2>
|
|
|
|
<P> 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".</P>
|
|
|
|
<H2><A NAME="ss9.4">9.4</A> <A HREF="Text-Terminal-HOWTO.html#toc9.4">Printer/Auxiliary Port </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#printer_esc">Printer Esc</A>.</P>
|
|
<P>There is a program called <CODE>vtprint</CODE> 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 <CODE>
|
|
<A HREF="http://vtprint.sourceforge.net/">vtprint</A></CODE>. It's also
|
|
included in the Debian distribution of Linux. <CODE>xprt</CODE> (also in
|
|
Debian) seems to do something similar, but only for X Window terminals
|
|
??</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="pages_"></A> <A NAME="ss9.5">9.5</A> <A HREF="Text-Terminal-HOWTO.html#toc9.5">Pages </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="char_sets"></A> <A NAME="ss9.6">9.6</A> <A HREF="Text-Terminal-HOWTO.html#toc9.6">Character-Sets </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>Many character sets include letters from foreign languages. But they
|
|
may also include special characters used to draw boxes and other
|
|
special characters.</P>
|
|
<P>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).</P>
|
|
<P>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.</P>
|
|
<P>More info re character-sets are:
|
|
<UL>
|
|
<LI> Manual pages: charsets, iso_8859-l or latin1 (covers 8859 series), ascii</LI>
|
|
<LI> HOWTO's for various languages (often written in that language).</LI>
|
|
<LI>
|
|
<A HREF="http://czyborra.com/charsets/iso8859.html">ISO-8859 Alphabet Soup</A> More than just iso8859. Extensive.</LI>
|
|
<LI>
|
|
<A HREF="http://www.cs.tut.fi/~jkorpela/chars.html">A tutorial on character code issues</A> Clearly written.</LI>
|
|
<LI>
|
|
<A HREF="http://www.w3.org/International/O-charset-lang.html">Languages, Countries and Character Sets</A></LI>
|
|
<LI>
|
|
<A HREF="http://www.osk.3web.ne.jp/logos/">Languages of the World by Computers ...</A></LI>
|
|
<LI>
|
|
<A HREF="ftp://kermit.columbia.edu/kermit/e/isok7.txt">... International Character Sets</A></LI>
|
|
</UL>
|
|
</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Graphics (Line Drawing, etc.) </H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>National Replacement Characters (obsolete) </H3>
|
|
|
|
<P> 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"</P>
|
|
<P>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.</P>
|
|
<P>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:<BR> @ [ \ ] ^ ` { \
|
|
} ~<BR> The symbols $ and # are sometimes used also. So
|
|
when using these replacement character sets, you are deprived of using
|
|
certain of these ASCII symbols since they now are used for the new
|
|
non-ASCII letters. Now that 8-bit character codes have replaced 7-bit
|
|
ones, it's better to use an 8-bit code which has both all the ASCII
|
|
symbols plus the non-ASCII characters for various languages. There's
|
|
also Unicode which replaces 8-bit codes with the same code scheme to
|
|
cover all languages (well almost all significant ones).</P>
|
|
<P>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.</P>
|
|
<P>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).</P>
|
|
<P>Here's tables for some character sets taken from Kermit and Unisys
|
|
documents:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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 --------
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss9.7">9.7</A> <A HREF="Text-Terminal-HOWTO.html#toc9.7">Fonts</A>
|
|
</H2>
|
|
|
|
<P> 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<BR>
|
|
<A HREF="http://www.ibiblio.org/pub/Linux/utils/terminal/">http://www.ibiblio.org/pub/Linux/utils/terminal/</A><BR>
|
|
For mapping the keyboard (and screen) for use of various fonts see
|
|
<A HREF="#mapchan_">Character Mapping: mapchan</A></P>
|
|
|
|
<H2><A NAME="ss9.8">9.8</A> <A HREF="Text-Terminal-HOWTO.html#toc9.8">Keyboards & Special Keys</A>
|
|
</H2>
|
|
|
|
<P>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).</P>
|
|
<P>
|
|
<UL>
|
|
<LI> 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.
|
|
</LI>
|
|
<LI> NO SCROLL stops the screen from scrolling like ^S does.
|
|
Depressing it again resumes scrolling. Uses flow control signals to
|
|
do this.
|
|
</LI>
|
|
<LI> 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.
|
|
</LI>
|
|
<LI> LINE FEED sends the line feed character ^J to the host. Seldom
|
|
used.
|
|
</LI>
|
|
<LI> 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
|
|
<A HREF="#enter_setup">Getting Into Set-Up (Configuration) Mode</A>.
|
|
</LI>
|
|
<LI> LOCAL disconnects the terminal from the host. In local, what
|
|
one types goes directly to the screen. Useful for testing.
|
|
</LI>
|
|
<LI> 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.
|
|
</LI>
|
|
<LI> F1, F2, ... or PF1, PF2, ... are function keys which sometimes
|
|
may be programmed to send out a sequence of bytes (characters). See
|
|
<A HREF="#funct_keys">Function Keys</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss9.9">9.9</A> <A HREF="Text-Terminal-HOWTO.html#toc9.9">Mouse</A>
|
|
</H2>
|
|
|
|
<P> A few text-terminals support a mouse. When the mouse is clicked,
|
|
an escape sequence is sent to the host to tell it where the mouse is.
|
|
An article for a mouse on VT terminals was once at
|
|
http://www.cs.utk.edu/ shuford/terminal/dec_vt_mouse.html but it's now a
|
|
dead link (2013). Try the "Wayback" machine." These escape codes for
|
|
mice are called "DEC Locator sequences". The FALCO Infinity Series of
|
|
terminals, model ANSI-G supports it. Did any linux applications support
|
|
this ?? </P>
|
|
|
|
<HR>
|
|
<H2><A NAME="term_emulation"></A> <A NAME="s10">10.</A> <A HREF="Text-Terminal-HOWTO.html#toc10">Terminal Emulation (including the Console) </A></H2>
|
|
|
|
<H2><A NAME="ss10.1">10.1</A> <A HREF="Text-Terminal-HOWTO.html#toc10.1">Intro to Terminal Emulation</A>
|
|
</H2>
|
|
|
|
<P> A trivial type of terminal emulation is where you set up a real
|
|
terminal to emulate another brand/model of terminal. To do this you
|
|
select the emulation you want (called "personality" in Wyse jargon)
|
|
from the terminal's set-up menu. This section will not discuss this
|
|
case.</P>
|
|
<P>Since a PC has a screen and keyboard (as does a real terminal) but
|
|
also has much more computing power, it's easy to use some of this
|
|
computing power to make the PC computer behave like a real text
|
|
terminal. Still a third type is where you just use a text-based
|
|
interface (at the console --usually just the monitor) to your Linux
|
|
PC, either by a terminal screen (such as xterm) in Xwindow or by a
|
|
"virtual terminal". </P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>For Linux see
|
|
<A HREF="#pc_as_terminal">Make a Linux PC a serial port terminal</A>. Emulation software for this also available for use
|
|
under MS Windows. See
|
|
<A HREF="#non_linux_pc">Make a non-Linux PC a terminal</A> This can be used to connect a Windows PC (as a
|
|
Text-Terminal) to a Linux PC.</P>
|
|
<P>Most Linux free software can only emulate a VT100, VT102, or
|
|
VT100/ANSI, xterm, pterm, or Wyse60 (but not fully). Since most PC's
|
|
have color monitors while VT100 and VT102 were designed for a
|
|
monochrome monitor, the emulation usually adds color capabilities
|
|
(including a choice of colors). Sometimes the emulation is not 100%
|
|
perfect but this usually causes few problems. None of them provide
|
|
programmable function keys. The non-free emulation software running
|
|
under MS Windows can emulate many more terminals than free Linux can.</P>
|
|
|
|
<H2><A NAME="term_not_for_emulation"></A> <A NAME="ss10.2">10.2</A> <A HREF="Text-Terminal-HOWTO.html#toc10.2">Don't Try to Use TERM Variable for Emulation</A>
|
|
</H2>
|
|
|
|
<P> Some have erroneously thought that they could create an emulator
|
|
at a Linux console (monitor) by setting the environment variable TERM
|
|
to the type of terminal they would like to emulate. This does not
|
|
work. The value of TERM only tells an application program what
|
|
terminal you are using. This way it doesn't need to interactively ask
|
|
you this question (and it's too dumb to be able to probe the terminal to
|
|
find out what type it is). If you're at a Linux PC monitor (command
|
|
line interface) it's a terminal of type "Linux", and since you can't
|
|
change this, TERM must be set to "Linux". But this "Linux" should be
|
|
set automatically, without you needing to do anything.</P>
|
|
<P>If you set it to something else, you are fibbing to an application
|
|
program. As a result, it will incorrectly interpret certain escape
|
|
sequences from the console resulting in a corrupted interface. Since
|
|
the Linux console behaves almost like a vt100 terminal, it could still
|
|
work almost OK if you falsely claimed it was a vt100 (or some other
|
|
terminal which is close to a vt100). In this case it may seeming work
|
|
OK most of the time but once in a while will give errors.</P>
|
|
|
|
<H2><A NAME="ss10.3">10.3</A> <A HREF="Text-Terminal-HOWTO.html#toc10.3">Serial Communication programs </A>
|
|
</H2>
|
|
|
|
<P>while the newer free PuTTY and Terra-Term programs can connect
|
|
directly to a serial line but can't dial out, most of of the older
|
|
programs did dialing out via a serial port modem. Some dialing
|
|
programs are for making a PPP connection to the Internet via a modem,
|
|
such as wvdial, and don't normally include any terminal emulation.
|
|
But some other programs (such as minicom or seyon) do both terminal
|
|
emulation and modem dialing (without PPP so it's not easy to use them
|
|
to connect to the internet). But since these programs connect to a
|
|
modem via a specified serial port (including "internal" serial ports
|
|
that have no connector on the back of the PC), they may be used to
|
|
connect to a serial line via a possible serial port connector on the
|
|
back of a PC. For this case you just set them up to connect without
|
|
dialing a phone number. The program "picocom" just does terminal
|
|
emulation although it's possible to type in a modem command and a
|
|
phone number to dial out manually. These programs are also useful for
|
|
testing modems. Seyon is only for use with X Window and can emulate
|
|
Tektronix 4014 terminals. In the past (before the Internet was
|
|
widespread) one could use dialing programs to dial up some public
|
|
libraries to use their catalogs and indexes, or even read magazine
|
|
articles on line. But today such activity is almost always done using
|
|
the Internet where there is a much larger choice of connections and no
|
|
long-distance telephone bills. </P>
|
|
<P>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.</P>
|
|
<P>Emulators exist under DOS such as <CODE>telix</CODE> and <CODE>procomm</CODE> work
|
|
just as well. The terminal emulated is often the old VT100, VT102, or
|
|
ANSI (like VT100).</P>
|
|
|
|
<H3>Emulation under X Window</H3>
|
|
|
|
<P>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
|
|
<A HREF="http://packages.ubuntu.com/dapper/virtual/x-terminal-emulator">Ubuntu -- x-terminal-emulator</A> for a brief list of such
|
|
emulators. Some are multilingual. Your Linux distribution has likely
|
|
installed one for you.</P>
|
|
|
|
<H3>Real terminals once were better</H3>
|
|
|
|
<P> Unless one was using X Window with a large display, a real
|
|
terminal was often nicer to use than emulating one. It often had
|
|
better resolution for text (since it's monochrome), and had no disk
|
|
drives to make annoying noises. Today, the resolution of modern color
|
|
displays is better than that of the old text-terminals and disk drives
|
|
are quieter.</P>
|
|
|
|
<H2><A NAME="ss10.4">10.4</A> <A HREF="Text-Terminal-HOWTO.html#toc10.4">Testing Terminal Emulation</A>
|
|
</H2>
|
|
|
|
<P> For the VT series terminals there is a test program: <CODE>vttest</CODE>
|
|
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:
|
|
<A HREF="http://www.ibiblio.org/pub/Linux/utils/console/">http://www.ibiblio.org/pub/Linux/utils/console/</A></P>
|
|
|
|
<H2><A NAME="console_"></A> <A NAME="ss10.5">10.5</A> <A HREF="Text-Terminal-HOWTO.html#toc10.5">The Linux Console </A>
|
|
</H2>
|
|
|
|
<P> The console for a PC Linux system is normally the computer monitor
|
|
in text mode. It emulates a terminal of type "Linux" and the escape
|
|
sequences it uses are in the man page: console_codes. There is no way
|
|
to make this interface emulate anything else. But of course you can run
|
|
emulation software on your PC so that the monitor and keyboard will
|
|
emulate a text terminal while that software program is running.
|
|
Setting the TERM environment variable to any type of terminal other
|
|
than "Linux" will not result in emulating that other terminal. It
|
|
will only result in a corrupted interface since you have falsely
|
|
declared (via the TERM variable) that your "terminal" is of a type
|
|
different from what it actually is: Linux. See
|
|
<A HREF="#term_not_for_emulation">Don't Use TERM For Emulation</A></P>
|
|
<P>In X Window, using a terminal emulator gives you the equivalent of a
|
|
console. For KDE they chose to call this emulation "konsole".
|
|
In some cases, the console for a Linux PC is a text-terminal. One may
|
|
recompile Linux to make a terminal receive most of the messages which
|
|
normally go to the console. See
|
|
<A HREF="#term_as_console">Make a Serial Terminal the Console</A>.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss10.6">10.6</A> <A HREF="Text-Terminal-HOWTO.html#toc10.6">Emulation Software</A>
|
|
</H2>
|
|
|
|
<P> Since there are free programs to emulate the most common
|
|
terminals, you will unlikely need to use any non-free software. But
|
|
if you need to purchase software you should try to throughly check out
|
|
what other customers have to say about it.</P>
|
|
|
|
<H3><A NAME="pc_as_terminal"></A> Make a Linux PC a serial port terminal </H3>
|
|
|
|
<P> Unless you want to emulate the standard vt100
|
|
(or close to it), xterm, or a Wyse 60, there doesn't seem to be much
|
|
free terminal emulation software available for Linux. The free
|
|
programs are minicom, picocom, and for GUI: seyon and PuTTY. Seyon
|
|
can emulate either xterm or vt100 while PuTTy uses its own termcap
|
|
(terminfo) named "putty" (put the terminal type "putty" in
|
|
/etc/inittab). Putty's "pterm" can be used as a replacement for
|
|
xterm.</P>
|
|
<P>PuTTY is much newer than most other emulations and a major use of it
|
|
is as an SSH client but you can set its configuration for a serial
|
|
port connection. Seyon is much older but with more features (some of
|
|
which are seldom needed). There are also more recent (but weaker)
|
|
"emulators" for a GUI interface: gtkterm and cutecom, neither of which
|
|
can emulate any terminal except of type "dumb" ??). Seyon can also
|
|
emulate a Tektronix 4014 terminal. For Wyse see
|
|
<A HREF="http://gutschke.com/wy60/">Wyse 60 emulator</A>.</P>
|
|
<P>Both gtkterm (and likely cutecom) don't use escape sequences, and
|
|
might be said to emulate a terminal of type "dumb" so they would be
|
|
quite slow if used as a text terminal for editing files on the host
|
|
computer using the vim editor, etc. gtkterm is simple to set up and
|
|
very weak in capabilities but it does show its current status at the
|
|
bottom of the screen.</P>
|
|
<P>Minicom, PuTTY, picocom, gtkterm, or cutecom may be used to emulate a
|
|
directly connected terminal by simply starting one of them. For
|
|
minicom, you must configure it for the serial port used). Picocom is
|
|
like a mini-minicom and doesn't have automatic dialout capability.
|
|
Gtkterm might be called a "mini-mini-minicom".</P>
|
|
<P>Minicom : For the case of minicom you obviously don't try to dial-out.
|
|
When you want to quit minicom (after you logout from the other PC) you
|
|
use minicom's q command to quit without reset since there is no modem
|
|
to reset. When minicom starts, it automatically sends out a modem
|
|
init string to the serial port. But since there's no modem there, the
|
|
string gets put after the "login:" prompt. If this string is mostly
|
|
capital letters, the getty program (which runs login) at the other PC
|
|
may think that your terminal has only capital letters and try to use
|
|
only capital letters. To avoid this, configure the modem init strings
|
|
sent by minicom to null (erase the init strings).</P>
|
|
<P>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
|
|
<A HREF="http://www.symantec.com/">http://www.symantec.com/</A>. And if you check the Internet (in
|
|
2008), it's still being sold here and there.</P>
|
|
<P>There was a specialized Linux distribution: Serial Terminal Linux. It
|
|
would turn a PC to into a minicom-like terminal. It's small (fits on a
|
|
floppy) and will not let you use the PC for any other purpose (when it's
|
|
running). The link to it is broken, but one similar to it (in 2013),
|
|
but on CD, is
|
|
<A HREF="http://www.asashi.net/pages/pitux.html">ASASHI DOT NET: PITUX, micro SERIAL TERMINAL LINUX</A></P>
|
|
<P>TERM (non-free commercial software from Century Software)
|
|
<A HREF="http://www.centurysoftware.com/terminal_emulator/advanced_terminal_emulator.php">Terminal Emulator</A> 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.</P>
|
|
|
|
<H3>Make a Linux PC an IBM network terminal</H3>
|
|
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3><A NAME="non_linux_pc"></A> Make a non-Linux PC a terminal </H3>
|
|
|
|
<P> Emulators exist which run on non-Linux PCs. They permit you to
|
|
use a non-Linux-PC as a terminal to connected to a Linux-PC. Under DOS
|
|
there were many programs that not only emulated a terminal but let you
|
|
dial out with a modem so that you could connect to other computers
|
|
over telephone lines (without getting connected to the Internet). Of
|
|
historical interest is an article in Byte magazine from Feb 1994
|
|
entitled "DOS Serial Communications. It was onetime at
|
|
http://www.byte.com/art/9402/sec8/art1.htm.</P>
|
|
<P>Today Windows comes with "HyperTerminal" (formerly simply called
|
|
"Terminal" in Windows 3.x and DOS). Competing with this is both the
|
|
free (open source) PuTTY and the non-free "HyperTerminal Private
|
|
Edition"
|
|
<A HREF="http://www.hilgraeve.com/htpe/index.html">http://www.hilgraeve.com/htpe/index.html</A> which is
|
|
non-free to business. It can emulate vt-220. PuTTY emulates xterm and
|
|
supposedly also vt-102 but it doesn't have file transfer capabilities
|
|
(such as zmodem) like HyperTerminal does. But PuTTY permits a display
|
|
with a height of over 24 lines (set the Linux shell variable LINES to
|
|
say 32 by typing: LINES=32). Turbosoft's TTWin (non-free) can emulate
|
|
over 80 different terminals under Windows. See
|
|
<A HREF="http://www.ttwin.com/">http://www.ttwin.com/</A> or
|
|
<A HREF="http://www.turbosoft.com.au/">http://www.turbosoft.com.au/</A> (Australia). See also
|
|
<A HREF="http://www.wrq.com/">WRQ</A></P>
|
|
<P>For using a Mac computer to emulate a common terminal use either
|
|
PuTTY, Linux's "minicom" (ported to the Mac OS X) or the old "zterm"
|
|
(shareware). For very old Macs prior to OS X, see the mini-howto:
|
|
Mac-Terminal.
|
|
<A HREF="http://www.carnationsoftware.com/carnation/HT.Carn.Home.html">Carnation Software</A> 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.</P>
|
|
|
|
|
|
<H2><A NAME="colors"></A> <A NAME="ss10.7">10.7</A> <A HREF="Text-Terminal-HOWTO.html#toc10.7">Colors on Emulated Terminals </A>
|
|
</H2>
|
|
|
|
<P>Since displays used for text terminal emulation are almost always
|
|
color displays, you can utilize color coding of words. Besides
|
|
displaying directories this way (See
|
|
<A HREF="#ls_color">Example for ls Function</A>) some other Linux programs display color-coded text.
|
|
It seems to mostly happen without any configuring but there may be
|
|
color conflicts. For example, if you have set the background color
|
|
green, then if a programs sends you green text, it will be difficult
|
|
or impossible to read.</P>
|
|
<P>Color usually works by programs sending ANSI escape sequences to the
|
|
terminal. One might think that an emulated terminal would show the
|
|
ANSI escape codes in the
|
|
<A HREF="#termcap1">terminfo</A>.
|
|
for the terminal. But this is not usually the case since if a terminal
|
|
support colors it seems to be assumed that these color will be sent to
|
|
the terminal using the ANSI encoding.</P>
|
|
<P>If you want to see what these encodings are, look at "man
|
|
console_codes". The ECMA-48 color codes in this man page appear to be
|
|
a subset of the ANSI color codes. For excruciating details see
|
|
<A HREF="http://en.wikipedia.org/wiki/ANSI_escape_code">ANSI escape code - Wikipedia</A>. Note that these ANSI codes cover more than just
|
|
colors.</P>
|
|
<P>For PuTTY one can select the precise color to display for every ANSI
|
|
code by using the settings menu and clicking on "Colours". For
|
|
example if you have your screen background light green, then you can
|
|
remap that ANSI color to some shade of brown that you select. Note
|
|
that light green is called "Green Bold". It's bold because it
|
|
contains a lot of white which makes it a light color.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="flow_control"></A> <A NAME="s11">11.</A> <A HREF="Text-Terminal-HOWTO.html#toc11">Flow Control (Handshaking) </A></H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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:
|
|
<OL>
|
|
<LI> Byte flow from the computer to the terminal</LI>
|
|
<LI> Byte flow from the terminal keyboard to the computer.</LI>
|
|
</OL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss11.1">11.1</A> <A HREF="Text-Terminal-HOWTO.html#toc11.1">Why Is Flow Control Needed ?</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="padding"></A> <A NAME="ss11.2">11.2</A> <A HREF="Text-Terminal-HOWTO.html#toc11.2">Padding </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#rec_del">Recognize Del</A>.</P>
|
|
<P>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 <CODE>stty</CODE> command involve padding.</P>
|
|
|
|
<H2><A NAME="ss11.3">11.3</A> <A HREF="Text-Terminal-HOWTO.html#toc11.3">Overrunning a Serial Port</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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).</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss11.4">11.4</A> <A HREF="Text-Terminal-HOWTO.html#toc11.4">Stop Sending</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="keybrd_lock"></A> <A NAME="ss11.5">11.5</A> <A HREF="Text-Terminal-HOWTO.html#toc11.5">Keyboard Lock </A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss11.6">11.6</A> <A HREF="Text-Terminal-HOWTO.html#toc11.6">Resume Sending</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="hdw_flow_control"></A> <A NAME="ss11.7">11.7</A> <A HREF="Text-Terminal-HOWTO.html#toc11.7">Hardware Flow Control (RTS/CTS etc.) </A>
|
|
</H2>
|
|
|
|
<P> 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
|
|
<A HREF="#null_modem_pinout">Standard Null Modem Cable Pin-out</A>. The
|
|
most popular pin to use seems to be the DTR pin (or both the DTR pin
|
|
and the DSR pin).</P>
|
|
|
|
<H3>RTS/CTS, DTR, and DTR/DSR Flow Control</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Connecting up DTR or DTR/DSR Flow Control </H3>
|
|
|
|
<P> 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
|
|
<A HREF="#keybrd_lock">Keyboard Lock</A>. 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.</P>
|
|
|
|
<H3>Old RTS/CTS handshaking is different</H3>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
|
|
<H3>Reverse Channel</H3>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="ss11.8">11.8</A> <A HREF="Text-Terminal-HOWTO.html#toc11.8">Is Hardware Flow Control Done by Hardware ?</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
<P>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.</P>
|
|
<P>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.</P>
|
|
|
|
<H2><A NAME="ss11.9">11.9</A> <A HREF="Text-Terminal-HOWTO.html#toc11.9">Obsolete ?? ETX/ACK or ENQ/ACK Flow Control</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="cable"></A> <A NAME="s12">12.</A> <A HREF="Text-Terminal-HOWTO.html#toc12">Physical Connection </A></H2>
|
|
|
|
<H2><A NAME="ss12.1">12.1</A> <A HREF="Text-Terminal-HOWTO.html#toc12.1">Introduction</A>
|
|
</H2>
|
|
|
|
<P> 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).</P>
|
|
|
|
<H2><A NAME="ss12.2">12.2</A> <A HREF="Text-Terminal-HOWTO.html#toc12.2">Multiport I/O Cards (Adapters)</A>
|
|
</H2>
|
|
|
|
<P> 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.</P>
|
|
|
|
<H2><A NAME="ss12.3">12.3</A> <A HREF="Text-Terminal-HOWTO.html#toc12.3">Direct Serial Cable Connection.</A>
|
|
</H2>
|
|
|
|
<P> 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).</P>
|
|
<P>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
|
|
<A HREF="#buy_or_make_cable">Buy or Make</A> 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).</P>
|
|
|
|
<H3>Pin numbering</H3>
|
|
|
|
<P>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.</P>
|
|
|
|
<H3>Null Modem cable pin-out (3, 4, or 5 conductor)</H3>
|
|
|
|
<P> 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 HREF="#twist_pair_kludge">A Kludge using Twisted-Pair Cable</A>. For a DB25 connector on
|
|
your PC, you need:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>If you have a DB9 connector on your PC, try the following:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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 **
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>If you have a DB9 connector on both your serial port and terminal:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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 **
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>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" ).</P>
|
|
|
|
<H3><A NAME="null_modem_pinout"></A> Standard Null Modem cable pin-out (7 conductor)</H3>
|
|
|
|
<P> 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).</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<A NAME="DB_pin-out"></A>
|
|
Alternatively, a full DB9-DB25 file-transfer (null-modem) cable (will
|
|
not work with terminal hardware handshaking; see above):</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
PC DB9 Terminal DB25
|
|
RxD Receive Data 2 <---- 2 TxD Transmit Data
|
|
TxD Transmit Data 3 ----> 3 RxD Receive Data
|
|
|--> 6 DSR Data Set Ready
|
|
DTR Data Terminal Ready 4 -|--> 8 DCD Carrier Detect
|
|
SG Signal Ground 5 ----- 7 SG Signal Ground
|
|
DCD Carrier Detect 1 <--|
|
|
DSR Data Set Ready 6 <--|- 20 DTR Data Terminal Ready
|
|
RTS Request To Send 7 ----> 5 CTS Clear To Send
|
|
CTS Clear To Send 8 <---- 4 RTS Request To Send
|
|
RI Ring Indicator 9 (not needed)
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and
|
|
DB25 connectors!)</P>
|
|
<P>Here's how to connect two DB9's together (but DTR flow control will
|
|
not work):
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
PC DB9 DB9
|
|
RxD Receive Data 2 <----- 3 TxD Transmit Data
|
|
TxD Transmit Data 3 -----> 2 RxD Receive Data
|
|
|--> 6 DSR Data Set Ready
|
|
DTR Data Terminal Ready 4 --|--> 1 DCD Carrier Detect
|
|
GND Signal Ground 5 ------ 5 GND Signal Ground
|
|
DCD Carrier Detect 1 <--|
|
|
DSR Data Set Ready 6 <--|-- 4 DTR Data Terminal Ready
|
|
RTS Request To Send 7 -----> 8 CTS Clear To Send
|
|
CTS Clear To Send 8 <----- 7 RTS Request To Send
|
|
RI Ring Indicator 9 (not used)
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Using the above 2 connections provide full modem control signals and
|
|
seemingly allow one to set "stty -clocal". Then one must turn on the
|
|
terminal first (asserts DTR) before the port may be opened in a normal
|
|
manner by getty, etc. But there is likely to be trouble if you fail
|
|
to turn on the terminal first (see
|
|
<A HREF="#rapid_respawn">Getty Respawning Too Rapidly</A>). For this reason one should use "stty
|
|
clocal" which is the default (ignores modem control lines) and the
|
|
additional wires in these cables then serve no useful purpose.</P>
|
|
<P>In olden days when it may not have been this easy to ignore modem
|
|
control signals etc, the following "trick" was done for cables that
|
|
lacked conductors for modem control: on your computer side
|
|
of the connector, connect RTS and CTS together, and also connect DSR,
|
|
DCD and DTR together. This way, when the computer needs a certain
|
|
handshaking signal to proceed, it will get it (falsely) from itself.</P>
|
|
|
|
<H3><A NAME="length_"></A> Overcoming length limitations </H3>
|
|
|
|
<P> A cable longer than a 50 feet or so may not work properly at high
|
|
speed. Much longer lengths sometimes work OK, especially if the speed
|
|
is low and/or the cable is a special low-capacitance type and/or the
|
|
electronics of the receiving end are extra sensitive. It is claimed
|
|
that under ideal conditions at 9600 baud, 1000 feet works OK. One way
|
|
to cover long distances is to install 2@ line drivers near each serial
|
|
port so as to convert unbalanced to balanced (and conversely) and then
|
|
use twisted pair cabling. But line drivers are expensive.</P>
|
|
<P>Another way to increase the distance is to try to cancel out much of
|
|
the magnetic field created by the currents in the transmit and receive
|
|
data wires: TxD and RxD. To do this, ground return lines, which have
|
|
current which is roughly equal (but in the opposite direction) are
|
|
placed next to the transmit and received wires. Twisted pair has
|
|
the best cancellation. Some DEC terminals have two signal ground
|
|
wires for this purpose. For example, one pair would be TxD and
|
|
SG(TxD) where SG is signal ground. If you use ribbon cable, insure
|
|
that the TxD and SG(TxD) wires are right next to each other.
|
|
Similarly for the RxD.</P>
|
|
<P>If there is only one signal ground wire provided by both the PC and
|
|
the terminal, it may be split into two wires in a twisted pair cable
|
|
for this purpose. You might think that return currents will be
|
|
equally split between the two signal ground wires. This would cancel
|
|
out only about half of the magnetic field. But it's better
|
|
cancellation than this because return current prefers the path of
|
|
least impedance. The return path of a data signal (such as TxD) has
|
|
the lowest impedance (due to lower inductance) if it flows back in the
|
|
same twisted pair. Although I've haven't seen any experimental test
|
|
results for this method, it should allow longer cable lengths.</P>
|
|
|
|
<H3>Hardware Flow Control cables</H3>
|
|
|
|
<P> If you expect to use hardware flow control (handshaking) you will
|
|
likely need to make up your own cable (or order one made). Of course,
|
|
if the connecters on the ends of a used cable remove, you might rewire
|
|
it. See
|
|
<A HREF="#db_conn_install">Installing DB Connectors</A>.
|
|
You will need to determine whether or not the terminal uses the
|
|
DTR pin for this, and if not, what pin (or pins) it uses. The set-up
|
|
menus may give you a clue on this since there may be an option for
|
|
enabling "DTR handshaking" (or flow control) which of course implies
|
|
that it uses the DTR pin. It may also use the DSR pin. See
|
|
<A HREF="#hdw_flow_control">Hardware Flow Control</A> for a detailed
|
|
explanation of it. Older terminals may have no provision for hardware
|
|
flow control.</P>
|
|
|
|
<H3>Cable tips</H3>
|
|
|
|
<P> The normal "straight thru" cable will not work unless you are
|
|
using it as an extension cable in conjunction with either a null modem
|
|
(crossover or file-transfer) cable or a null modem adapter. Make sure
|
|
that the connectors on the cable ends will mate with the connectors on
|
|
the hardware. One may use telephone cable which is at least
|
|
4-conductor (and possibly twisted pair). Shielded, special
|
|
low-capacitance cable computer cable is best.</P>
|
|
|
|
<H3><A NAME="twist_pair_kludge"></A> A kludge using twisted-pair cable </H3>
|
|
|
|
<P> See also
|
|
<A HREF="#length_">Overcoming Length Limitations</A>.
|
|
Although none of the EIA-232 signals are balanced for twisted pair
|
|
one may attempt to use twisted-pair cable with it. Use one pair for
|
|
transmit and another for receive. To do this connect signal ground to
|
|
one wire in each of these 2 pair. Only part of the signal ground
|
|
current flows in the desired wire but it may help. Due to the lower
|
|
inductance of the twisted pair circuit (as compared to ground return
|
|
current by some other path) more return (ground) current will confine
|
|
itself to the desired twisted pair than one would expect from only
|
|
resistance calculations. This is especially true at higher
|
|
frequencies since inductive impedance increases with frequency. The
|
|
rectangular wave of the serial port contains high frequency harmonics.</P>
|
|
|
|
<H3>Cable grounding</H3>
|
|
|
|
<P> Pin 1 (of a DB25) should be chassis ground (also earth ground) but
|
|
on cheap serial ports it may not even be connected to anything. A
|
|
9-pin connector doesn't even have a chassis ground. The signal ground
|
|
is pin 7 and is usually grounded to chassis ground. This means that
|
|
part of the signal current will flow thru the ground wires of the
|
|
building wiring (undesirable). Cable shields are supposed to be only
|
|
grounded at one end of the cable, but it may be better to ground both
|
|
ends since it's better to have current in the shield than in the
|
|
building wiring ??</P>
|
|
|
|
<H2><A NAME="ss12.4">12.4</A> <A HREF="Text-Terminal-HOWTO.html#toc12.4">Modem Connection</A>
|
|
</H2>
|
|
|
|
<P> By using a terminal-modem combination (without a computer) one may
|
|
dial out to other computers. Up to the mid 1990s in the US, there
|
|
were many "bulletin boards" one could dial out to. Some even provided
|
|
connections to the Internet. But bulletin boards lost out in favor of
|
|
the Internet.</P>
|
|
|
|
<H3>Dialing out from a terminal</H3>
|
|
|
|
<P> Instead of connecting a terminal (or computer emulating a
|
|
terminal) directly to a host computer using a cable it may be
|
|
connected to the host via a telephone line (or dedicated private line)
|
|
with a modem at each end of the line. The terminal (or computer) will
|
|
usually dial out on a phone line to a host computer.</P>
|
|
<P>Most people use a PC and modem for dialing out. The PC could have a
|
|
terminal connected to a serial port and the person at the terminal
|
|
may dial out using the PC. Connecting a real terminal directly to an
|
|
external modem is more difficult since the real terminal isn't very
|
|
intelligent and doesn't give as much feedback to the user. For
|
|
dialing out, many terminals can store one or more telephone numbers as
|
|
messages which may be "set-up" into them and are sent out to the modem
|
|
by pressing certain function keys. Many modems can also store phone
|
|
numbers. The modem initiation sequence must precede the telephone
|
|
number. When the outgoing call is answered by another modem at the
|
|
other end of the phone line, the host computer on this modem may
|
|
run a getty program to enable you to log in.</P>
|
|
|
|
<H3>Terminal gets dialed into</H3>
|
|
|
|
<P> It's common for a computer running Linux to get dialed into. The
|
|
caller gets a login prompt and logs in. At first glance, it may seem
|
|
strange how a dumb terminal (not connected to any computer) could
|
|
accept an incoming call, but it can. One possible reason for doing
|
|
this is to save on phone bills where rates are not symmetric. Your
|
|
terminal needs to be set up for dial-in: Set the modem at your
|
|
terminal for automatic answer (Register S0 set to 2 will answer on the
|
|
2nd ring). You turn on the terminal and modem before you expect a
|
|
call and when the call comes in you get a login prompt and log in.</P>
|
|
<P>The host computer that dials out to your terminal needs to do
|
|
something quite unusual. As soon as your modem answers, it needs to
|
|
run login (getty). A host may do this by running the Linux program
|
|
"callback" sometimes named "cb". Callback is for having computer A
|
|
call computer B, and then B hangs up and calls A back. This is what
|
|
you want if you are using computer A to emulate a terminal. For the
|
|
case of a real terminal this may be too complex a task so the host may
|
|
utilize only the "back" part of the callback program. The setup file
|
|
for callback must be properly configured at the host. Callback makes
|
|
the call to the terminal and then has mgetty run a login on that port.
|
|
Mgetty by itself (as of early 1998) is only for dial-in calls but
|
|
there is work being done to incorporate callback features into it and
|
|
thus make it able to dial-out. As of early 1999 it didn't seem to have
|
|
been done.</P>
|
|
|
|
<H2><A NAME="ss12.5">12.5</A> <A HREF="Text-Terminal-HOWTO.html#toc12.5">Telnet and ssh</A>
|
|
</H2>
|
|
|
|
<P>Telnet is a program which lets a text terminal (or a PC console)
|
|
connect to a host computer over a network. No serial ports are used
|
|
for the telnet connection. Of course if you are sitting at a real
|
|
text terminal there is a serial connection to your own host. But when
|
|
you run telnet, your host connects to another host via serial-less
|
|
telnet.</P>
|
|
<P>Telnet uses tcp/ip packets over various networks: the Internet, LANs,
|
|
etc. You run telnet (as a client) and it connects to a telnet server
|
|
on another computer on a network. Then you get a login prompt and log
|
|
in just as if you were directly connected via a cable to a serial
|
|
port.</P>
|
|
<P>Ssh is "Secure Shell" and is like telnet. At one time it was much
|
|
more secure than the conventional telnet which sent passwords in the
|
|
clear (no encoding). But now (2006) there are packages "telnet-ssl"
|
|
which offer secure telnet. But since telnet was slow in introducing
|
|
security, ssh may have become more popular.</P>
|
|
<P>Telnet may put each character you type inside a packet and naturally
|
|
there's a lot of overhead with this. But there's an option for sending
|
|
one line at a time. To use telnet as a client, you need to have an
|
|
account on another computer on that runs a telnet server. Then you
|
|
give the telnet command and specify the address of the computer that
|
|
will accept a connection from you.</P>
|
|
<P>What kind of terminal does telnet emulate? It doesn't. Instead, it
|
|
connects you to a remote computer using whatever kind of terminal you
|
|
are currently using. If you're on a Linux console, it's a terminal of
|
|
type Linux. The remote computer needs to somehow find out what type
|
|
of terminal you're on so it can send the correct escape sequences.</P>
|
|
<P>So using telnet is much like connecting up a dumb terminal to a serial
|
|
port except that instead of a cable between you and the computer,
|
|
there is a stream of packets flowing over the Internet between you and
|
|
some distant computer.</P>
|
|
|
|
<H2><A NAME="ss12.6">12.6</A> <A HREF="Text-Terminal-HOWTO.html#toc12.6">Terminal Server Connection</A>
|
|
</H2>
|
|
|
|
<H3>What is a terminal server ?</H3>
|
|
|
|
<P> A terminal server is something that serves to connect a bunch of
|
|
terminals to a host computer(s) via a network. Today this server is
|
|
often located nearby or inside the host computer. If you directly
|
|
connect some terminals to a PC or connect them via dial-up modems thru
|
|
serial ports at each end, you don't need a terminal server.</P>
|
|
<P>But if the terminals are connected to the host over a network, then
|
|
you may need a terminal server to make the serial-to-network
|
|
conversions. This is useful for devices such as printers and
|
|
terminals that have no built-in network support. However the
|
|
definition of "terminal server" has broadened to the case where all
|
|
data flows entirely over a network (except of course within the
|
|
computer itself) and where no serial ports are involved. The term
|
|
"terminal" may include a thin client type terminal with a GUI. The
|
|
network usually uses tcp/ip and/or ppp but other protocols (including
|
|
protocol conversion) are sometimes supported.</P>
|
|
<P>One way to connect a "terminal" (your PC console) to a network is to
|
|
run telnet on your PC (assuming your PC has a network connection). At
|
|
one time, terminal servers were dedicated hardware which could be used
|
|
only as terminal servers. Today a PC can simultaneously serve as a
|
|
terminal server, thereby serving many terminals.</P>
|
|
<P>Today, most terminal servers serve thin client terminals rather than
|
|
text-terminals. The "Linux Terminal Server Project" is an example.
|
|
But it can also serve text terminals using telnet. Such a text-terminal
|
|
is likely to be just a PC monitor emulating a terminal of type
|
|
"Linux". The terminal server is just software running on the host
|
|
computer. Telnet server software is like a simple terminal server.</P>
|
|
<P>A host that only has directly connected terminals (or modem
|
|
connections without tcp/ip or ppp) is sometimes called a "terminal
|
|
server". Although it's doing the same job as a real terminal server,
|
|
it strictly speaking is not a terminal server. </P>
|
|
|
|
<H3>Evolution of the "terminal server"</H3>
|
|
|
|
<P>Originally a terminal server served real text-terminals via the
|
|
serial port. A server for real text-terminals would have a number of
|
|
serial ports. The user would log in to the server and then get
|
|
connected via tcp/ip, etc. to a host computer where s/he would login a
|
|
second time again. Sometimes the first login would be automatic, or
|
|
perhaps there would be a choice given the user as to what host
|
|
computer (or printer) to connect to (or what protocol to use).</P>
|
|
<P>The use of real text-terminals declined as the PC replaced mainframes.
|
|
But the PC could emulate a terminal (using say minicom (Linux) or
|
|
(hyper)terminal for MS). One could could then dial-out via a modem
|
|
to a bulletin-board or the like. There would be a bank of modems to
|
|
accept such calls and each modem would be connected to a serial port.
|
|
The serial port could either be on a multiport card or on a dedicated
|
|
terminal server. Note that in both the above cases there is no client
|
|
software. It's not a client-server model.</P>
|
|
<P>When the Internet became popular, one would run the PPP protocol on
|
|
the phone line and still go thru a modem and "terminal server" at the
|
|
ISP. This server would handle PPP and ultimately connect one to the
|
|
Internet. But the PC was no longer emulating a text terminal since
|
|
browser images were being displayed. Today with ISPs getting only
|
|
digital signals from the phone company, they don't need real modems
|
|
anymore. So what was once a "terminal server" evolved into a "remote
|
|
access server". It's infrequently been called a "digital terminal
|
|
server". Note that 56k modem service requires that an ISP have a
|
|
digital connection to the phone company.</P>
|
|
<P>With remote access servers, instead of many individual telephone line
|
|
cables connected to a terminal server, one now finds just a few cables
|
|
with many digitized telephone calls on each cable (multiplexed). The
|
|
multitude of connectors needed for large numbers of terminals or
|
|
modems is no longer present on a remote access server and thus the
|
|
successor to this type of terminal server can't readily serve
|
|
text-terminals anymore.</P>
|
|
<P>More recently with the advent of thin clients terminals, the term
|
|
"terminal server" was revived to apply to the hosts that served the
|
|
thin clients. Both MS Windows and Linux can serve thin clients.</P>
|
|
|
|
<H2><A NAME="ss12.7">12.7</A> <A HREF="Text-Terminal-HOWTO.html#toc12.7">Connector and Adapter Types</A>
|
|
</H2>
|
|
|
|
<P> A connector is more-or-less permanently attached to the end of a
|
|
cable or to a hardware unit. There are two basic types of connectors
|
|
used in serial communications: 1. DB types with pins (DB 9 or DB25) and 2.
|
|
modular telephone-style connectors.</P>
|
|
<P>An adapter looks about like a connector but it has two ends with pins.
|
|
It is just like a cable that is so short that there is no cable part
|
|
left at all --just different connectors on each end is all that
|
|
remains. The adapter just plugs in to two other connectors on each side
|
|
of it. It allows two incompatible connectors to mate with each other
|
|
by going in between them. Except that even for two connectors that
|
|
will mate with each other, an adapter may be used to connect the cable
|
|
conductors together in other than straight-thru. Obviously, one may
|
|
use a special cable (perhaps homemade) as a substitute for an adapter.</P>
|
|
|
|
<H3>Sex of connector/adapters</H3>
|
|
|
|
<P> Connectors (or one side of adapters) are either male or female.
|
|
The connectors that have pins are male and the ones that have sockets
|
|
(sometimes also called pins) are female. For modular connectors, the
|
|
ones with exposed contacts are plugs while the ones with internal
|
|
contacts (not easy to see) are jacks. Plugs are male; jacks are
|
|
female.</P>
|
|
|
|
<H3>Types of adapters</H3>
|
|
|
|
<P> There are three basic types of adapters: null modem, gender
|
|
changers and port adapters. Some adapters perform more than one of
|
|
these three functions.
|
|
<UL>
|
|
<LI> null modem adapter: Reroutes wires, like a null modem cable.</LI>
|
|
<LI> gender changer: Changes the sex of a cable end. Two connectors
|
|
of the same sex can now connect (mate) with each other.</LI>
|
|
<LI> port adapter: Goes from one type of connector to another (DB9
|
|
to DB 25, etc.)</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3><A NAME="db_conn"></A> DB connectors </H3>
|
|
|
|
<P> (For how to install a DB connector on the ends of a cable see
|
|
<A HREF="#db_conn_install">Installing DB Connectors</A>.) These come in
|
|
9 or 25 pins. The EIA-232 specs. call for 25 pins but since most of
|
|
these pins are not used on ordinary serial ports, 9 pins is
|
|
sufficient. See
|
|
<A HREF="#DB_pin-out">DB9-DB25</A> for the pin-out.
|
|
The pins are usually numbered if you look closely enough or use a
|
|
magnifying glass.</P>
|
|
|
|
<H3><A NAME="rj_conn"></A> RJ modular connectors </H3>
|
|
|
|
<P> RJ means Registered Jack. These look like modern telephone
|
|
connectors but are sometimes not compatible with telephone connectors.
|
|
See also
|
|
<A HREF="#rj_conn_install">Installing RJ Connectors</A>.
|
|
For use with serial ports they may be 6 or 8 conductor. A few are
|
|
10-conductor but may not officially belong to the RJ series.</P>
|
|
|
|
<H3>6-conductors: RJ11/14, RJ12, and MMJ</H3>
|
|
|
|
<P> RJ11 are all the same size but may have 2, 4, or 6 conductors.
|
|
If it has two conductors, it should be called a RJ11. If it has 4
|
|
conductors, some call it a RJ14. If it has 6 conductors, many call it
|
|
a RJ12 (but a RJ12 per the phone company has only 4 conductors).
|
|
Seems confusing but they are all the same size and differ mainly by
|
|
the number of conductor contacts present.</P>
|
|
<P>A look-alike (almost) is a MMJ connector (6-conductor) used on later
|
|
model VT (and other) terminals. It's sometimes referred to as a
|
|
DEC-423 or a DEC RJ11. MMJ has an offset tab and is not compatible
|
|
with RJ ones (unless the tab is cut off). However, some connectors
|
|
have been made that are compatible with both MMJ and the RJ ones.
|
|
Since MMJ connectors are both hard to find and may be expensive some
|
|
people have forced a RJ (6 conductor) to fit MMJ by filing off the
|
|
offset tab with a file.</P>
|
|
<P>The MMJ (DEC) pinout is: 1-DTR, 2-TxD, 3-TxD_Gnd, 4-RxD_Gnd, 5-RxD,
|
|
6-DSR. Cyclades Cyclom-8Ys RJ12 has: 1-DTR, 2-TxD, 3-Gnd, 4-CTS,
|
|
5-RxD, 6-DCD. Specialix IO8+ has: 1-DCD, 2-RxD, 3-DTR/RTS, 4-Gnd,
|
|
5-TxD, 6-CTS. The pins of the RJ (and MMJ) are numbered similar to
|
|
the RJ45.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Plug Jack (or socket)
|
|
(Looking at the end (Looking at the cavity
|
|
end of a cable) in a wall or PC back)
|
|
.________. .________.
|
|
| 654321 | | 123456 |
|
|
|__. .__| |__. .__|
|
|
|__| |__|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>A standard MMJ file-transfer (null-modem) cable has a MMJ connector at
|
|
each end. It connects to the PC using a MMJ-to-DB adapter. This
|
|
adapter plugs into a DB (say 25 pin) connector on the back of the PC
|
|
and the MMJ connecter plugs into it. If you don't have such an
|
|
adapter, you can make a custom cable with a MMJ (or filed RJ)
|
|
connector on one end and a DB connector on the other end.</P>
|
|
<P>The standard file-transfer (null-modem) cable with two MMJ (or
|
|
RJ11/14) connectors will connect: 1-6, 2-5, and 3-4. Note that such a
|
|
cable supports DTR/DSR flow control which is not supported (yet) by
|
|
Linux. Making up your own standard 6-conductor file-transfer cable is
|
|
very simple if you understand that the ordinary 4-conductor telephone
|
|
cable from the wall to your telephone, used in hundreds of millions of
|
|
homes, is also a file-transfer cable. Find one and wire your cable the
|
|
same way.</P>
|
|
<P>If you lay such a cable flat on the floor (with no twists) you will
|
|
note that both plugs on the ends have their gold contacts facing up
|
|
(or both facing down). Although it's symmetrical, it is also
|
|
file-transfer if you think about it a bit. One may put a few such
|
|
cables together with inline couplers and everything works OK because
|
|
each inline coupler is also a file-transfer (null-modem) adapter. Two
|
|
file-transfer cables in series result in a straight-thru connection.</P>
|
|
<P>Here's a custom cable diagram (by Mark Gleaves) for connecting MMJ to
|
|
a 9-pin serial port using RTS/CTS flow control:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
DEC MMJ Linux PC DB9
|
|
Pin Signal Signal Pin
|
|
=== ====== ====== ===
|
|
1 DTR -----------------------|---> DSR 6
|
|
|---> CTS 8
|
|
2 TxD ---------------------------> RxD 2
|
|
3 SG (TxD)--------------------|--- SG 5
|
|
4 SG (RxD)--------------------|
|
|
5 RxD <--------------------------- TxD 3
|
|
6 DSR <-----------------------|--- RTS 7
|
|
|--> DTR 4
|
|
|--> CD 1
|
|
(no connection) RI 9
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<H3>8-conductors and 10-conductors</H3>
|
|
|
|
<P> RJ45 and RJ48 are 8-conductor modular telephone plugs.
|
|
There exists some 10-conductor connectors which are allegedly wider
|
|
and will not mate with the 8-conductor ones. People have called the
|
|
10-conductor ones RJ45 and/or RJ48 but this may be incorrect. These
|
|
connectors are used for both flat telephone cable and round twisted
|
|
pair cable. The cable end of the connector may be different for round
|
|
and flat cable. RJ48 has an extra tab so that a RJ48 plug will not
|
|
push into a RJ45 jack (but a RJ45 plug will mate with a RJ48 jack).
|
|
They're used on some multiport serial cards and networks. Heres the
|
|
pin numbers for an 8-conductor:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Plug Jack (or socket)
|
|
(Looking at the end (Looking at the cavity
|
|
end of a cable) in a wall)
|
|
.__________. .__________.
|
|
| 87654321 | | 12345678 |
|
|
|__. .__| |__. .__|
|
|
|____| |____|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="ss12.8">12.8</A> <A HREF="Text-Terminal-HOWTO.html#toc12.8">Making or Modifying a Cable</A>
|
|
</H2>
|
|
|
|
<H3><A NAME="buy_or_make_cable"></A> Buy or make ? </H3>
|
|
|
|
<P> You may try to buy a short, null modem cable. Just a "modem
|
|
cable" will not work. Null modem cables were once labeled as "serial
|
|
printer" cables but serial printers are not popular today (2004).
|
|
They also may be labeled as "file-transfer" cables or "PC-to-PC"
|
|
cables. Hardware flow control will work on them for PC-to-PC
|
|
connections (terminal emulation) but not for the DTR flow control used
|
|
by most real text terminals. If Linux supported DTR flow control,
|
|
real terminals would work OK . Make sure the connectors on the cable
|
|
ends will fit the connectors on your computer and terminal.</P>
|
|
<P>But if you need longer cables to connect up terminals or need hardware
|
|
flow control, how do you get the right cables? The right ready-made
|
|
cables may be difficult to find (you might find them by searching the
|
|
Internet), especially if you want to use a minimum (say 4) of
|
|
conductors. One option is to get them custom made, which is likely to
|
|
be fairly expensive although you might find someone to make them at
|
|
prices not too much higher than ready-made cable (I did).</P>
|
|
<P>A low-cost alternative is to buy used cables (if you can find them).
|
|
If you get a used terminal, ask if they have a cable for it. Another
|
|
alternative is to make your own. Even if you get used cables, they
|
|
may need some changes to the pin wiring. In either case, this may
|
|
require special tools. Most connectors that come with short cables
|
|
are permanently molded to the cable and can't be rewired but most
|
|
custom-made and homemade cables have connectors that can be rewired.
|
|
One advantage of making your own cable is that the skills you learn
|
|
will come in handy if a cable breaks (or goes bad) or if you need to
|
|
make up another cable in a hurry.</P>
|
|
|
|
<H3>Pin numbers of 9 and 25 pin connectors</H3>
|
|
|
|
<P> The pin numbers are often engraved in the plastic of the
|
|
connector but you may need a magnifying glass to read them.
|
|
Note DCD is sometimes labeled CD. The numbering of the pins on a
|
|
female connector is read from right to left, starting with 1 in the
|
|
upper right corner (instead of 1 in the upper left corner for the male
|
|
connector as shown below). --> direction is out of PC.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
___________ ________________________________________
|
|
\1 2 3 4 5/ Looking at pins \1 2 3 4 5 6 7 8 9 10 11 12 13/
|
|
\6 7 8 9/ on male connector \14 15 16 17 18 19 20 21 22 23 24 25/
|
|
------ -----------------------------------
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H3><A NAME="db_conn_install"></A> Installing DB connectors on cable ends </H3>
|
|
|
|
<P> See
|
|
<A HREF="#db_conn">DB Connectors</A> for a brief description
|
|
of them. Unfortunately, most cables one purchases today have molded
|
|
connectors on each end and can't be modified. Others have connectors
|
|
which unscrew and can be rewired. If you are making up cable or
|
|
modifying an existing one then you need to know about pins. There are
|
|
two types: soldered and crimped.</P>
|
|
<P>The crimped pins require a special crimping tool and also need an
|
|
"insertion/extraction" tool. But once you have these tools, making up
|
|
and modifying cable may be faster than soldering. If you are
|
|
connecting two wires to one pin (also needed if you want to jumper one
|
|
connected pin to another pin) then soldering is faster (for these
|
|
pins). This is because the crimped pins can only take one wire each
|
|
while the soldered ones can accept more than one wire per pin.</P>
|
|
<P>To insert crimped pins just push them in by hand or with the insertion
|
|
tool. Using the tool for either insertion of removal first requires
|
|
putting the tool tip around the wire. The tool tip should completely
|
|
encircle the wire at the back of the pin.</P>
|
|
<P>Removing a pin with this tool is a little tricky. These directions
|
|
can be best understood if you have both the tool and wires in front of
|
|
you as you read this. With the tool tip around the wire insert the
|
|
tool as far as it will go into the hole (about 1 1/2 cm. Some tools
|
|
have a mark (such as a tiny hole) on them to indicate how far to
|
|
insert it. The tool tip should have a tapered gap so that you may get
|
|
the tip around the wire by starting it in where the gap is wider than
|
|
the wire. The tool may have 2 tips. The one that is the most
|
|
difficult to get around the wire is also the one that removes the wire
|
|
the easiest since it almost completely envelops the wire.</P>
|
|
<P>With the tip properly inserted pull on both the tool and the wire
|
|
with a gentle pull. If it doesn't come out, the tool was likely not
|
|
inserted correctly so either push it in more or twist it to a
|
|
different position (or both). Perhaps you should have used another
|
|
tip that fits tighter around the pin. Using this tool, one may
|
|
readily convert a straight-thru cable to a file-transfer (null-modem)
|
|
cable, etc.</P>
|
|
<P>There can be problems using the "insertion/extraction" tool. If the
|
|
tools will not insert on the back of the pin, it could be that the pin
|
|
was not neatly crimped to the wire and is sort of square where it
|
|
should be round, etc. If a pin starts to come out but will not pull
|
|
out all the way, the pin may be bent. Look at it under a magnifying
|
|
glass. Straightening a pin with needle-nose pliers may damage the
|
|
gold plating but you may have to straighten it to remove it.
|
|
Sometimes a stuck pin may be pushed out with a thick screwdriver blade
|
|
tip (or the like) but if you push too hard you may gouge the plastic
|
|
hole or bend the pin:.</P>
|
|
<P>Don't try soldering unless you know what you're doing or have read
|
|
about how to do it.</P>
|
|
|
|
<H3><A NAME="rj_conn_install"></A> Installing RJ connectors </H3>
|
|
|
|
<P> These are telephone modular connecters one type of which is used
|
|
for most ordinary telephones. But there are many different types (see
|
|
<A HREF="#rj_conn">RJ Modular Connectors</A>).</P>
|
|
<P>These are not easy to reuse. You might be able to pull the wires out,
|
|
push in something wedged that would lift up the gold-colored contacts
|
|
and reuse the connector. There are special crimping tools used to
|
|
install them; a different tool for each type.</P>
|
|
<P>If you don't have a crimping tool, installation is still possible (but
|
|
difficult) using a small screwdriver (and possibly a hammer). Push in
|
|
the cable wires and then push each gold-colored contact down hard with
|
|
a small screwdriver that will just fit between the insulating ridges
|
|
between the contacts. You may damage it if you fail to use a
|
|
screwdriver with a head almost the same thickness as the contacts or
|
|
if the screwdriver slips off the contact as you are pushing it down.
|
|
You may also use a small hammer to pound on the screwdriver (push
|
|
first by hand).</P>
|
|
<P>Be sure to not hurt the "remove lever" on the connecter when you push
|
|
in the contacts. Don't just set it down on a table and push in the
|
|
contacts. Instead, put a shim (about 1 mm thick) that fits snugly
|
|
in the crevice between the lever and the body. For such a shim you
|
|
may use thick cardboard, several calling cards, or wood. Since the
|
|
bottom of the connector (that you will put on the table) isn't level
|
|
(due to the "remove lever), make sure that the table top has something
|
|
a little soft on it (like a sheet of cardboard) to help support the
|
|
non-level connector. Even better would be to put another 1mm shim
|
|
under the first 6mm of the connector, supporting it just under where
|
|
you see the contacts. A soft tabletop wouldn't hurt either. Another
|
|
method (I've never done this) is to hold the connector in a vice but
|
|
be careful not to break the connector.</P>
|
|
<P>As compared to using a crimping tool, installing it per above takes a
|
|
lot longer and is much more prone to errors and failure but it's sometimes
|
|
more expedient and a lot cheaper than buying a special tool if you
|
|
only have one or two connectors to install.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="setup_"></A> <A NAME="s13">13.</A> <A HREF="Text-Terminal-HOWTO.html#toc13">Set-Up (Configure) in General </A></H2>
|
|
|
|
<H2><A NAME="ss13.1">13.1</A> <A HREF="Text-Terminal-HOWTO.html#toc13.1">Intro to Set-Up</A>
|
|
</H2>
|
|
|
|
<P> Configuring (Set-Up) involves both storing a configuration in the
|
|
non-volatile memory of the terminal, and putting commands in start-up
|
|
files (on your hard disk) that will run each time the computer is
|
|
powered on (or possibly only when the run-level changes). This
|
|
section gives an overview of configuring and covers the configuring of
|
|
the essential communication options for both the terminal and the
|
|
computer. The next two major sections cover in detail the
|
|
configuration of the terminal (see
|
|
<A HREF="#term_conf_details">Terminal Set-Up</A> and the computer (see
|
|
<A HREF="#comp_conf_details">Computer Set-Up (Configure) Details</A>.</P>
|
|
|
|
<H2><A NAME="term_conf_ov"></A> <A NAME="ss13.2">13.2</A> <A HREF="Text-Terminal-HOWTO.html#toc13.2">Terminal Set-Up (Configure) Overview </A>
|
|
</H2>
|
|
|
|
<P> When a terminal is installed it's necessary to configure the
|
|
physical terminal by saving (in its non-volatile memory which is not
|
|
lost when the terminal is powered off) the characteristics it will
|
|
have when it is powered on. You might be lucky and have a terminal
|
|
that has already been set-up correctly for your installation so that
|
|
little or no terminal configuration is required.</P>
|
|
<P>There are two basic ways of configuring a terminal. One is to sit at
|
|
the terminal and go thru a series of set-up menus. Another is to send
|
|
escape sequences to it from the host computer. Before you can send
|
|
anything to the terminal (such as the above escape sequences), its
|
|
<A HREF="#commun_config">Communication Interface</A> options such
|
|
as the baud rate must be set up to match those of the computer. This
|
|
can only be done by sitting at the terminal since the communications
|
|
must be set up right before the computer and the terminal can "talk"
|
|
to each other. See
|
|
<A HREF="#term_conf_details">Terminal Set-Up</A>.</P>
|
|
|
|
<H2><A NAME="ss13.3">13.3</A> <A HREF="Text-Terminal-HOWTO.html#toc13.3">Computer Set-Up (Configure) Overview</A>
|
|
</H2>
|
|
|
|
<P> Besides possibly sending escape sequences from the computer to
|
|
configure the terminal, there is the configuring of the computer
|
|
itself to handle the terminal. If you're lucky, all you need to do is
|
|
to put a "getty" command in the /etc/inittab file so that a "login:"
|
|
prompt will be sent to the terminal when the computer starts up. See
|
|
the section
|
|
<A HREF="#getty_">Getty (used in /etc/inittab)</A> for
|
|
details.</P>
|
|
<P>The computer communicates with the terminal using the serial device
|
|
driver software (part of the kernel). The serial device driver has a
|
|
default configuration and is also partly (sometimes fully) configured
|
|
by the getty program before running "login" at each terminal.
|
|
However, additional configuration is sometimes needed using programs
|
|
named "stty" and "setserial". These programs (if needed) must be run
|
|
each time the computer starts up since this configuration is lost each
|
|
time the computer powers down. See
|
|
<A HREF="#comp_conf_details">Computer Set-Up (Configure) Details</A>.</P>
|
|
|
|
<H2><A NAME="ss13.4">13.4</A> <A HREF="Text-Terminal-HOWTO.html#toc13.4">Many Options</A>
|
|
</H2>
|
|
|
|
<P> There are a great many configuration options for you to choose
|
|
from. The communication options must be set right or the terminal
|
|
will not work at all. Other options may be set wrong, but will cause no
|
|
problem since the features they set may not be used. For example, if
|
|
you don't have a printer connected to the terminal it makes no
|
|
difference how the printer configuration parameters are set inside the
|
|
terminal. This last statement is not 100% correct. Suppose that you
|
|
have no printer but the computer (by mistake) sends the terminal a
|
|
command to redirect all characters (data) from the computer to the
|
|
printer only. Then nothing will display on the screen and your
|
|
terminal will be dead. Some terminals have a configuration option to
|
|
inform the terminal that no printer is attached. In this case the
|
|
terminal will ignore any command to redirect output to the "printer"
|
|
and the above problem will never happen. However, this doesn't help
|
|
much since there are many other erroneous commands that can be sent to
|
|
your terminal that will really foul things up. This is likely to
|
|
happen if you send the terminal a binary file by accident.</P>
|
|
<P>In some cases a wrong setting will not cause any problem until you
|
|
happen to run a rare application program that expects the terminal to
|
|
be set a certain way. Other options govern only the appearance of the
|
|
display and the terminal will work fine if they are set wrong but may
|
|
not be as pleasant to look at.</P>
|
|
<P>Some options concern only the terminal and do not need to be set at
|
|
the computer. For example: Do you want black letters on a light
|
|
background? This is easier on the eyes than a black background.
|
|
Should a key repeat when held down? Should the screen wrap when a
|
|
line runs off the right end of the screen? Should keys click?</P>
|
|
|
|
<H2><A NAME="commun_config"></A> <A NAME="ss13.5">13.5</A> <A HREF="Text-Terminal-HOWTO.html#toc13.5">Communication Interface Options </A>
|
|
</H2>
|
|
|
|
<P> Some of these communication settings (options) are for both the
|
|
terminal and the computer and they must be set exactly the same for
|
|
both: speed, parity, bits/character, and flow control. Other
|
|
communication options are only set at the terminal (and only a couple
|
|
of these are essential to establish communications). Still others
|
|
such as the address and interrupt (IRQ) of the physical port ttyS2 are
|
|
set only at the computer using the "setserial" command. Until all of
|
|
the above essential options are compatibly set up there can be no
|
|
satisfactory serial communication (and likely no communication at all)
|
|
between the terminal and the computer. For the terminal, one must set
|
|
these options manually by menus at each terminal (or by using some sort
|
|
of special cartridge at each terminal). The host computer is
|
|
configured by running commands each time the computer is powered up
|
|
(or when people log in). Sometimes the getty program (found in the
|
|
/etc/inittab file) which starts the login process will take care of
|
|
this for the computer. See
|
|
<A HREF="#getty_">Getty (used in /etc/inittab)</A></P>
|
|
<P>The settings for both the computer and the terminal are:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#speed">Speed (bits/second) </A></LI>
|
|
<LI>
|
|
<A HREF="#parity_">Parity</A></LI>
|
|
<LI>
|
|
<A HREF="#ch_size">Bits per Character </A></LI>
|
|
<LI>
|
|
<A HREF="#flow_control">Flow Control </A></LI>
|
|
</UL>
|
|
</P>
|
|
<P>Some essential settings for the terminal alone are:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#port_select">Port Select</A></LI>
|
|
<LI> Set communication to full duplex (=FDX on Wyse terminals)</LI>
|
|
</UL>
|
|
</P>
|
|
<P>If the
|
|
<A HREF="#getty_">Getty (used in /etc/inittab)</A> program
|
|
can't set up the computer side the way you want, then you may need to
|
|
use one (or both) of the
|
|
<A HREF="#stty_setserial">Stty & Setserial</A> commands.</P>
|
|
|
|
<H3><A NAME="speed"></A> Speed </H3>
|
|
|
|
<P> These must be set the same on both the terminal and the computer.
|
|
The speed is the bits/sec (bps or baud rate). Use the highest speed
|
|
that works without errors. Enabling flow control may make higher
|
|
speeds possible. There may be two speeds to set at the terminal:
|
|
Transmit and Receive, sometimes abbreviated T and R. Usually they are
|
|
both set the same since stty in Linux doesn't seem to have the option
|
|
yet of setting them differently. (There is an option to do this with
|
|
the "stty" command but it seems to actually set them both the same.)
|
|
Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ...
|
|
The slower speeds (like 600) are for printers and hard-copy terminals.</P>
|
|
|
|
<H3><A NAME="parity_"></A> Parity & should you use it ? </H3>
|
|
|
|
<P> For a definition see
|
|
<A HREF="#parity_def">Parity Explained</A>.
|
|
Parity-disabled is often the default. To enable parity, you must both
|
|
enable it and then select either even or odd parity. It probably
|
|
makes no difference if it's odd or even. For terminals there are
|
|
sometimes settings for both transmit and receive parity. You should
|
|
set both of these the same since stty at the computer doesn't permit
|
|
setting them differently. The PC serial port usually can't support
|
|
different parities either. Some terminal are unable to set receive
|
|
parity and will simply always ignore received parity bits. On some
|
|
older terminals if you use 8-data-bits per byte then parity will not
|
|
work since there is no room in the hardware for the extra parity bit.</P>
|
|
<P>Should you use parity at all? Parity, while not really necessary, is
|
|
nice to have. If you don't have parity, then you may get an incorrect
|
|
letter here and there and wind up trying to correct spelling errors
|
|
that don't really exist. However parity comes at a cost. First, it's
|
|
more complicated to set up since the default is usually no parity.
|
|
Secondly, parity will slow down the speed with which bytes travel over
|
|
the serial cable since there will be one more bit per byte. This may
|
|
or may not slow down the effective speed.</P>
|
|
<P>For example, a hard-copy terminal is usually limited by the mechanics
|
|
of the printing process. Increasing the bytes/sec when the computer
|
|
(its UART chip) is transmitting only results in more flow-control
|
|
"halt" signals to allow the mechanical printing to catch up. Due to
|
|
more flow-control waits the effective speed is no better without
|
|
parity than with it. The situation is similar for some terminals:
|
|
After you implement parity there may be fewer flow-control waits per
|
|
unit time resulting in more bits/sec (average). However, due to the
|
|
added parity bits the bytes/sec (average) stays the same.</P>
|
|
<P>One option is to install terminals with no parity. Then if parity
|
|
errors are noticed, it can be implemented later. To spot possible
|
|
errors with no parity, look for any spelling errors you don't think
|
|
you made. If you spot such an error, refresh the screen (retransmit
|
|
from the computer). If the error goes away, then it's likely a parity
|
|
error. If too many such errors happen (such as more than one every
|
|
few hundred screens) then corrective action is needed such as: Enable
|
|
parity and/or reduce speed, and/or use a shorter/better cable.
|
|
Enabling parity will not reduce the number of errors but it will tell
|
|
you when an error has happened.</P>
|
|
<P>Just the opposite policy is to initially enable parity. Then if no
|
|
parity errors (error symbols on the CRT) are ever seen (over a
|
|
reasonable period of time, say a month or two) it may be safely
|
|
disabled.</P>
|
|
|
|
<H3><A NAME="ch_size"></A> Bits/Character </H3>
|
|
|
|
<P> This is the character size (the number of data bits per character
|
|
excluding any parity bit). To use international character sets you
|
|
need 8 bits. But it's not of much use unless your terminal has the
|
|
fonts for them. See
|
|
<A HREF="#char_sets">Character-Sets</A> If you
|
|
are only going to use ASCII characters, then select 7-bits since it's
|
|
faster to transmit 7 bits than 8. Some very old terminals only
|
|
support 7-bit characters.</P>
|
|
|
|
|
|
<H3>Which Flow Control (Handshaking) ?</H3>
|
|
|
|
<P> The choice is between "hardware" (for example dtr/cts)
|
|
or "software" (Xon/Xoff) flow control. While hardware flow control
|
|
may be faster (if the one or two extra wires for it are available in
|
|
the cable and if the terminal supports it) in most cases Xon/Xoff
|
|
should work OK. Some people report that they solved disturbing
|
|
problems (see below) by converting to hardware flow control but
|
|
software flow control has worked fine at other installations (and for
|
|
me personally).</P>
|
|
<P>If you use software (Xon/Xoff) flow control and have users who don't
|
|
know about it, then they may accidentally send an Xoff to the host and
|
|
lock up their terminal. While it's locked, they may type frantically
|
|
in a vain attempt to unlock it. Then when Xon is finally sent to
|
|
restore communication, all that was typed in haste gets executed,
|
|
perhaps with unexpected results. They can't do this with hardware
|
|
flow control. See
|
|
<A HREF="#flow_control">Flow Control</A> for an
|
|
explanation of flow control.</P>
|
|
|
|
<H3><A NAME="port_select"></A> Port select </H3>
|
|
|
|
<P> Since most terminals have two or more connectors on the back, it
|
|
is usually possible to assign one of these connecters to connect to
|
|
the host computer and assign another connector to be the printer port.
|
|
The connector may have a name next to it (inspect it) and this name
|
|
(such as Aux, Serial 2, or Modem) may be assigned to either be the
|
|
main host connection or the printer connection (or the like).</P>
|
|
|
|
<H2><A NAME="ss13.6">13.6</A> <A HREF="Text-Terminal-HOWTO.html#toc13.6">Quick Attempt</A>
|
|
</H2>
|
|
|
|
<P> While all the above may seem overly complex, to get a terminal
|
|
working is often fairly simple. The
|
|
<A HREF="#quick_install">Quick Install</A> section describes a simple way to try to do
|
|
this. But if that doesn't work or if you want to make the display
|
|
look better and perform better, more reading will be needed.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="term_conf_details"></A> <A NAME="s14">14.</A> <A HREF="Text-Terminal-HOWTO.html#toc14">Terminal Set-Up (Configure) Details </A></H2>
|
|
|
|
<P> Except for the next subsection on sending escape sequences to the
|
|
terminal, this section mainly presents the details of setting up the
|
|
terminal manually by sitting at the terminal and going thru menus. If
|
|
you haven't already done so, you should read
|
|
<A HREF="#term_conf_ov">Terminal Set-Up (Configure) Overview</A>. It's best if you have a
|
|
terminal manual, but even it you don't there is information here on
|
|
many of the options which you might possibly need to set.</P>
|
|
<P>The communication parameters such as its baud rate must always be set
|
|
up at the terminal since if this is not done there can be no
|
|
communication with the terminal. Once communication is established
|
|
you have two choices for doing the rest of the terminal configuration.
|
|
You may continue to configure manually at the terminal and save the
|
|
results in the terminal's non-volatile memory or you may do this by
|
|
sending escape sequences to the terminal from the computer each time
|
|
the terminal is powered on (or the like).</P>
|
|
<P>If you know how to set up and save a good configuration inside the
|
|
terminal it may be the best way. If you don't, you might want to just
|
|
send the init string from terminfo to your terminal each time you use
|
|
the terminal. Perhaps doing nothing will still give you a usable
|
|
terminal. You (or an application program) can always change
|
|
things by sending certain escape sequences to the terminal.</P>
|
|
|
|
<H2><A NAME="ss14.1">14.1</A> <A HREF="Text-Terminal-HOWTO.html#toc14.1">Send Escape Sequences to the Terminal</A>
|
|
</H2>
|
|
|
|
<P> Once the communication interface is established, the rest of the
|
|
configuration of the terminals may sometimes be done by sending
|
|
escape sequences to the terminals from the computer. If you have a
|
|
large number of terminals, it may be worthwhile to write (or locate) a
|
|
shell script to automatically do this. There may (or may not) be a
|
|
command you can send to a terminal to tell it to save its current
|
|
set-up in its non-volatile memory so that it will be present the next
|
|
time the terminal is powered on.</P>
|
|
<P>There is an simple way to send these escape sequences and a complex
|
|
way. Using the simple way, you never look up escape sequences but
|
|
issue commands that automatically find an appropriate escape sequence
|
|
in the terminfo database and send that. Unfortunately, not all the
|
|
escape sequences which you might want to send are always in the
|
|
terminfo database. Thus the more complex (but possibly better) way is
|
|
to directly send escape sequences.</P>
|
|
<P>For this complex method you'll need an advanced manual. Old terminal
|
|
manuals once included a detailed list of escape sequences but newer
|
|
ones usually don't. To find them you may need to purchase another
|
|
manual called the "programmers manual" (or the like) which is not
|
|
supplied with the terminal. A
|
|
<A HREF="#esc_seq_lists">Esc Sequence List</A> for some terminals is on the Internet but it's terse
|
|
and likely incomplete.</P>
|
|
<P>Even without a manual or the like, you may still send commands to
|
|
configure the terminal by using the programs "tput" and "setterm".
|
|
See
|
|
<A HREF="#term_settings">Changing the Terminal Settings</A>.
|
|
You could just send the terminal an init string from the terminfo
|
|
entry if the init string sets up the terminal the way want it. See
|
|
<A HREF="#init_string">Init String</A>. Unless you plan to have
|
|
these sequences sent from the computer to the terminal each time the
|
|
terminal is powered on, you must somehow save the settings in the
|
|
non-volatile memory of the terminal.</P>
|
|
|
|
<H2><A NAME="ss14.2">14.2</A> <A HREF="Text-Terminal-HOWTO.html#toc14.2">Older Terminals Set-Up</A>
|
|
</H2>
|
|
|
|
<P> On older terminals look at the keyboard for labels just above the
|
|
top row of numeric keys. If they exist, these labels may be what
|
|
these keys do in set-up mode. Some older terminals may have only one
|
|
"set-up" menu. Still older ones have physical switches. In some
|
|
cases not all the switches are well labeled but they may be well
|
|
concealed. Of course, if you set something with a switch, it's
|
|
"saved" and there is no need to save the setting in non-volatile
|
|
memory.</P>
|
|
|
|
<H2><A NAME="enter_setup"></A> <A NAME="ss14.3">14.3</A> <A HREF="Text-Terminal-HOWTO.html#toc14.3">Getting Into Set-Up (Configuration) Mode </A>
|
|
</H2>
|
|
|
|
<P> To select options (configure) at the terminal, you must first
|
|
enter "set-up" mode and then select options (i.e. configure) using
|
|
menus stored inside the terminal and displayed on the screen. To do
|
|
this, the terminal does not even need to be connected to a computer.
|
|
How to get into set-up mode is covered in the terminal's manual, but
|
|
here's some hints that may help:</P>
|
|
<P>If there's a "set-up" key try pressing it. Also try it shifted.
|
|
<UL>
|
|
<LI> Wyse: First try the shifted "Select" key; then substitute
|
|
Ctrl for shifted in all of the above.</LI>
|
|
<LI> VT, Dorio: F3 may be the set-up key. On VT420 and later models
|
|
this key may have been programmed to do something else so turn off the
|
|
power. When you turn on the power again, hit the F3 key as soon as
|
|
you get an initial screen message.</LI>
|
|
<LI> IBM: 3151: Ctrl-ScrollLock. 3153: Ctrl-Minus_on_Keypad (or
|
|
like 3151)</LI>
|
|
</UL>
|
|
</P>
|
|
<P>To move around in the set-up menus, try the arrow keys. Use Return,
|
|
Space, or a special key ("toggle" on old terminals) to select.
|
|
To exit set-up mode select exit from a menu (or on some older
|
|
terminals press the set-up key again).</P>
|
|
|
|
<H2><A NAME="ss14.4">14.4</A> <A HREF="Text-Terminal-HOWTO.html#toc14.4">Communication Options</A>
|
|
</H2>
|
|
|
|
<P> For the terminal to work at all, speed, parity, :its/character,
|
|
and communication mode must be set correctly. Incorrect flow control
|
|
may cause loss and/or corruption of data seen on the screen. The
|
|
essential communication options were dealt with (for both the terminal
|
|
and computer) in another section: See
|
|
<A HREF="#commun_config">Communication Interface</A>. The following list provides some
|
|
links to that section, as well as some additional communication
|
|
options set only at the terminal.</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#speed">Speed (bits/second) </A>
|
|
(baud rate): 9600, 19200, etc.</LI>
|
|
<LI>
|
|
<A HREF="#parity_">Parity</A> none, even, odd, mark, space</LI>
|
|
<LI>
|
|
<A HREF="#ch_size">Bits per Character </A> {Data}: 7 or 8</LI>
|
|
<LI>
|
|
<A HREF="#flow_control">Flow Control:</A> or Handshake
|
|
{Hndshk}: none, Xon-Xoff, or hardware (DTR, etc).
|
|
<UL>
|
|
<LI> Receiver Handshake {Rcv Hndshk} protects data being Received
|
|
by the terminal by transmitting flow-control signals to the host.</LI>
|
|
<LI> Transmitter Handshake {Xmt Hndshk} is protection of data being
|
|
Transmitted by the terminal. The terminal receives flow-control
|
|
signals (and locks/unlocks the keyboard). Includes "Incoming Xon/Xoff".</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI> number of stop bits: 1 or 2. See
|
|
<A HREF="#byte_seq">Voltage Sequence for a Byte</A></LI>
|
|
<LI> Flow control level {Rcv Hndshk Level} {{Xoff at ...}}: Flow
|
|
control will send "stop" when this number of bytes in the terminal's
|
|
buffer is exceeded.</LI>
|
|
<LI>
|
|
<A HREF="#half_duplex">Communication Mode</A> {Comm}:
|
|
<A HREF="#half_duplex">Full Duplex {FDX}, Half Duplex {HDX}</A> {{Local
|
|
Echo}},
|
|
<A HREF="#local_mode">Local Mode</A> {{Online/Local}}</LI>
|
|
<LI> Transmit Rate (Speed) Limit {Xmt Lim}: limits the transmit rate
|
|
to the specified cps (chars/sec) even though the baud rate setting may
|
|
be at a higher speed.</LI>
|
|
<LI> Function-Key Rate Limit: as above but for function key
|
|
messages.</LI>
|
|
<LI>
|
|
<A HREF="#port_select">Port Select</A>: Which physical connecter
|
|
is for the host {Host Port} ?</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss14.5">14.5</A> <A HREF="Text-Terminal-HOWTO.html#toc14.5">Saving the Set-up</A>
|
|
</H2>
|
|
|
|
<P> Your set-up must be saved in the non-volatile memory of the
|
|
terminal so that it will be effective the next time you turn on the
|
|
terminal. If you fail to save it, then the new settings will be lost
|
|
when you turn off the terminal. Before you go to the trouble of
|
|
setting up a terminal, make sure that you know how to save the
|
|
settings. For modern terminals the save command is done via a menu.
|
|
In some older terminals, only the manual tells how to save. For many
|
|
of these you press Ctrl-S to save.</P>
|
|
|
|
<H2><A NAME="set_up_pars"></A> <A NAME="ss14.6">14.6</A> <A HREF="Text-Terminal-HOWTO.html#toc14.6">Set-Up Options/Parameters </A>
|
|
</H2>
|
|
|
|
<P> What follows in this section describes some of the options which are
|
|
available in the set-up menus of many terminals. Options are also
|
|
called parameters or features. Many options may be called "modes".
|
|
Setting options is often called "configuring". Many of these options
|
|
may also be set by sending certain escape sequences to the terminal.
|
|
Different models and brands of terminals have various options and the
|
|
same option may be called by different names (not all of which are
|
|
given here) Terse names used by Wyse are enclosed in {...}. Names
|
|
used mostly for VT terminals are enclosed in {{...}}.</P>
|
|
|
|
<H2><A NAME="ss14.7">14.7</A> <A HREF="Text-Terminal-HOWTO.html#toc14.7">Emulation {Personality} {{Terminal Modes}}</A>
|
|
</H2>
|
|
|
|
<P> Most modern terminals can emulate several other terminals. The
|
|
terminal can likely do more if it is set to emulate itself (actually
|
|
no emulation) {native personality}. Sometimes there are 2 different
|
|
emulations for the same model of terminal. For example VT220-7
|
|
emulates a VT220 with 7-bits/byte while VT220-8 emulates a VT220 with
|
|
8-bits/byte (256 possible characters).</P>
|
|
<P>Older models of terminals usually have fewer features than newer
|
|
models. Suppose one wanted to emulate an old terminal but also wanted
|
|
some of the advanced capabilities of the later model terminal they are
|
|
sitting at. This is sometimes possible (to some degree). This
|
|
feature is sometimes called {Enhance} (or Enhanced ??).</P>
|
|
|
|
<H2><A NAME="ss14.8">14.8</A> <A HREF="Text-Terminal-HOWTO.html#toc14.8">Display Options</A>
|
|
</H2>
|
|
|
|
<H3>Character Cell Size {Char Cell}</H3>
|
|
|
|
<P> This is the size of the cell in which a character fits. It is
|
|
measured in pixels (=tiny dots). The more dots, the better the
|
|
resolution. 10x16 is 10 dots wide by 16 dots high (16 rows and 10
|
|
columns). Note the notation is inverted as compared to the notation
|
|
for matrix dimensions which gives rows (height) first.. Also, the
|
|
character cell includes rows and columns of pixels allocated for the
|
|
space between adjacent characters so the cell size which defines the
|
|
boundaries of an actual character may be smaller.</P>
|
|
|
|
<H3>Columns/Lines</H3>
|
|
|
|
<P> Usually 80 columns and 24 or 25 lines. This means that there may
|
|
be up to 80 characters in a row (line) on the screen. Many terminals
|
|
have a 132 column option but unless you have a large screen, the tiny
|
|
characters may be hard to read. {{Set 132 column mode}}. If you set
|
|
25 lines, make sure that this is in the terminfo. You should also put
|
|
"export LINES=25" into /etc/profile and also use: "stty -F /dev/ttySx
|
|
rows 25". If you don't it might result in a scrolling problem (see
|
|
<A HREF="#no_scroll_25">Terminal doesn't scroll</A></P>
|
|
|
|
<H3>Cursor</H3>
|
|
|
|
<P> The cursor may be set to appear as a rectangle (= block) {Blk}.
|
|
Other options are underline {Line} or blinking. I prefer non-blinking
|
|
{Steady} block since it's big enough to find quickly but there is no
|
|
distractive blinking. If you set it invisible (an option on some
|
|
terminals) it will disappear but new letters will appear on the screen
|
|
as you type at the invisible cursor.</P>
|
|
|
|
<H3>Display Attributes (Magic Cookies)</H3>
|
|
|
|
<P>
|
|
<A HREF="#display_attributes">Display Attributes</A> may either
|
|
be magic cookies or be attribute bytes assigned to each character.
|
|
For magic cookies, there is a limit to their extent: Are they in
|
|
effect to the end of the line or to the end of the page? It's best to
|
|
use attribute bytes (which could actually be half-bytes = nibbles).</P>
|
|
|
|
<H3>Display Control Characters {Monitor}</H3>
|
|
|
|
<P> May be called various names such as "Display Controls". When off
|
|
(normal) it's "Interpret Controls". When set on, you see the escape
|
|
sequences from the host (which you normally never see on the screen).
|
|
So that these sequences may be viewed in sequence on a line, they are
|
|
not acted upon (interpreted) by the terminal. Except that a CR LF
|
|
sequence creates a new line. See
|
|
<A HREF="#control_codes">Control Codes</A>.</P>
|
|
|
|
<H3>Double Width/Height</H3>
|
|
|
|
<P> Some terminals can have their characters double width and/or
|
|
double height. This feature is seldom needed. When changing a line
|
|
to double width (DW) the right half (RH) is pushed off the screen and
|
|
there is the question of whether or not to delete (erase) it.
|
|
"Preserve" means to keep the RH of DW lines. When in double height
|
|
mode, it may be necessary to send each such line twice (the 2nd time
|
|
down one row) in order to get a double-height line on the screen.</P>
|
|
|
|
<H3>Reverse Video {Display} (Background Light/Dark)</H3>
|
|
|
|
<P> Normal video is light (white, green, amber) letters (foreground)
|
|
on a dark (black) background. Reverse video {Display Light} is the
|
|
opposite: black text on a light background. This is easier on the
|
|
eyes (unless the room is dark).</P>
|
|
|
|
<H3>Status Line</H3>
|
|
|
|
<P> A status line is a line at the top or bottom of the screen that
|
|
displays info about the application program you are running. It's
|
|
often highlighted in some way. With a status line enabled, an
|
|
application can send the terminal a special escape sequence which
|
|
means that the text that follows is for the status line. However,
|
|
many applications don't use this feature but instead only simulate a
|
|
real status line by direct cursor positioning. The ordinary user
|
|
looking at it doesn't know the difference.</P>
|
|
|
|
<H3>Upon 80/132 Change: Clear or Preserve?</H3>
|
|
|
|
<P> When switching the number of columns from 80 to 132 (or
|
|
conversely) should the data displayed in the old format be erased
|
|
(cleared) or preserved? {80/132 Clr} {{Screen Width Change}}. It
|
|
should make no difference how you set this option since if an
|
|
application program uses 132 columns, it should set this option
|
|
appropriately via a control sequence.</P>
|
|
|
|
<H2><A NAME="ss14.9">14.9</A> <A HREF="Text-Terminal-HOWTO.html#toc14.9">Page Related Options</A>
|
|
</H2>
|
|
|
|
<P> For a Wyse terminal to be able to access multiple pages of display
|
|
memory {Multipage} must be set to on.</P>
|
|
|
|
<H3>Page Size</H3>
|
|
|
|
<P> The terminal memory may be divided up into a number of pages.
|
|
See
|
|
<A HREF="#pages_">Pages</A> and
|
|
<A HREF="#pages_def">Pages (definition)</A> for explanations of pages. You may partition the page
|
|
memory into a number of pages of selected length. Linux applications
|
|
don't seem to use pages at present so it shouldn't make much
|
|
difference how you set this up.</P>
|
|
|
|
<H3>Coupling (of cursor & display)</H3>
|
|
|
|
<P> The terminal memory may be divided up into a number of pages.
|
|
See
|
|
<A HREF="#pages_">Pages</A> and
|
|
<A HREF="#pages_def">Pages</A>
|
|
for explanations of pages. When the cursor is moved to a location in
|
|
video memory not currently displayed (such as another page, or on the
|
|
same page but to a location not displayed on the screen) should the
|
|
display change to let one view the new cursor location? If so, this
|
|
is called "Coupling". For cursor movement within the same page there
|
|
is "Vertical Coupling" and "Horizontal Coupling". For movement to
|
|
another page there is "Page Coupling".</P>
|
|
|
|
<H2><A NAME="ss14.10">14.10</A> <A HREF="Text-Terminal-HOWTO.html#toc14.10">Reporting and Answerback</A>
|
|
</H2>
|
|
|
|
<P> The terminal will identify itself and its state, or send out a
|
|
pre-recorded message in response to certain escape sequences.</P>
|
|
|
|
<H3>Answerback Message (String)</H3>
|
|
|
|
<P> You may write a short message during set-up which may optionally
|
|
be sent to the host at power-up or be sent to the host in response to
|
|
a request from the host (perhaps the ENQ (inquire) control character).</P>
|
|
|
|
<H3>Auto Answerback</H3>
|
|
|
|
<P> If set, sends the answerback message to the host at power-on
|
|
without the host asking for it. Do any "getty" processes look for
|
|
this ??</P>
|
|
|
|
<H3>Answerback Concealed</H3>
|
|
|
|
<P> If set, will never let anyone see the answerback message (except
|
|
of course the host computer). If it needs to be changed, deselect
|
|
"answerback concealed" and the formerly concealed message will be
|
|
destroyed so you then may enter a new message (but you don't get to
|
|
see the old one).</P>
|
|
|
|
<H3>Terminal ID {ANSI ID}</H3>
|
|
|
|
<P> The terminal sends this reply in answer to a request for identity.</P>
|
|
|
|
<H2><A NAME="ss14.11">14.11</A> <A HREF="Text-Terminal-HOWTO.html#toc14.11">Keyboard Options</A>
|
|
</H2>
|
|
|
|
<H3>Keyclick</H3>
|
|
|
|
<P> When set, pressing any key makes a click (broadcast by a tiny
|
|
loudspeaker in the keyboard). These clicks annoy some people and I
|
|
think it's best to set keyclick off.</P>
|
|
|
|
<H3>Caps Lock {Keylock}</H3>
|
|
|
|
<P> When the Caps-Lock key is down, should only the alphabetic keys
|
|
generate shifted characters? If set to {Caps} or upper-case-only
|
|
then hitting a number key with the Caps-Lock on will type the number.
|
|
To get the symbol above the number one must manually hold down the
|
|
shift key. This is the normal mode. If set to {Shift} then all keys
|
|
type the shifted character when Caps-Lock is on (hitting the 5 key
|
|
should type % without holding down Shift, etc.).</P>
|
|
|
|
<H3>Auto Repeat {Repeat}</H3>
|
|
|
|
<P> If a key is held down then that key is repeatedly "typed". This
|
|
is handy for repeatedly typing the same character to create a line across
|
|
the page.</P>
|
|
|
|
<H3>Margin Bell</H3>
|
|
|
|
<P> When the cursor is 8 columns away from the right side of the
|
|
display, a bell is rung (like on an old typewriter). Almost all
|
|
editors will automatically create a new line if needed (no need to
|
|
hit the Return key) so this feature is seldom needed.</P>
|
|
|
|
<H3>Remapping the Keys</H3>
|
|
|
|
<P> The code sent to the host when a key is pressed is normally the
|
|
ASCII code for that key (depends also on Shift and Control key). On
|
|
some terminals you may make any key send any code you wish. That is,
|
|
you may completely remap the keyboard by setting up the terminal that
|
|
way. This may be useful for some foreign languages and Dvorak
|
|
keyboard layouts, etc. which permit one to type faster. Even for
|
|
terminals that don't have the feature, there is software to remap the
|
|
keyboard (and screen also). It's something like a device driver
|
|
which uses a pseudo terminal. See
|
|
<A HREF="#mapchan_">Character Mapping: mapchan</A></P>
|
|
|
|
<H3>Corner Key (for Wyse only)</H3>
|
|
|
|
<P> Wyse terminals have a key near the lower left corner which may be
|
|
set to do various things. Its may be labelled "Funct", "Compose
|
|
Character", "Alt", "Hold" or "Scroll Lock". Early models don't have
|
|
all of the following options:</P>
|
|
<P>
|
|
<UL>
|
|
<LI>Hold: No-Scroll. Hitting it stops the flow of data (using flow
|
|
control) to the terminal. Hitting the key again restores normal flow.</LI>
|
|
<LI>Compose: Hitting it followed by certain other keys permits one
|
|
to generate a limited number of pre-defined non-Latin characters.</LI>
|
|
<LI>Meta: Holding it down while typing another key sets the
|
|
high-order bit on each byte. Are there models where it acts like a
|
|
toggle to lock in the meta effect ??</LI>
|
|
<LI>Funct: Holding it down while typing any alphanumeric key
|
|
gets a header (SOH) and trailer (CR) byte framing the ASCII byte code.</LI>
|
|
<LI>Kpd Compose: Holding it down while typing a decimal number
|
|
on the numeric keys (followed by "enter") sends out the same number in
|
|
hexadecimal ??</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Numeric Keypad or Arrow Keys Sends</H3>
|
|
|
|
<P> The numeric keypad (the rectangle of mostly numeric keys to the
|
|
right of the main part of the keyboard) can be set to send special
|
|
codes which will do special things in certain application programs.
|
|
Ditto for the arrow keys. There is thus a "normal" mode where they
|
|
send what is shown on the keycap (or the normal code sequence for an
|
|
arrow-key) and an "application" mode where special escape sequences
|
|
are sent. In some cases there is a "hex" numeric mode which is almost
|
|
like normal numeric mode except that 6 non-numeric keys send the
|
|
letters A-F. Thus one may type for example "B36F" on the numeric
|
|
keypad.</P>
|
|
|
|
<H3>What does shifted-del and shifted-bs send?</H3>
|
|
|
|
<P> Depending on how they're set up, shifted-del sometimes sends the
|
|
control character CAN and shifted backspace sometimes sends DEL.</P>
|
|
|
|
<H3>PC Scan Codes</H3>
|
|
|
|
<P> Many terminals can emulate a PC keyboard by sending PC scancodes
|
|
(see Keyboard-and-Console-HOWTO) instead of ASCII codes. This is
|
|
mostly used with special Multiuser DOS OSs. It won't work with
|
|
ordinary MS DOS. See
|
|
<A HREF="#non_linux">Non-Linux OSs</A>
|
|
However, hardly any Linux programs that run via the serial port can
|
|
accept scancodes. If this is the latest version of this HOWTO, let me
|
|
know if any programs do this. I think Foxpro can do it. You need to
|
|
define smsc and rmsc in the terminfo, and perhaps pctrm.</P>
|
|
<P>When using scancodes it's best to use hardware flow control since
|
|
normal software flow control conflicts with some of the codes (??).
|
|
If you do use software flow control, you must use the XPC type of flow
|
|
control. It uses 0x65 and 0x67 for on and off characters. It must be
|
|
set this way both in the terminal and by stty for the PC.</P>
|
|
|
|
<H3>Alternate Characters</H3>
|
|
|
|
<P> Some keys may have alternative letters on them. When keys is set
|
|
to "Typewriter" they send what they would normally send on a
|
|
typewriter. When keys is set to something else the alternative
|
|
characters are sent.</P>
|
|
|
|
<H2><A NAME="ss14.12">14.12</A> <A HREF="Text-Terminal-HOWTO.html#toc14.12">Meaning of Received Control Codes</A>
|
|
</H2>
|
|
|
|
<H3>Auto New Line {Newline}</H3>
|
|
|
|
<P> In this case "New Line" means a new line starting at the left
|
|
margin below the current line. In Linux and C "new line" (NL) may
|
|
have a different meaning: the line-feed control character LF also
|
|
called new-line or NL. This is because in Linux text files, the LF
|
|
character means a "new line starts here" so it's labeled NL.
|
|
Normally, a LF (NL) sent to a terminal only results in the cursor
|
|
jumping down one line below where is was and does not move the cursor
|
|
back to the start of this "new line".</P>
|
|
<P>If Auto New Line is set, the above "normal" situation is canceled and
|
|
a physical new line is created on the display upon receiving a LF from
|
|
the host. This is exactly what one wants in Linux. Except that (when
|
|
Auto New Line is set) the Return (or Enter) key sends a CR LF sequence
|
|
to the host (for Wyse and VT100, but for VT420 ??). Since Linux uses
|
|
LF as a "new line" marker in files, Linux would like only a LF to be
|
|
sent (and not a CR LF). Thus the "New Line" option is seldom used.
|
|
Instead, the required translations are made by the serial port device
|
|
driver by default. It is as if one gave the command "stty onlcr
|
|
icrnl". But you don't need to do this since it's the default.</P>
|
|
|
|
<H3>Auto Line Feed {Rcv CR}</H3>
|
|
|
|
<P> This is just another type of "Auto New Line". When a CR (carriage
|
|
return) character is received, a LF (line feed) action is added
|
|
resulting in a new line being displayed. Since Linux marks the end of
|
|
lines with LF, this option is not used.</P>
|
|
|
|
<H3><A NAME="rec_del"></A> Recognize Del (Wyse Only ??) or Null </H3>
|
|
|
|
<P> If off, the DEL character received by the terminal is ignored. If
|
|
on the DEL performs a destructive backspace. Null characters are
|
|
usually ignored in any case. Both DEL and NULL are sometimes used for
|
|
padding. See
|
|
<A HREF="#padding">Padding</A></P>
|
|
|
|
<H2><A NAME="ss14.13">14.13</A> <A HREF="Text-Terminal-HOWTO.html#toc14.13">Where New Text Goes</A>
|
|
</H2>
|
|
|
|
<H3>Line Wrap</H3>
|
|
|
|
<P> Also called "Auto Wrap(around)". What happens when the right edge
|
|
of the screen is reached (col. 80, etc) and no return character (or
|
|
the like) has been sent from the host? If Line Wrap is set, then the
|
|
rest of the line displays on the line below, etc. Otherwise, the rest
|
|
of the line is lost and is not seen on the screen. Any good
|
|
application should handle the situation correctly (provided the
|
|
terminfo knows how Line Wrap is set). Thus even if Line Wrap is not
|
|
set, the application should either wrap the screen for long lines or
|
|
provide another way for you to view the cutoff tail of long lines (by
|
|
use of the arrow keys, etc). But a raw copy command (and other
|
|
situations) may not do this so it's often best to set line wrap.</P>
|
|
<P>For an 80 col. screen, most terminals only wrap if the 81st character
|
|
from the host is a graphic (printable) character. This allows for the
|
|
case where 81st character from the host might be "return" or a
|
|
"newline" (non-graphic characters) which means that the application is
|
|
handing the wrapping OK and intervention by the terminal is not
|
|
needed.</P>
|
|
|
|
<H3>Scrolling</H3>
|
|
|
|
<P> Scrolling {Scrl} is where all the lines on the screen move up or
|
|
down. Its also called "panning" which includes movement sideways. In
|
|
ordinary scrolling lines roll off the bottom or top of the screen and
|
|
disappear, and new lines from the host appear at the opposite edge
|
|
(top or bottom). There are 3 types of this: smooth, jump, or burst.
|
|
Burst is not really scrolling since its an instant replacement of an
|
|
old screenfull by a new one (although some lines on the new screen may
|
|
be from the old screen). Jump is where new lines jump into view one
|
|
at a time. Smooth {Smth} is where the text moves at a steady speed
|
|
upward or downward. If the smooth scroll rate is slow enough, one may
|
|
read the newly visible lines when they are still scrolling (in motion).</P>
|
|
<P>Smooth scrolling on slow terminals was once useful since one could
|
|
continue reading as the display was scrolling. But with higher baud
|
|
rates, jump scroll is so fast that little time is lost as the new
|
|
display appears. Since it takes a little longer to read scrolling
|
|
text than fixed text, it may actually waste more time if smooth
|
|
scrolling is selected.</P>
|
|
<P>If (auto)scrolling {Autoscrl} is disabled, then new text from the host
|
|
must go somewhere so it is put at the top of the display. If the old
|
|
text is not erased, the new text merges (nonsensically) into the old.
|
|
If the old text is erased, then the new text is out of context. So
|
|
keep (auto)scrolling enabled.</P>
|
|
|
|
<H3>New Page?</H3>
|
|
|
|
<P> See
|
|
<A HREF="#pages_">Pages</A> and
|
|
<A HREF="#pages_def">Pages</A> for explanations of pages. When the current page is
|
|
full (the last line is finished) should the page scroll, or should a
|
|
new page be created (leaving the previous page stored in the
|
|
terminal's display memory). If {Autopage} is set, then a new page is
|
|
created. Since you are probably not using pages, you should probably
|
|
set this to off.</P>
|
|
|
|
<H2><A NAME="funct_keys"></A> <A NAME="ss14.14">14.14</A> <A HREF="Text-Terminal-HOWTO.html#toc14.14">Function Keys </A>
|
|
</H2>
|
|
|
|
<P> These are the keys labeled F1, F2, etc. On older terminals they
|
|
may be labeled PF1, PF2, etc. where the P stands for Programmable.
|
|
Some keyboards have both. One may program (redefine) these keys to
|
|
send out a string of user-defined bytes. This doesn't work for older
|
|
terminals such as vt100 or for the Linux command-line interface (how
|
|
sad). They may often be easily "programmed" using a certain set-up
|
|
menu {FKey}. On some terminals, one may also specify where this
|
|
string is sent to when the key is pressed. In "normal" mode, pressing
|
|
the key is just like typing the string at the keyboard. In "local"
|
|
mode pressing the key sends it to the terminal (just like if the
|
|
terminal was in local mode). This may be used to send escape
|
|
sequences to the terminal so as to configure it in a special way. In
|
|
"remote" mode, the string is always sent out the serial port to the
|
|
host computer (even if the terminal is in local mode).</P>
|
|
|
|
<H2><A NAME="ss14.15">14.15</A> <A HREF="Text-Terminal-HOWTO.html#toc14.15">Block Mode Options</A>
|
|
</H2>
|
|
|
|
<P> Some options are only for the case of
|
|
<A HREF="#block">Block Mode</A>. This option is powerful since it provides forms and takes
|
|
load off the host computer by transmitting in bursts. But it's more
|
|
complicated to set up and is thus not used too much.</P>
|
|
|
|
<H3>Forms Display</H3>
|
|
|
|
<P> In block mode some regions of the screen are for the text of forms
|
|
and are thus write-protected "Prot" {WPRT}. Options may set the characters
|
|
in these regions to appear dim, reverse video {WPRT Rev}, and/or
|
|
underlined {WPRT Undrln}. {WPRT Intensity} may be set to dim, normal,
|
|
or even blank (invisible)</P>
|
|
|
|
<H3>Send Entire Block ?</H3>
|
|
|
|
<P> Should write-protected text (the original text in the form) be
|
|
sent to the host upon transmission of a block: {Send All} or is
|
|
write-protected text also read-protected: {Send Erasable}</P>
|
|
|
|
<H3>Region to Send</H3>
|
|
|
|
<P> Should the entire screen be sent or just the scrolling region?
|
|
{Send Area}. Should the sending stop when the current cursor position
|
|
is reached? If {Xfer Term} is set to Cursor, only the data on the
|
|
screen up to the cursor is sent.</P>
|
|
|
|
<H3>Block/Page terminator</H3>
|
|
|
|
<P> What is the termination symbol to be appended to a block of data?
|
|
{Blk End} or at the end of a page {Send Term}ination.</P>
|
|
|
|
<H2><A NAME="ss14.16">14.16</A> <A HREF="Text-Terminal-HOWTO.html#toc14.16">Locks</A>
|
|
</H2>
|
|
|
|
<P> There are various types of Locks. One is the Locked keyboard due
|
|
to flow control. See
|
|
<A HREF="#keybrd_lock">Keyboard Lock</A>
|
|
Another lock {Feature Lock} is that which prohibits the host computer
|
|
from changing the terminal set-up by sending certain escape sequences
|
|
to the terminal. Placing such a lock may result in unexpected
|
|
behavior as application programs send escape sequences to the
|
|
terminals that are ignored. Not all set-up parameters lock. Unless
|
|
you have a good reason to do so, you should not enable such locking.</P>
|
|
<P>A Function Key lock will prohibit the computer from redefining what a
|
|
programmable function key sends. You may want to use this if you have
|
|
something important programmed into the function keys.</P>
|
|
|
|
<H2><A NAME="ss14.17">14.17</A> <A HREF="Text-Terminal-HOWTO.html#toc14.17">Screen Saver {Scrn Saver}</A>
|
|
</H2>
|
|
|
|
<P> Also called "CRT Saver". This turns off (or dims) the screen
|
|
after the terminal is not used for a period of time. It may prolong
|
|
the life of the screen and save some energy. Hitting any key will
|
|
usually restore the screen and may "execute" that key so it's best to
|
|
hit the shift-key, etc.</P>
|
|
|
|
<H2><A NAME="ss14.18">14.18</A> <A HREF="Text-Terminal-HOWTO.html#toc14.18">Printer</A>
|
|
</H2>
|
|
|
|
<P> For Wyse, if there is no {Printer Attached} set it to Off. It's
|
|
not essential to do this, but if you do it any escape sequence to send
|
|
text to the printer (instead of the terminal) will be ignored.</P>
|
|
<P>Setting up the printer port is about the same (usually simpler) as
|
|
setting up the communications on the main port. There are a couple of
|
|
options specific to the printer. Is the printer a serial or parallel
|
|
printer? If it's parallel it should be designated as such in setup
|
|
and connected to the parallel port on the terminal (if there is one).
|
|
Should a FF (form feed) be sent to the printer at the end of a print
|
|
job? If {Print Term} is set to FF, this will happen.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="comp_conf_details"></A> <A NAME="s15">15.</A> <A HREF="Text-Terminal-HOWTO.html#toc15">Computer Set-Up (Configure) Details </A></H2>
|
|
|
|
<P> There are various files to edit to set up the computer for
|
|
terminals. If you're lucky, you'll only need to edit /etc/inittab.
|
|
One does this by editing at the console (or from any working terminal).</P>
|
|
|
|
<H2><A NAME="getty_"></A> <A NAME="ss15.1">15.1</A> <A HREF="Text-Terminal-HOWTO.html#toc15.1">Getty (used in /etc/inittab) </A>
|
|
</H2>
|
|
|
|
<H3>Introduction to Getty</H3>
|
|
|
|
<P> In order to have a login process run on a serial port (and the
|
|
terminal connected to it) when the computer starts up (or switches run
|
|
levels) a getty command must be put into the /etc/inittab file.
|
|
Running getty from the command line may cause problems (see
|
|
<A HREF="#stopped_">If getty run from command line: Programs get stopped</A> to see why ). Getty GETs a TTY (a terminal) going. Each
|
|
terminal needs its own getty command. There is also at least one
|
|
getty command for the console in every /etc/inittab file. Find this
|
|
and put the getty commands for the real terminals next to it. This
|
|
file may contain sample getty lines for text terminals that are
|
|
commented out so that all you need to do is to uncomment them (remove
|
|
the leading #) and change a few arguments.</P>
|
|
<P>The arguments which are permitted depend on which getty you
|
|
use:<BR>
|
|
Two gettys best for directly connected terminals are:
|
|
<OL>
|
|
<LI> agetty (sometimes just called getty): Easy to set up with no config
|
|
required. See
|
|
<A HREF="#agetty_">agetty</A></LI>
|
|
<LI>
|
|
<A HREF="#getty_ps">getty (part of getty_ps)</A> More
|
|
advanced with config file. </LI>
|
|
</OL>
|
|
|
|
Two gettys best for dial-in modems (avoid for directly connected
|
|
terminals) are:
|
|
<OL>
|
|
<LI> mgetty: the best one for modems; works for terminals too but inferior</LI>
|
|
<LI> uugetty: for modems only; part of the getty_ps package</LI>
|
|
</OL>
|
|
|
|
Simple gettys to use if you don't use a real text-terminal. Most
|
|
Linux users use one of these at their monitor:
|
|
<OL>
|
|
<LI> mingetty</LI>
|
|
<LI> fbgetty</LI>
|
|
<LI> fgetty</LI>
|
|
<LI> rungetty</LI>
|
|
</OL>
|
|
</P>
|
|
<P>Your Linux distribution may come with either getty_ps or agetty for
|
|
text-terminals. Some distributions supply neither. Unfortunately,
|
|
they often just call it "getty". If you need to determine which one
|
|
you have look at the man page for "getty". As of 2007 agetty (in the
|
|
"util-linux package) seems to be more widely used then getty_ps which
|
|
was at:
|
|
<A HREF="http://rpmfind.net/linux/rpm2html/search.php?query=getty_ps&subm">getty_ps</A></P>
|
|
<P>As a last resort to try to determine which getty you have, you might
|
|
check out its executable code (usually in /sbin). getty_ps has
|
|
/etc/gettydefs embedded in this code. To search for it, go
|
|
to /sbin and type:<BR>
|
|
<CODE>strings getty | grep getty </CODE><BR>
|
|
If getty is actually agetty the above will result in
|
|
nothing. However if you have agetty typing:<BR>
|
|
<CODE>getty -h</CODE><BR> should show the agetty options [-hiLmw].</P>
|
|
<P>The source codes for various gettys may be downloaded from
|
|
<A HREF="http://ibiblio.org/pub/Linux/system/serial/getty/">Getty Software</A>.</P>
|
|
<P>If you are not using modem control lines (for example if you only use
|
|
the minimum number of 3 conductors: transmit, receive, and common
|
|
signal ground) you should let getty know this by using a "local" flag.
|
|
The format of this depends on which getty you use.</P>
|
|
|
|
<H3>Getty exits after login (and can respawn)</H3>
|
|
|
|
<P>After you log in you will notice (by using "top", "ps -ax", or
|
|
"ptree") that the getty process is no longer running. What happened
|
|
to it? Why does getty restart again if your shell is killed? Here's
|
|
why.</P>
|
|
<P>After you type in your user name, getty takes it and calls the login
|
|
program telling it your user name. The getty process is replaced
|
|
by the login process. The login process asks for your password,
|
|
checks it and starts whatever process is specified in your password
|
|
file. This process is often the bash shell. If so, bash starts and
|
|
replaces the login process. Note that one process replaces another
|
|
and that the bash shell process originally started as the getty
|
|
process. The implications of this will be explained below.</P>
|
|
<P>Now in the /etc/inittab file, getty is supposed to respawn (restart) if
|
|
killed. It says so on the line that calls getty. But if the bash shell
|
|
(or the login process) is killed, getty respawns (restarts). Why?
|
|
Well, both the login process and bash are replacements for getty and
|
|
inherit the signal connections establish by their predecessors. In
|
|
fact if you observe the details you will notice that the replacement
|
|
process will have the same process ID as the original process. Thus
|
|
bash is sort of getty in disguise with the same process ID number. If
|
|
bash is killed it is just like getty was killed (even though getty
|
|
isn't running anymore). This results in getty respawning.</P>
|
|
<P>When one logs out, all the processes on that serial port are killed
|
|
including the bash shell. This may also happen (if enabled) if a
|
|
hangup signal is sent to the serial port by a drop of DCD voltage by
|
|
the modem. Either the logout or drop in DCD will result in getty
|
|
respawning. One may force getty to respawn by manually killing bash
|
|
(or login) either by hitting the k key, etc. while in "top" or with
|
|
the "kill" command. You will likely need to kill it with signal 9
|
|
(which can't be ignored).</P>
|
|
|
|
|
|
<H3><A NAME="stopped_"></A> If getty run from command line: Programs get stopped </H3>
|
|
|
|
<P> You should normally run getty from inside <CODE>/etc/inittab</CODE>
|
|
and not from the command line or else some programs running on the
|
|
terminal may be unexpectedly suspended (stopped). Here's why (skip to
|
|
the next section if the why is not important to you). If you start
|
|
getty for say ttyS1 from the command line of another terminal, say tty1,
|
|
then it will have tty1 as its "controlling terminal" even though the
|
|
actual terminal it runs on is ttyS1. Thus it has the wrong
|
|
controlling terminal. But if it's started inside the inittab file
|
|
then it will have ttyS1 as the controlling terminal (correct).</P>
|
|
<P>Even though the controlling terminal is wrong, the login at ttyS1 works
|
|
fine (since you gave ttyS1 as an argument to getty). The standard
|
|
input and output are set to ttyS1 even though the controlling terminal
|
|
remains tty1. Other programs run at ttyS1 may inherit this standard
|
|
input/output (which is connected to ttyS1) and everything is OK. But
|
|
some programs may make the mistake of trying to read from their
|
|
controlling terminal (tty1) which is wrong. Now tty1 may think that
|
|
these programs are being run in the background by tty1 so an attempt
|
|
to read from tty1 (it should have been ttyS1) results in stopping the
|
|
process that attempted to read. (A background process is not allowed
|
|
to read from its controlling terminal.). You may see a message
|
|
something like: "<CODE>[1]+ Stopped</CODE>" on the screen. At this point
|
|
you are stuck since you can't interact with a process which is trying
|
|
to communicate with you via the wrong terminal. Of course to escape
|
|
from this you can go to another terminal and kill the process, etc.</P>
|
|
|
|
<H3><A NAME="agetty_"></A> agetty (may be named getty) </H3>
|
|
|
|
<P>agetty means "alternative getty" and it was an easier-to-use
|
|
alternative to the original getty (getty_ps).<BR>
|
|
An example line in /etc/inittab: <BR>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
S1 is from ttyS1. 23 means that getty is run upon entering run levels
|
|
2 or 3. respawn means that if getty (or a process that replaced it
|
|
such as bash) is killed, getty will automatically start up (respawn)
|
|
again. /sbin/getty is the getty command. The -L means Local (ignore
|
|
modem control signals). -h (not shown in the example) enables
|
|
hardware flow control (same as stty crtscts). 19200 is the baud rate.
|
|
ttyS1 means /dev/ttyS1 (COM2 in MS-DOS). vt102 is the type of
|
|
terminal and this getty will set the environment variable TERM to this
|
|
value. There are no configuration files. Type "init q" on the
|
|
command line after editing getty and you should see a login prompt.</P>
|
|
|
|
<H3>Agetty's auto-detection of parity problems</H3>
|
|
|
|
<P> The <CODE>agetty</CODE> program will attempt to auto-detect the parity set
|
|
inside the terminal (including no parity). It doesn't support 8-bit
|
|
data bytes plus 1-bit parity. See
|
|
<A HREF="#parity_8-bit">8-bit data bytes (plus parity)</A>. If you use <CODE>stty</CODE> to set parity,
|
|
<CODE>agetty</CODE> will automatically unset it since it initially wants the
|
|
parity bit to come thru as if it was a data bit. This is because it
|
|
needs to get the last bit (possibly a parity bit) as you type your
|
|
login-name so that it can auto-detect parity. Thus if you use parity,
|
|
enable it only inside the text-terminal and let <CODE>agetty</CODE>
|
|
auto-detect it and set it at the computer. If your terminal supports
|
|
received parity, the login prompt will look garbled until you type
|
|
something so that getty can detect the parity. The garbled prompt
|
|
will deter visitors, etc. from trying to login. That could be just
|
|
what you want.</P>
|
|
<P>There is sometimes a problem with auto detection of parity. This
|
|
happens because after you first type your login name, <CODE>agetty</CODE>
|
|
starts the <CODE>login</CODE> program to finish logging you in.
|
|
Unfortunately, the <CODE>login</CODE> program can't detect parity so if the
|
|
<CODE>getty</CODE> program failed to determine the parity then <CODE>login</CODE> will
|
|
not be able to determine it either. If the first login attempt fails,
|
|
<CODE>login</CODE> will let you try again, etc. (all with the parity set
|
|
wrong). Eventually, after a number of failed attempts to login (or
|
|
after a timeout) <CODE>agetty</CODE> will start up again and start the login
|
|
sequences all over again. Once getty is running again, it may be able
|
|
to detect the parity on the second try so everything may then work OK.</P>
|
|
<P>With wrong parity, the <CODE>login</CODE> program can't correctly read what
|
|
you type and you can't log in. If your terminal supports received
|
|
parity, you will continue to see a garbled screen. If getty fails to
|
|
detect parity an /etc/issue file is usually dumped to the screen just
|
|
before the before the prompt, so more garbled words may appear on the
|
|
screen.</P>
|
|
<P>Why can't agetty detect parity by the first letter typed? Here's an
|
|
example: Suppose it detects an 8-bit byte with its parity bit 0
|
|
(high-order bit) and with an odd number of 1-bits. What parity is it?
|
|
Well, the odd number of 1 bits implies that it's odd parity. But it
|
|
could also just be an 8-bit character with no parity. There's no way
|
|
so far to determine which. But so far we have eliminated the
|
|
possibility of even parity. The detection of parity thus proceeds by
|
|
a process of elimination.</P>
|
|
<P>If the next byte typed is similar to the first one and also only
|
|
eliminates the possibility of even parity, it's still impossible to
|
|
determine parity. This situation can continue indefinitely and in rare
|
|
cases login will fail until you change your login-name. If agetty
|
|
finds a parity bit of 1 it will assume that this is a parity bit and
|
|
not a high-order bit of an 8-bit character. It thus assumes that you
|
|
don't use meta-characters (high bit set) in your user name (i.e that
|
|
your name is in ASCII).</P>
|
|
<P>One may get into a "login loop" in various ways. Suppose you only
|
|
type a single letter or two for your login name and then hit return.
|
|
If these letters are not sufficient for parity detection, then login
|
|
runs before parity has been detected. Sometimes this problem happens
|
|
if you don't have the terminal on and/or connected when agetty first
|
|
starts up.</P>
|
|
<P>If you get stuck in this "login loop" a way out of it is
|
|
to hit the return key several times until you get the getty login
|
|
prompt. Another way is to just wait a minute or so for a timeout.
|
|
Then the getty login prompt will be put on the screen by the getty
|
|
program and you may try again to log in.</P>
|
|
|
|
<H3><A NAME="parity_8-bit"></A> 8-bit data bytes (plus parity) </H3>
|
|
|
|
<P> Unfortunately, agetty can't detect this parity. As of late 1999
|
|
it has no option for disabling the auto-detection of parity and thus
|
|
will detect incorrect parity. The result is that the login process
|
|
will be garbled and parity will be set wrong. Thus it doesn't seem
|
|
feasible to try to use 8-bit data bytes with parity.</P>
|
|
|
|
<H3><A NAME="getty_ps"></A> getty (part of getty_ps) </H3>
|
|
|
|
<P>The name has often been misspelled as <CODE>ps_getty</CODE>. (Most of
|
|
this is from the old Serial-HOWTO by Greg Hankins)<BR> For this
|
|
getty one needs to both put entries in a configuration file and add an
|
|
entry in <CODE>/etc/inittab</CODE>. Here are some example entries to use
|
|
for your terminal that you put into the configuration file
|
|
<CODE>/etc/gettydefs</CODE>.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# 38400 bps Dumb Terminal entry
|
|
DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
|
|
|
|
# 19200 bps Dumb Terminal entry
|
|
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
|
|
|
|
# 9600 bps Dumb Terminal entry
|
|
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P> Note that the DT38400, DT19200, etc. are just labels and must
|
|
be the same that you use in <CODE>/etc/inittab</CODE>.</P>
|
|
<P>If you want, you can make <CODE>getty</CODE> print interesting things in the
|
|
login banner. In my examples, I have the system name and the serial
|
|
line printed. You can add other things:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
@B The current (evaluated at the time the @B is seen) bps rate.
|
|
@D The current date, in MM/DD/YY.
|
|
@L The serial line to which getty is attached.
|
|
@S The system name.
|
|
@T The current time, in HH:MM:SS (24-hour).
|
|
@U The number of currently signed-on users. This is a
|
|
count of the number of entries in the /etc/utmp file
|
|
that have a non-null ut_name field.
|
|
@V The value of VERSION, as given in the defaults file.
|
|
To display a single '@' character, use either '\@' or '@@'.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>When you are done editing <CODE>/etc/gettydefs</CODE>, you can verify that
|
|
the syntax is correct by doing:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
linux# getty -c /etc/gettydefs
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Make sure there is no other <CODE>getty</CODE> or <CODE>uugetty</CODE> config file for
|
|
the serial port that your terminal is attached to such as
|
|
(<CODE>/etc/default/{uu}getty.ttyS</CODE><EM>N</EM> or
|
|
<CODE>/etc/conf.{uu}getty.ttyS</CODE><EM>N</EM>), as this will probably
|
|
interfere with running <CODE>getty</CODE> on a terminal. Remove such
|
|
conflicting files if they exits.</P>
|
|
<P>Edit your <CODE>/etc/inittab</CODE> file to run <CODE>getty</CODE> on the serial
|
|
port (substituting in the correct information for your environment -
|
|
port, speed, and default terminal type):
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Restart <CODE>init</CODE>:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
linux# init q
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>At this point, you should see a login prompt on your terminal. You
|
|
may have to hit return to get the terminal's attention.</P>
|
|
|
|
<H3>mgetty</H3>
|
|
|
|
<P> The "m" stands for modem. This program is primarily for modems
|
|
and as of mid 2000 it will require recompiling to use it for
|
|
text-terminals (unless you use hardware flow control --and that
|
|
usually requires a hand-made cable). For the documentation for
|
|
directly connected terminals see the "Direct" section of the manual:
|
|
<CODE>mgetty.texi.</CODE></P>
|
|
<P>Look at the last lines of <CODE>/etc/mgetty/mgetty.config</CODE> for an
|
|
example of configuring it for a terminal. Unless you say "toggle-dtr
|
|
no" it will think that you have a modem and drop (negate) the DTR pin
|
|
at the PC in a vain attempt to reset the non-existent modem. In
|
|
contrast to other gettys, mgetty will not attach itself to a terminal
|
|
until someone hits any key of that terminal so you'll see a ? for the
|
|
terminal in <CODE>top</CODE> or <CODE>ps</CODE> until this happens. The logs in
|
|
<CODE>/var/log/mgetty/</CODE> may show a few warning messages which are
|
|
only applicable to modems which you may ignore.</P>
|
|
<P>Here's an example of the simple line you put in <CODE>/etc/inittab:</CODE></P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
s1:23:respawn:/sbin/mgetty -r ttyS1
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="stty_setserial"></A> <A NAME="ss15.2">15.2</A> <A HREF="Text-Terminal-HOWTO.html#toc15.2">Stty & Setserial </A>
|
|
</H2>
|
|
|
|
<P> There is both a "stty" command and a "setserial" command for
|
|
setting up the serial ports. Some (or all) of the needed stty
|
|
settings can be done via getty and there may be no need to use
|
|
setserial so you may not need to use either command. These two
|
|
commands (stty and setserial) set up different aspects of the serial
|
|
port. Stty does the most while setserial configures the low-level
|
|
stuff such as interrupts and port addresses. To "save" the settings,
|
|
these commands must be written in certain files (shell scripts) which
|
|
run each time the computer starts up. Distributions of Linux often
|
|
supply a shell script which runs <CODE>setserial</CODE> but seldom supply one
|
|
which runs <CODE>stty</CODE> since on seldom need it.</P>
|
|
|
|
<H2><A NAME="set_serial"></A> <A NAME="ss15.3">15.3</A> <A HREF="Text-Terminal-HOWTO.html#toc15.3">Setserial </A>
|
|
</H2>
|
|
|
|
<P> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
|
|
are some minor differences, depending on which HOWTO it appears in.</P>
|
|
|
|
<H3>Setserial problems with linmodems, laptops</H3>
|
|
|
|
<P>
|
|
If you have a Laptop (PCMCIA) don't use <CODE>setserial</CODE> until you
|
|
read
|
|
<A HREF="#laptops_">Laptops: PCMCIA</A>.</P>
|
|
|
|
<H3>Introduction</H3>
|
|
|
|
<P><CODE>setserial</CODE> is a program used for the user to communicate with
|
|
the serial device driver. You normally never need to use it, provided
|
|
that you only use the one or two serial ports that come as standard
|
|
equipment with a PC. Even in other cases, most extra serial ports
|
|
should be auto-detected by modern kernels. Except you'll need to use
|
|
setserial if you have an obsolete ISA serial port set by jumpers on the
|
|
physical hardware or if your kernel (such as 2.2 or older) doesn't
|
|
both detect and set your add-on PCI serial ports. In some cases the
|
|
setserial program may have been previously used and the wrong serial
|
|
port data has been manually given by the some past user (perhaps by
|
|
you). If setserial hasn't been configured to accept what the kernel
|
|
says, it will override the (likely correct) kernel data with what
|
|
someone previously set.</P>
|
|
<P><CODE>setserial</CODE> allows you (or a shell script) to talk to the serial
|
|
software. But there's also another program, tt/stty/, that also deals
|
|
with the serial port and is used for setting the port speed, etc.
|
|
<CODE>setserial</CODE> is really a misnomer, it doesn't set any information on
|
|
the serial card. Example: it can't change the irq set on the card.
|
|
More details on this later</P>
|
|
<P><CODE>setserial</CODE> deals with the lower-level configuring of the serial
|
|
port, such as dealing with IRQs (such as 5), port addresses (such as
|
|
3f8), and the like. A major problem with it is that it can't
|
|
set or configure the serial port hardware: It can't set the IRQ or
|
|
port addresses into the hardware. Furthermore, when it seemingly
|
|
reports the configuration of the hardware, it's sometimes wrong since
|
|
it doesn't actually probe the hardware unless you specifically tell it
|
|
to. Even then, it doesn't do the modern type of bus probing and some
|
|
hardware may never be found by it. Still, what it shows is right most
|
|
all the time but if you're having trouble getting a serial port to
|
|
work, then there's a fair chance it's wrong.</P>
|
|
<P>In olden days, when the IRQ and port address was set by jumpers on the
|
|
serial card, one would use <CODE>setserial</CODE> to tell the driver how these
|
|
jumpers were set. Today, when plug-and-play methods detect how the
|
|
jumperless serial port is set, <CODE>setserial</CODE> is not really needed
|
|
anymore unless you're having problems or using old hardware.
|
|
Furthermore, if the configuration file used by <CODE>setserial</CODE> is
|
|
wrong, then there's trouble. In this case, if you use <CODE>setserial</CODE>
|
|
to try to find out how the port is configured, it may just repeat the
|
|
incorrect information in the setserial configuration file.</P>
|
|
<P><CODE>setserial</CODE> can sometimes be of help to find a serial port. But
|
|
it's only of use if you know the port address and use the right
|
|
options. For modern ports, there's usually better ways to look for
|
|
them by plug-and-play methods.</P>
|
|
<P>Thus the name <CODE>setserial</CODE> is somewhat of a misnomer since it
|
|
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
|
|
them in the driver software. And the driver naively believes that
|
|
what <CODE>setserial</CODE> tells it, even if it conflicts with what the driver
|
|
has found by using plug-and-play methods. Too bad that it fails to
|
|
at least issue a warning message for setserial such a conflict. Since the
|
|
device driver is considered to be part of the kernel, the word
|
|
"kernel" is often used in other documentation with no mention made of
|
|
any "serial driver". </P>
|
|
<P>Some distributions (and versions) set things up so that <CODE>setserial</CODE>
|
|
is run at boot-time by an initialization shell script (in the
|
|
/etc directory tree). But the configuration file which this script
|
|
uses may be either in the /etc tree or the /var tree. In some cases,
|
|
if you want <CODE>setserial</CODE> to run at boot-time, you may have to take
|
|
some action. <CODE>setserial</CODE>will not work without either serial
|
|
support built into the kernel or loaded as a module. The module may
|
|
get loaded automatically if you (or a script) attempt to use
|
|
<CODE>setserial</CODE>.</P>
|
|
<P>While <CODE>setserial</CODE> can be made to probe the hardware IO port
|
|
addresses to try to determine the UART type and IRQ, this has
|
|
severe limitations. See
|
|
<A HREF="#probing_ss">Probing</A>. It
|
|
can't set the IRQ or the port address in the hardware of PnP or PCI
|
|
serial ports (but the plug-and-play features of the serial driver may
|
|
do this). It also can't directly read the PnP data stored in
|
|
configuration registers in the hardware. But since the device driver
|
|
can read these registers and setserial tells you what the device
|
|
driver thinks, it might be correct. Or it could be telling you what
|
|
<CODE>setserial</CODE> had previously (and perhaps erroneously) told the
|
|
driver. There's no way to know for sure without doing some other
|
|
checks.</P>
|
|
<P>The serial driver (for Linux Kernels 2.4 and 2.6) looks for a few
|
|
"standard" legacy serial ports, for PnP ports on the ISA bus, and for
|
|
all supported port hardware on the PCI bus. If it finds your ports
|
|
correctly, then there's no need to use <CODE>setserial</CODE> unless they have
|
|
been "set" incorrectly in the setserial configuration file. The driver
|
|
doesn't probe for the IRQs of old ISA serial ports set with jumpers on
|
|
the card and may get these wrong.</P>
|
|
<P>Besides the man page for <CODE>setserial</CODE>, check out info in
|
|
<CODE>/usr/doc/setserial.../</CODE> or <CODE>/usr/share/doc/setserial</CODE>.
|
|
This should tell you how setserial is handled for your distribution of
|
|
Linux. While <CODE>setserial</CODE> behaves the same in all distributions,
|
|
the scripts for running it, how to configure such scripts (including
|
|
automatic configuration), and the names and locations of the script
|
|
files, etc., are all distribution-dependent. If your serial port is Plug-and-Play you may need to consult other
|
|
HOWTOs such as Plug-and-Play or Serial.</P>
|
|
|
|
<H3>Serial module unload</H3>
|
|
|
|
<P>If a serial module gets unloaded, the changes previously made by
|
|
<CODE>setserial</CODE> will be forgotten by the driver. But while the driver
|
|
forgets it, a script provided by the distribution may save it in a
|
|
file somewhere so that it can the restored if the module is reloaded.
|
|
Also changes made by setserial may be stored in setserial's
|
|
configuration file (see the documentation for your distribution, this
|
|
info is not in the man page).</P>
|
|
|
|
|
|
|
|
<H3>Giving the <CODE>setserial</CODE> command</H3>
|
|
|
|
<P>Remember, that <CODE>setserial</CODE> can't set any I/O addresses or IRQs
|
|
in the hardware. That's done either by plug-and-play software (run by
|
|
the driver) or by jumpers for legacy serial ports. Even if you give
|
|
an I/O address or IRQ to the driver via <CODE>setserial</CODE> it will not set
|
|
such values and assumes that they have already been set. If you give
|
|
it wrong values, the serial port will not work right (if at all).</P>
|
|
<P>For legacy ports, if you know the I/O address but don't know the IRQ
|
|
you may command setserial to attempt to determine the IRQ.</P>
|
|
<P>You can see a list of possible commands by just typing <CODE>setserial</CODE>
|
|
with no arguments. This fails to show you the one-letter options such
|
|
as -v for verbose which you should normally use when troubleshooting.
|
|
Note that setserial calls an IO address a "port". If you type:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
setserial -g /dev/ttyS*
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
You'll see some info about how the device driver is configured for
|
|
your ports. In many cases you'll see some ports displayed with what
|
|
appears at first glance to be erroneous IRQs and addresses. But if
|
|
you also see: <CODE>"UART: unknown"</CODE> just ignore the entire line
|
|
since no serial port exists at that address. </P>
|
|
<P>If you add -a to the option -g you will see more info although few
|
|
people need to deal with (or understand) this additional info since
|
|
the default settings you see usually work fine. In normal cases the
|
|
hardware is set up the same way as "setserial" reports. But if you are
|
|
having problems there is a good chance that <CODE>setserial</CODE> has it wrong.
|
|
In fact, you can run "setserial" and assign a purely fictitious I/O
|
|
port address, any IRQ, and whatever uart type you would like to have.
|
|
Then the next time you type "setserial ..." it will display these
|
|
bogus values you've supplied to the driver. They will also be officially
|
|
registered with the kernel as displayed (at the top of the screen) by
|
|
the "scanport" command (Debian). Of course the serial
|
|
port driver will not work correctly (if at all) if you attempt to use
|
|
such a port. Thus, when giving parameters to <CODE>setserial</CODE>, "anything
|
|
goes". Well almost. If you assign one port a base address that is
|
|
already assigned (such as 3e8) it may not accept it. But if you use
|
|
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
|
|
is within the range starting at base address 3e8. Thus the moral of
|
|
the story is to make sure your data is correct before assigning
|
|
resources with setserial.</P>
|
|
|
|
<H3>Configuration file</H3>
|
|
|
|
<P>While assignments made by setserial are lost when the PC is powered
|
|
off, a configuration file may restore them when the PC is started
|
|
up again. In newer versions, what you change by setserial might get
|
|
automatically saved to a configuration file. When <CODE>setserial</CODE> runs
|
|
it uses the info from the configuration file.</P>
|
|
<P>Where this configuration file resides depends on your distribution.
|
|
Look at the start-up scripts somewhere in the /etc/ tree (such as
|
|
/etc/init.d/ or /etc/rc.d/) and read the startup script for "serial"
|
|
or "setserial" or the like. It should show where the configuration
|
|
file(s) reside. In Debian there are 4 options for use of this
|
|
configuration file:</P>
|
|
<P>
|
|
<OL>
|
|
<LI>Don't use this file at all. At each boot, the serial driver
|
|
alone detects the ports and setserial doesn't ever run. ("kernel" option)</LI>
|
|
<LI>Save what <CODE>setserial</CODE> reports when the system is first
|
|
shutdown and put it in the configuration file. After that, don't ever
|
|
make any changes to the configuration file, even if someone has made
|
|
changes by running the <CODE>setserial</CODE> command on the command line and
|
|
then shuts down the system. ("autosave-once" option)</LI>
|
|
<LI>At every shutdown, save whatever <CODE>setserial</CODE> detects to the
|
|
configuration file. ("autosave" option)</LI>
|
|
<LI>Manually edit the configuration file to set the configuration.
|
|
Don't ever do any automatic saves to it. ("manual" option)</LI>
|
|
</OL>
|
|
</P>
|
|
<P>In olden days (perhaps before 2000), there wasn't any configuration
|
|
file and the configuration was manually set (hard coded) inside the
|
|
shell script that ran <CODE>setserial</CODE>. See
|
|
<A HREF="#old_sets_script">Edit a script (prior to version 2.15)</A>.</P>
|
|
|
|
<H3><A NAME="probing_ss"></A> Probing </H3>
|
|
|
|
<P>You probe for a port with <CODE>setserial</CODE> only when you suspect that
|
|
it has been enabled (by PnP methods, the BIOS, jumpers, etc.).
|
|
Otherwise <CODE>setserial</CODE> probing will never find it since its address
|
|
doesn't exist. A problem is where the software looks for a port at
|
|
specified I/O addresses. Prior to probing with "setserial", one may
|
|
run the "scanport" (Debian) command to check all possible ports in one
|
|
scan. It makes crude guesses as to what is on some ports but doesn't
|
|
determine the IRQ. It's a fast first start. It may hang your PC but
|
|
so far it's worked fine for me. Note that non-Debian distributions
|
|
don't seem to supply "scanport". Is there another scan program?</P>
|
|
<P>With appropriate options, <CODE>setserial</CODE> can probe (at a given I/O
|
|
address) for a serial port but you must guess the I/O address. If you
|
|
ask it to probe for /dev/ttyS2 for example, it will only probe at the
|
|
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
|
|
is at a different address, then it will probe at that address, etc.
|
|
See
|
|
<A HREF="#probing_ss">Probing</A></P>
|
|
<P>The purpose of such probing is to see if there is a uart there, and if
|
|
so, what its IRQ is. Use <CODE>setserial</CODE> mainly as a last resort as
|
|
there are faster ways to attempt it such as wvdialconf to detect
|
|
modems, looking at very early boot-time messages, or using <CODE>pnpdump
|
|
--dumpregs</CODE>, or lspci -vv. But if you want to detect hardware
|
|
with <CODE>setserial</CODE> use for example :<BR> <CODE>setserial
|
|
/dev/ttyS2 -v autoconfig</CODE><BR>
|
|
If the resulting message shows a uart type such as 16550A, then you're
|
|
OK. If instead it shows "<CODE>unknown</CODE>" for the uart type, then there
|
|
is supposedly no serial port at all at that I/O address. Some cheap
|
|
serial ports don't identify themselves correctly so if you see
|
|
"<CODE>unknown</CODE>" you still might have a serial port there.</P>
|
|
<P>Besides auto-probing for a uart type, setserial can auto-probe for
|
|
IRQ's but this doesn't always work right either. In one case it first
|
|
gave the wrong irq but when the command was repeated it found the
|
|
correct irq. In versions of setserial >= 2.15, the results of your
|
|
last probe test could be automatically saved and put into a
|
|
distribution-specific configuration file such as
|
|
<CODE>/etc/serial.conf</CODE> or <CODE>/etc/sysconfig/serial</CODE> or
|
|
<CODE>/var/lib/setserial/autoserial.conf</CODE> for Debian. This will be
|
|
used next time you start Linux. </P>
|
|
<P>It may be that two serial ports both have the same IO address set in
|
|
the hardware. Of course this is not normally permitted for the ISA
|
|
bus but it sometimes happens anyway. Probing detects one serial port
|
|
when actually there are two. However if they have different IRQs,
|
|
then the probe for IRQs may show IRQ = 0. For me, it only did this if
|
|
I first used <CODE>setserial</CODE> to give the IRQ a fictitious value.</P>
|
|
|
|
<H3><A NAME="sets_boot_time"></A> Boot-time Configuration </H3>
|
|
|
|
<P>While <CODE>setserial</CODE> may run via an initialization script,
|
|
something akin to <CODE>setserial</CODE> also runs earlier when the serial
|
|
module is loaded (or when the kernel starts the built-in serial driver
|
|
if it was compiled into the kernel). Thus when you watch the start-up
|
|
messages on the screen it may look like it ran twice, and in fact it
|
|
has. </P>
|
|
<P>If the first message is for a legacy port, the IRQs shown may be wrong
|
|
since it didn't probe for IRQs. If there is a second report of serial
|
|
ports, it may the result of a script such as /etc/init.d/setserial.
|
|
It usually does no probing and thus could be wrong about how the
|
|
hardware is actually set. It only shows configuration data that got
|
|
saved in a configuration files. The old method, prior to setserial
|
|
2.15, was to manually write such data directly into the script.</P>
|
|
<P>When the kernel loads the serial module (or if the "module equivalent"
|
|
is built into the kernel) then all supported PnP ports are detected.
|
|
For legacy (non-PnP) ports, only <CODE>ttyS{0-3}</CODE> are auto-detected
|
|
and the driver is set to use only IRQs 4 and 3 (regardless of what
|
|
IRQs are actually set in the hardware). No probing is done for IRQs
|
|
but it's possible to do this manually. You see this as a boot-time
|
|
message just as if <CODE>setserial</CODE> had been run.</P>
|
|
<P>To correct possible errors in IRQs (or for other
|
|
reasons) there may be a script file somewhere that runs
|
|
<CODE>setserial</CODE>. Unfortunately, if this file has some IRQs wrong, the
|
|
kernel will still have incorrect info about the IRQs. This file is
|
|
usually part of the initialization done at boot-time. Whether it
|
|
runs or not depends on how you (and/or your distribution) have set
|
|
things up. It may also depends on the runlevel. </P>
|
|
<P>Before modifying a configuration file, you can test out a "proposed"
|
|
<CODE>setserial</CODE> command by just typing it on the command line. In some
|
|
cases the results of this use of <CODE>setserial</CODE> will automatically get
|
|
saved somewhere such as /etc/serial.conf (or autoserial.conf or
|
|
serial) when you shutdown. So if it worked OK (and solved your
|
|
problem) then there's no need to modify any configuration file. See
|
|
<A HREF="#config_file">Configuration method using /etc/serial.conf, etc.</A>.</P>
|
|
|
|
<H3><A NAME="old_sets_script"></A> Edit a script (required prior to version 2.15) </H3>
|
|
|
|
<P> This is how it was done prior to <CODE>setserial</CODE> 2.15 (1999)
|
|
The objective was to modify (or create) a script file in the /etc
|
|
tree that runs setserial at boot-time. Most distributions provided
|
|
such a file (but it may not have initially resided in the /etc tree).</P>
|
|
<P>So prior to version 2.15 (1999) it was simpler. All you did was edit
|
|
a script. There was no /etc/serial.conf file (or the like) to
|
|
configure setserial. Thus you needed to find the file that runs
|
|
"setserial" at boot time and edit it. If it didn't exist, you needed
|
|
to create one (or place the commands in a file that ran early at
|
|
boot-time). If such a file was currently being used it's likely
|
|
was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
|
|
in /usr/doc/setserial/ but you need to move it to the /etc tree before
|
|
using it.</P>
|
|
<P>The script <CODE>/etc/rc.d/rc.serial</CODE> was commonly used in the past.
|
|
The Debian distribution used <CODE>/etc/rc.boot/0setserial</CODE>.
|
|
Another file once used was <CODE>/etc/rc.d/rc.local</CODE> but it's may
|
|
not have run early enough. It was reported that other processes may
|
|
try to open the serial port before rc.local ran resulting in serial
|
|
communication failure. Later on it most likely was found in
|
|
/etc/init.d/ but wasn't normally intended to be edited.</P>
|
|
<P>If such a file was supplied, it likely contained a number of
|
|
commented-out examples. By uncommenting some of these and/or
|
|
modifying them, you could set things up correctly. It was important
|
|
use a valid path for <CODE>setserial</CODE>, and a valid
|
|
device name. You could do a test by executing this file manually
|
|
(just type its name as the super-user) to see if it works right.
|
|
Testing like this was a lot faster than doing repeated reboots to get
|
|
it right.</P>
|
|
<P>For versions >= 2.15 (provided your distribution implemented the
|
|
change, Redhat didn't at first) it may be more tricky to do since the
|
|
file that runs setserial on startup, /etc/init.d/setserial or the like
|
|
was not intended to be edited by the user. See
|
|
<A HREF="#config_file">Configuration method using /etc/serial.conf, etc.</A>.</P>
|
|
<P>An example line in such a script was:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>or, if you wanted setserial to automatically determine the uart and the
|
|
IRQ for ttyS3 you would have used something like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>This was done for every serial port you wanted to auto configure,
|
|
using a device name that really does exist on your machine. In some
|
|
cases it didn't work right due to the hardware. </P>
|
|
|
|
<H3><A NAME="config_file"></A> Configuration method using /etc/serial.conf, etc.</H3>
|
|
|
|
<P> Prior to setserial version 2.15 (1999), the way to configure
|
|
setserial was to manually edit the shell-script that ran setserial at
|
|
boot-time. See
|
|
<A HREF="#old_sets_script">Edit a script (before version 2.15)</A>. This was simple, but the simple and clear method has
|
|
been changed to something that is unnecessarily complex. Today the
|
|
script and configuration file are two different files instead of one.
|
|
This shell-script is not edited but gets its data from a configuration
|
|
file such as <CODE>/etc/serial.conf</CODE> (or
|
|
<CODE>/var/lib/setserial/autoserial.conf</CODE>).</P>
|
|
<P>Furthermore you may not even need to edit serial.conf (or the like)
|
|
because using the "setserial" command on the command line may
|
|
automatically cause serial.conf to be edited appropriately. This was
|
|
done so that you may not need to edit any file in order to set up (or
|
|
change) what setserial does each time that Linux is booted.</P>
|
|
<P>What often happens is this: When you shut down your PC the script
|
|
that ran "setserial" at boot-time is run again, but this time it only
|
|
does what the part for the "stop" case says to do: It uses
|
|
"setserial" to find out what the current state of "setserial" is, and
|
|
it puts that info into the serial configuration file such as
|
|
<CODE>serial.conf</CODE>. Thus when you run "setserial" to change
|
|
the serial.conf file, it doesn't get changed immediately but only when
|
|
and if you shut down normally.</P>
|
|
<P>Now you can perhaps guess what problems might occur. Suppose you
|
|
don't shut down normally (someone turns the power off, etc.) and the
|
|
changes don't get saved. Suppose you experiment with "setserial" and
|
|
forget to run it a final time to restore the original state (or make a
|
|
mistake in restoring the original state). Then your "experimental"
|
|
settings are saved. And worst of all, unless you know which options
|
|
were set in the configuration file, you don't know what will happen.
|
|
One option in Debian (and likely other distributions) is known as
|
|
"AUTOSAVE-ONCE" which saves changes only for the first time you make
|
|
them with the setserial command.</P>
|
|
<P>If the option "###AUTOSAVE###" is set and you manually edit
|
|
serial.conf, then your editing is destroyed when you shut down because
|
|
it gets changed back to the state of setserial at shutdown. There is
|
|
a way to disable the changing of serial.conf at shutdown and that is
|
|
to remove "###AUTOSAVE###" or the like from first line of serial.conf.
|
|
In the Debian distribution, the removal of "###AUTOSAVE###" from the
|
|
first line was once automatically done after the first time you
|
|
shutdown just after installation. To retain this effect the
|
|
"AUTOSAVE-ONCE" option was created which only does a save when time
|
|
the system is shut down for the first time (just after you install or
|
|
update the setserial program).</P>
|
|
<P>The file most commonly used to run setserial at boot-time (in
|
|
conformance with the configuration file) is now /etc/init.d/setserial
|
|
(Debian) or /etc/init.d/serial (Redhat), or etc., but it should not
|
|
normally be edited. For 2.15, Redhat 6.0 just had a file
|
|
/usr/doc/setserial-2.15/rc.serial which you have to move to
|
|
/etc/init.d/ if you want setserial to run at boot-time.</P>
|
|
<P>To disable a port, use <CODE>setserial</CODE> to set it to "uart none". This
|
|
will not be saved. The format of /etc/serial.conf appears to be just
|
|
like that of the parameters placed after "setserial" on the command
|
|
line with one line for each port. If you don't use autosave, you may
|
|
edit /etc/serial.conf manually.</P>
|
|
<P>In order to force the current settings set by setserial to be saved to
|
|
the configuration file (serial.conf) without shutting down, do what
|
|
normally happens when you shutdown: Run the shell-script
|
|
<CODE>/etc/init.d/{set}serial stop</CODE>. The "stop" command will save
|
|
the current configuration but the serial ports still keep working OK.</P>
|
|
<P>In some cases you may wind up with both the old and new configuration
|
|
methods installed but hopefully only one of them runs at boot-time.
|
|
Debian labeled obsolete files with "...pre-2.15".</P>
|
|
|
|
<H3>IRQs</H3>
|
|
|
|
<P> By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and
|
|
ttyS3 share IRQ 3. But while sharing serial interrupts (using them in
|
|
running programs) is OK for the PCI bus, it's not permitted for the
|
|
ISA bus unless you: 1. have kernel 2.2 or better, and 2. you've
|
|
compiled in support for this, and 3. your serial hardware supports it.
|
|
See
|
|
Serial-HOWTO: Interrupt sharing and Kernels 2.2+.</P>
|
|
|
|
<P>If you only have two serial ports, ttyS0 and ttyS1, you're still OK
|
|
since IRQ sharing conflicts don't exist for non-existent devices.</P>
|
|
<P>If you add a legacy internal modem (without plug-and-play) and retain
|
|
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
|
|
it in your serial port (or modem card) and then use setserial to
|
|
assign it to your device driver. If IRQ 5 is not being used for a
|
|
sound card, this could be used for a modem.</P>
|
|
|
|
<H3><A NAME="laptops_"></A> Laptops: PCMCIA </H3>
|
|
|
|
<P>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
|
|
configuration. For serial ports on the motherboard, setserial is used
|
|
just like it is for a desktop. But for PCMCIA cards (such as a modem)
|
|
it's a different story. The configuring of the PCMCIA system should
|
|
automatically run setserial so you shouldn't need to run it. If you
|
|
do run it (by a script file or by /etc/serial.conf) it might be
|
|
different and cause trouble. The autosave feature for serial.conf
|
|
shouldn't save anything for PCMCIA cards (but Debian did until
|
|
2.15-7). Of course, it's always OK to use setserial to find out how
|
|
the driver is configured for PCMCIA cards.</P>
|
|
|
|
|
|
<H2><A NAME="stty_"></A> <A NAME="ss15.4">15.4</A> <A HREF="Text-Terminal-HOWTO.html#toc15.4">Stty </A>
|
|
</H2>
|
|
|
|
<H3>Introduction</H3>
|
|
|
|
<P> <CODE>stty</CODE> does much of the configuration of the serial port but
|
|
since application programs (and the getty program) often handle this,
|
|
you may not need to use it much. It's handy if you're having problems
|
|
or want to see how the port is set up. It also configures the terminal
|
|
interface which is not only used by the serial port but is also used
|
|
anytime you use a command-line interface in Linux. Try typing ``stty
|
|
-a'' at your terminal/console to see how it's now set. Also try typing
|
|
it without the -a (all) for a short listing which shows how it's set
|
|
different than "normal" which is how it's set using the command
|
|
<CODE>"stty sane"</CODE>. Don't try to learn all the settings unless you
|
|
want to become a serial historian since many of the settings are only
|
|
for slow antique dumb terminals of the 1970's. Most of the defaults
|
|
should work OK.</P>
|
|
<P><CODE>stty</CODE> is documented in the man pages with a more detailed account
|
|
in the info pages. Type <CODE>"man stty"</CODE> or <CODE>"info stty"</CODE>.</P>
|
|
<P>Many of the stty options (or settings) start with an "o" (output) or an
|
|
"i" (input). For example: <CODE>onlcr</CODE>. Output is the flow of bytes out
|
|
of the computer while input is the flow of bytes into the computer. The
|
|
"point of view" is the computer, not the serial port or the device
|
|
connected to the serial port. For example, received input data comes in
|
|
on a cable and goes to the serial port chip. This chip, after
|
|
converting the bits from the serial to parallel representation, then
|
|
sends it (via a program read) to the large serial port buffer in main
|
|
computer memory. Thus the chip has both input and output but since it's
|
|
input data to the computer, its output is considered to be input. The
|
|
situation is similar for output flowing thru this chip. The "input" and
|
|
"output" refer to the direction of flow with respect to the computer and
|
|
not the serial port hardware (the chip).</P>
|
|
<P>Whereas <CODE>setserial</CODE> only deals with actual serial ports, stty is used
|
|
for terminals regardless of whether they are accesses via a serial port,
|
|
network, or by a virtual terminal on Linux PC monitor, or a GUI
|
|
terminal window such as xterm. For the PC monitor, xterm, or a network
|
|
many of the stty settings are meaningless. Changing the baud rate, etc.
|
|
doesn't appear to actually do anything.</P>
|
|
<P>Here are some of the items stty configures: speed (bits/sec), parity,
|
|
bits/byte, # of stop bits, strip 8th bit?, modem control signals, flow
|
|
control, break signal, end-of-line markers, change case, padding, beep
|
|
if buffer overrun?, echo what you type to the screen, allow background
|
|
tasks to write to terminal?, define special (control) characters (such
|
|
as what key to press for interrupt). See the <CODE>stty</CODE> man or info
|
|
page for more details. Also see the man page: <CODE>termios</CODE> which
|
|
covers the same options set by stty but (as of mid 1999) covers
|
|
features which the stty man page fails to mention.
|
|
For use of some special characters see
|
|
<A HREF="#stty_chars">Special (Control) Characters</A></P>
|
|
<P>With some implementations of getty (getty_ps package), the commands
|
|
that one would normally give to stty are typed into a getty
|
|
configuration file: /etc/gettydefs. Even without this configuration
|
|
file, the getty command line may be sufficient to set things up so
|
|
that you don't need stty.</P>
|
|
<P>One may write C programs which change the stty configuration, etc.
|
|
Looking at some of the documentation for this may help one better
|
|
understand the use of the stty command (and its many possible
|
|
arguments). Serial-Programming-HOWTO may be useful but it's outdated.
|
|
The manual page: termios contains a description of the C-language
|
|
structure (of type termios) which stores the stty configuration in
|
|
computer memory. Many of the flag names in this C-structure are
|
|
almost the same (and do the same thing) as the arguments to the stty
|
|
command.</P>
|
|
|
|
<H3>Flow control options</H3>
|
|
|
|
<P> To set hardware flow control use "crtscts". For software flow
|
|
control there are 3 settings: ixon, ixoff, and ixany.</P>
|
|
<P>ixany: Mainly for terminals. Hitting any key will restart the flow
|
|
after a flow-control stop. If you stop scrolling with the "stop
|
|
scroll" key (or the like) then hitting any key will resume scrolling.
|
|
It's seldom needed since hitting the "scroll lock" key again will do
|
|
the same thing.</P>
|
|
<P>ixon: Enables the port to listen for Xoff and to stop transmitting
|
|
when it gets an Xoff. Likewise, it will resume transmitting if it gets
|
|
an Xon.</P>
|
|
<P>ixoff: enables the port to send the Xoff signal out the transmit line
|
|
when its buffers in main memory are nearly full. It protects the
|
|
device where the port is located from being overrun.</P>
|
|
<P>For a slow dumb terminal (or other slow device) connected to a fast
|
|
PC, it's unlikely that the PC's port will be overrun. So you seldom
|
|
actually need to enable ixoff. But it's often enabled "just in case".</P>
|
|
|
|
<H3>Using stty at a "foreign" terminal</H3>
|
|
|
|
<P>How do you use stty to view or set a terminal other than the
|
|
terminal you are currently using? It's usually impossible to do it if
|
|
the foreign terminal is in use and has a shell running on it. In
|
|
other cases for dealing with say ttyS2 while typing at another
|
|
terminal (such as tty1) use <CODE> stty -F /dev/ttyS2 ...</CODE> (or
|
|
--file instead of F). If ... is -a it displays all the stty settings
|
|
(-a means all).</P>
|
|
<P>But if the foreign terminal (ttyS2 in this example) has a shell
|
|
running on it, then what you see will likely be deceptive and trying
|
|
to set it will not work. This problem exists for virtual terminals
|
|
also such as dealing with tty3 from tty1, etc. See
|
|
<A HREF="#two_term_interfaces">Two interfaces at a terminal</A> to
|
|
understand it.</P>
|
|
|
|
<H3><A NAME="two_term_interfaces"></A> Two interface modes at a terminal </H3>
|
|
|
|
<P> When using a shell (such as bash) with command-line-editing
|
|
enabled there are two different terminal interfaces (or line
|
|
disciplines: what you see when you type stty -a). When you type in
|
|
modern shells at the command line you have a temporary "raw" interface
|
|
(or raw mode) where each character is read by the shell's
|
|
command-line-editor as you type it. Once you hit the <return>
|
|
key, the command-line-editor is exited and the terminal interface is
|
|
changed from raw to the nominal "cooked" interface (cooked mode) for the
|
|
terminal using the stty configuration that was used for the last cooked
|
|
mode (the shell has saved it and it gets restored). This cooked mode
|
|
lasts until the next prompt is sent to the terminal (which is only a
|
|
small fraction of a second) but it exists during the execution of the
|
|
command (or at least during the first stage of the command execution).
|
|
Note that one never gets to type any command into this cooked mode but
|
|
what was typed in raw mode on the command line starts execution by the
|
|
shell while in cooked mode.</P>
|
|
<P>When a prompt is sent to the terminal, the terminal goes from "cooked"
|
|
to "raw" mode (just like it does when you start an editor such as vim.
|
|
The prompt signals starting the command-line editor. The settings for
|
|
the "raw" mode are based only on the basic stty settings taken from the
|
|
"cooked" mode. Raw mode keeps these setting but changes several other
|
|
settings in order to change the mode to "raw". It is not at all based
|
|
on the settings used in the previous "raw" mode (as contrasted to
|
|
"cooked" mode which gets restored by the shell to its previous
|
|
settings). Thus if one uses stty to change settings for the raw mode,
|
|
such settings will be permanently lost as soon as one hits the
|
|
<return> key at the terminal.</P>
|
|
<P>Now when one types stty to look at the terminal interface, one may
|
|
either get a view of the cooked mode or the raw mode. You need to
|
|
figure out which one you're looking at. It you use stty from a
|
|
foreign terminal (other than the terminal you are currently typing at)
|
|
then you will likely see the raw mode settings since the terminal is in raw
|
|
mode almost all the time. Any changes made will only be made to the raw
|
|
mode and will be lost when someone presses <return> at the foreign
|
|
terminal you tried to "set". But if you type a stty command to
|
|
view/change the configuration of the terminal you are using, and then
|
|
hit <return> it's a different story. The <return> puts the
|
|
terminal in cooked mode and your changes are saved by the shell before it
|
|
returns to raw mode. Since going into raw mode doesn't change all stty
|
|
settings, some of the changes you made via stty may still be present in
|
|
raw mode and will not get destroyed by <return>.</P>
|
|
<P>This situation can create problems. For example, suppose you corrupt
|
|
your terminal interface so that it's not displaying what you type, etc.
|
|
To restore it you go to another terminal (on the same PC) and type "stty
|
|
-F dev/ttyS1 sane" (or the like). It will not work because the terminal
|
|
is in raw mode! Of course you can try to type "stty sane ..." at the
|
|
terminal that is corrupted but you can't see what you typed. All the
|
|
above not only applies to dumb terminals but to virtual terminals used
|
|
on a PC Monitor as well as to the terminal windows in X. In other
|
|
words, it applies to almost everyone who uses Linux.</P>
|
|
<P>Luckily, when you start up Linux, any file that runs stty at boot-time
|
|
will likely deal with a terminal (or serial port with no terminal)
|
|
that has no shell running on it so there's no problem for this special
|
|
case.</P>
|
|
|
|
<H3><A NAME="stty_where"></A> Where to put the stty command ? </H3>
|
|
|
|
<P> Should you need to have <CODE>stty</CODE> set up the serial interface each
|
|
time the computer starts up then you need to put the <CODE>stty</CODE> command
|
|
in a file that will be executed each time the computer is started up
|
|
(Linux boots). It should be run before the serial port is used
|
|
(including running getty on the port). There are many possible places
|
|
to put it. If it gets put in more than one place and you only know
|
|
about (or remember) one of those places, then a conflict is likely.
|
|
So make sure to document what you do.</P>
|
|
<P>One place to put it would be in the same file that runs setserial when
|
|
the system is booted. The location is distribution and version
|
|
dependent. It would seem best to put it after the setserial command
|
|
so that the low level stuff is done first. If you have directories in
|
|
the /etc tree where every file in them is executed at boot-time
|
|
(System V Init) then you could create a file named "stty" for this
|
|
purpose.</P>
|
|
|
|
<H3>Obsolete redirection method</H3>
|
|
|
|
<P>Prior to about 2000 you needed to use the redirection operator "<"
|
|
if you wanted to use stty on a foreign terminal. For example to use
|
|
stty on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2.
|
|
After 2000 (provided your version of setserial is >= 1.17 and stty >=
|
|
2.0) a better method was created using the -F option: stty -F
|
|
/dev/ttyS2. This will work when the old redirection method fails. </P>
|
|
<P>The old redirection example above makes ttyS2 the standard input to
|
|
stty. This gives the stty program a link to the "file" ttyS2 so that
|
|
it may "read" it. But instead of reading the bytes sent to ttyS2 as
|
|
one might expect, it uses the link to find the configuration settings
|
|
of the port so that it may read or change them. In olden days, some
|
|
people tried to use ``stty ... > /dev/ttyS2'' to set the terminal.
|
|
This didn't work. Instead, it takes the message normal displayed
|
|
by the stty command for the terminal you are on (say tty1) and sends
|
|
this message to ttyS2. But it doesn't change any settings for ttyS2.</P>
|
|
<P>Here's a problem with the old redirection operator (which doesn't
|
|
happen if you use the newer -F option instead). Sometimes when trying
|
|
to use stty, the command hangs and nothing happens (you don't get a
|
|
prompt for a next command even after hitting <return>). This is
|
|
likely due to the port being stuck because it's waiting for one of the
|
|
modem control lines to be asserted. For example, unless you've set
|
|
"clocal" to ignore modem control lines, then if no CD signal is
|
|
asserted the port will not open and stty will not work for it (unless
|
|
you use the newer -F option). A similar situation seems to exist for
|
|
hardware flow control. If the cable for the port doesn't even have a
|
|
conductor for the pin that needs to be asserted then there is no easy
|
|
way to stop the hang.</P>
|
|
<P>One way to try to get out of the above hang is to use the newer -F
|
|
option and set "clocal" and/or "crtscts" as needed. If you don't have
|
|
the -F option then you may try to run some program (such as minicom) on
|
|
the port that will force it to operate even if the control lines say
|
|
not to. Then hopefully this program might set the port so it doesn't
|
|
need the control signal in the future in order to open: clocal or
|
|
-crtscts. To use "minicom" to do this you likely will have to
|
|
reconfigure minicom and then exit it and restart it. Instead of all
|
|
this bother, it may be simpler to just reboot the PC or via using a
|
|
virtual terminal kill the process using "top" (or "ps" to get the
|
|
process number and then "kill" to kill that process.</P>
|
|
<P>The obsolete redirection method (which still works in later versions)
|
|
is to type ``stty ... < /dev/ttyS2''. If the new method using -F
|
|
works but the obsolete one hangs, it implies that the port is hung due
|
|
to a modem control line not being asserted. Thus the obsolete
|
|
redirection method might still useful for troubleshooting.</P>
|
|
|
|
|
|
<H2><A NAME="termcap1"></A> <A NAME="ss15.5">15.5</A> <A HREF="Text-Terminal-HOWTO.html#toc15.5">Terminfo & Termcap (brief) </A>
|
|
</H2>
|
|
|
|
<P> See
|
|
<A HREF="#termcap2">Terminfo and Termcap (detailed)</A> for
|
|
a more detailed discussion of termcap. Many application programs that
|
|
you run use the terminfo (formerly termcap) data base. This has an
|
|
entry (or file) for each model or type (such as vt100) of terminal and
|
|
tells what the terminal can do, what codes to send for various
|
|
actions, and what codes to send to the terminal to initialize it.</P>
|
|
<P>Since many terminals (and PC's also) can emulate other terminals and
|
|
have various "modes" of operation, there may be several terminfo
|
|
entries from which to choose for a given physical terminal. They
|
|
usually will have similar names. The last parameter of getty (for
|
|
both agetty and getty_ps) should be the terminfo name of the terminal
|
|
(or terminal emulation) that you are using (such as vt100).</P>
|
|
<P>The terminfo does more than just specify what the terminal is capable
|
|
of doing and disclose what codes to send to the terminal to get it to
|
|
do those things. It also specifies what "bold" will look like (will
|
|
it be reverse video or will it be high intensity, etc.), what
|
|
the cursor will look like, if the letters will be black, white, or
|
|
some other color, etc. In PC terminology these are called
|
|
"preferences". It also specifies initialization codes to send to the
|
|
terminal (analogous to the init strings sent to modems). Such strings
|
|
are not automatically sent to the terminal by Linux. See
|
|
<A HREF="#init_string">Init String</A>. If you don't like the way the
|
|
display on the screen looks and behaves you may need to edit (and then
|
|
update) the terminfo (or termcap) file. See
|
|
<A HREF="#tic">Terminfo Compiler (tic)</A> for how to update.</P>
|
|
|
|
<H2><A NAME="ss15.6">15.6</A> <A HREF="Text-Terminal-HOWTO.html#toc15.6">Setting TERM and TERMINFO</A>
|
|
</H2>
|
|
|
|
<P> These are two environment variables for terminals: TERM and
|
|
TERMINFO, but you may not need to do anything about them. TERM must
|
|
always be set to the type of the terminal you are using (such as
|
|
vt100). If you don't know the type (name) see
|
|
<A HREF="#term_name">What is the terminfo name of my terminal ?</A>. TERMINFO contains
|
|
the path to the terminfo data base, but may not be needed if the
|
|
database is in a default location (or TERMINFO could be set
|
|
automatically by a file that comes with your distribution of Linux).
|
|
You may want to look at
|
|
<A HREF="#tc_compiled_locs"> Compiled database locations</A>.</P>
|
|
<P>Fortunately, the getty program usually sets TERM for you just before
|
|
login. It just uses the terminal type that was specified on getty's
|
|
command line (in /etc/inittab). This permits application programs to
|
|
find the name of your terminal and then look up the terminal
|
|
capabilities in the terminfo data base. See
|
|
<A HREF="#term_var">TERM Variable</A> for more details on TERM.</P>
|
|
<P>If your terminfo data base can't be found you may see an error message
|
|
about it on your terminal. If this happens it's time to check out
|
|
where terminfo resides and set TERMINFO if needed. You may find out
|
|
where the terminfo database is by searching for a common terminfo file
|
|
such as "vt100" using the "locate" command. Make sure that your
|
|
terminal is in this database. An example of setting TERMINFO is:
|
|
export TERMINFO=/usr/share/terminfo (put this in /etc/profile or the
|
|
like). If the data for your terminal in this data base is not to your
|
|
liking, you may need to edit it. See
|
|
<A HREF="#termcap1">Terminfo & Termcap (brief)</A>.</P>
|
|
|
|
<H3><A NAME="term_name"></A> What is the terminfo name of my terminal ? </H3>
|
|
|
|
<P> You need the exact name in order to set the TERM environment
|
|
variable or to give to <CODE>getty</CODE>. The same name should be used by
|
|
both the termcap and terminfo databases so you only need to find it
|
|
once. A terminal usually has alias names but if more than one name is
|
|
shown, use the first one.</P>
|
|
<P>To find it, try looking at the /etc/termcap... file (if you have it).
|
|
If not, then either look at the terminfo trees (see
|
|
<A HREF="#tc_compiled_locs"> Compiled database locations</A>) or try to
|
|
find the terminfo source code file (see
|
|
<A HREF="#tc_source_loc">Source-code database locations</A>.</P>
|
|
|
|
<H2><A NAME="ss15.7">15.7</A> <A HREF="Text-Terminal-HOWTO.html#toc15.7">Rarely Needed /etc/ttytype File</A>
|
|
</H2>
|
|
|
|
<P> The configuration file /etc/ttytype is used to map /dev/ttySn's to
|
|
terminal names per terminfo. tset/reset uses it, but if the TERM
|
|
environment variable is already set correctly, then this file is not
|
|
needed. Since the Linux getty sets TERM for each tty, you don't need
|
|
this file. In other Unix-like systems such as FreeBSD, the file
|
|
/etc/ttys maps ttys to much more, such as the appropriate getty
|
|
command, and the category of connection (such as "dialup"). An
|
|
example line of Linux ttytype: vt220 ttyS1</P>
|
|
|
|
<H2><A NAME="login_restr"></A> <A NAME="ss15.8">15.8</A> <A HREF="Text-Terminal-HOWTO.html#toc15.8">Login Restrictions </A>
|
|
</H2>
|
|
|
|
<P> By default, the root user may not login from a terminal. To
|
|
permit this you must create (or edit) the file /etc/securetty per the
|
|
manual page "securetty". To restrict logins of certain users and/or
|
|
certain terminals, etc. edit /etc/login.access (this replaces the old
|
|
/etc/usertty file ??). /etc/login.def determines if /etc/securetty is
|
|
to be used and could be edited so as to make /etc/securetty not needed
|
|
(or not used). /etc/porttime restricts the times at which certain
|
|
ttys and users may use the computer. If there are too many failed
|
|
login attempt by a user, that user may be prohibited from ever logging
|
|
in again. See the man page "faillog" for how to control this.</P>
|
|
|
|
<H2><A NAME="ss15.9">15.9</A> <A HREF="Text-Terminal-HOWTO.html#toc15.9">Run Command Only If TERM=my_term_type</A>
|
|
</H2>
|
|
|
|
<P> Sometimes there are commands that one wants to execute at start-up
|
|
only for a certain type of terminal. To do this for the stty command
|
|
is no problem since one uses the redirection operator < to specify
|
|
which terminal the command is for. But what about shell aliases or
|
|
functions? You may want to make a function for the ls command so it
|
|
will color-code the listing of directories only on color terminals or
|
|
consoles. For monochrome terminals you want the same function name
|
|
(but a different function body) which will use symbols as a substitute
|
|
for color-coding. Where to put such function definitions that are
|
|
to be different for different terminals?</P>
|
|
<P>You may put them inside an "if" statement in /etc/profile which runs
|
|
at startup each time one logs on. The conditional "if" statement
|
|
defines certain functions, etc. only if the terminal is of a
|
|
specified type.</P>
|
|
|
|
<H3><A NAME="ls_color"></A> Example for ls Function </H3>
|
|
|
|
<P> While much of what this if statement does could be done in the
|
|
configuration file for dircolors, here's an example for the case of
|
|
the bash shell. It makes the <EM>ls</EM> command display colors if the
|
|
terminal is "linux" but uses <EM>ls -F</EM> if you're using a dumb
|
|
terminal (VT220). Note that the -F option uses symbols to give
|
|
information on file types just like color coding does. So there are
|
|
alternatives to using colors for the <EM>ls</EM> command, although a color
|
|
display may look more impressive.</P>
|
|
<P>
|
|
<HR>
|
|
<PRE>
|
|
if [ "$TERM" = linux ]; then
|
|
eval `dircolors`;
|
|
elif [ "$TERM" = vt220 ]; then
|
|
ls () { command ls -F $* ; }# to export the function ls():
|
|
declare -xf ls
|
|
else echo "From /etc/profile: Unknown terminal type $TERM"
|
|
fi
|
|
</PRE>
|
|
<HR>
|
|
</P>
|
|
|
|
<H2><A NAME="mapchan_"></A> <A NAME="ss15.10">15.10</A> <A HREF="Text-Terminal-HOWTO.html#toc15.10">Character Mapping: mapchan </A>
|
|
</H2>
|
|
|
|
<P> There is a free program named "mapchan" which will map characters
|
|
(bytes) typed at a terminal keyboard (input) into different characters
|
|
per a user-supplied mapping table. It can also map characters which
|
|
are sent to the screen (output). This is nice for remapping the
|
|
keyboard for foreign language alphabets. Most distributions don't
|
|
seem to supply it (let me know if any do). Source code by Yura
|
|
Kalinichenko (Ukraine, partly in Russian )
|
|
<A HREF="http://sourceforge.net/projects/mapchan/">download mapchan etc.</A></P>
|
|
|
|
<HR>
|
|
<H2><A NAME="termcap2"></A> <A NAME="s16">16.</A> <A HREF="Text-Terminal-HOWTO.html#toc16">Terminfo and Termcap (detailed) </A></H2>
|
|
|
|
<H2><A NAME="ss16.1">16.1</A> <A HREF="Text-Terminal-HOWTO.html#toc16.1">Intro to Terminfo</A>
|
|
</H2>
|
|
|
|
<P> Terminfo (formerly Termcap) is a database of terminal capabilities
|
|
and more. For every (well almost) model of terminal it tells
|
|
application programs what the terminal is capable of doing. It tells
|
|
what escape sequences (or control characters) to send to the terminal
|
|
in order to do things such as move the cursor to a new location, erase
|
|
part of the screen, scroll the screen, change modes, change appearance
|
|
(colors, brightness, blinking, underlining, reverse video etc.).
|
|
After about 1980, many terminals supported over a hundred different
|
|
commands (some of which take numeric parameters).</P>
|
|
<P>One way in which terminfo gives the its information to an application
|
|
program is via the "ncurses" functions that a programmer may put into
|
|
a C program. For example, if a program wants to move the cursor to row
|
|
3, col 6 it simply calls: move(3,6). The move() function (part of
|
|
ncurses) knows how to do this for your terminal (it has read
|
|
terminfo). So it sends the appropriate escape sequence to the
|
|
terminal to make this particular move for a certain terminal.
|
|
Some programs get info directly from a terminfo files without using
|
|
ncurses. Thus a Linux package that doesn't require ncurses may still
|
|
need a terminfo file for your terminal.</P>
|
|
<P>The terminfo abbreviations are usually longer than those of termcap
|
|
and thus it's easier to guess what they mean. The manual pages for
|
|
terminfo are more detailed (and include the old termcap
|
|
abbreviations). Also, the termcap entries had a size limitation which
|
|
is not present for terminfo. Thus, unless you are already committed
|
|
to working with termcap, it's suggested you use terminfo.</P>
|
|
|
|
<H2><A NAME="database"></A> <A NAME="ss16.2">16.2</A> <A HREF="Text-Terminal-HOWTO.html#toc16.2">Terminfo Database </A>
|
|
</H2>
|
|
|
|
<H3>Introduction</H3>
|
|
|
|
<P> The terminfo database is compiled and thus has a source part and a
|
|
compiled part. The old termcap database has only a source part but
|
|
this source can, by a single command, be both converted to terminfo
|
|
source and then compiled. Thus you may get by without having any
|
|
terminfo source since the termcap source can create the compiled
|
|
terminfo database. To see a display of the database for the terminal
|
|
you're now using (including a PC monitor) type "infocmp" and you
|
|
should see the source terminfo "file" for it.</P>
|
|
<P>To see if your terminal (say vt100) is in the terminfo data base type
|
|
"locate vt100". If you need to find the terminfo name for your
|
|
terminal, explore the listing of files in the compiled database or see
|
|
<A HREF="#term_name">What is the terminfo name of my terminal ?</A></P>
|
|
|
|
<H3>Where is the database located ?</H3>
|
|
|
|
<H3><A NAME="tc_compiled_locs"></A> Compiled database locations </H3>
|
|
|
|
<P> Typing "locate vt100" may show /usr/lib/terminfo/v/vt100,
|
|
/usr/share/terminfo/v/vt100, /home/.../.terminfo/v/vt100, and/or
|
|
/etc/terminfo/v/vt100. All these are possible locations of the
|
|
compiled terminfo files. Although the /etc/terminfo directory is not
|
|
a standard location for it, having a few terminal types there could be
|
|
useful in case the /usr directory is not accessible. For example /usr
|
|
could be on a separate disk or partition that failed to mount.
|
|
Normally, programs that use your main terminfo data base are able to
|
|
find it if it's in at least one of the locations mentioned above.
|
|
Otherwise the environment variable TERMINFO may be set to the path to
|
|
this database. Example: TERMINFO=/usr/share/terminfo</P>
|
|
<P>For the Debian Distribution of Linux, several commonly used terminals
|
|
(including the monitor-console) are in the ncurses-term package.
|
|
These are put into /etc/terminfo/. All of the terminals in the
|
|
database are in the ncurses-bin package and go into
|
|
/usr/share/terminfo/.</P>
|
|
<P>If the compiled terminfo is in more than one location, everything is
|
|
usually OK until someone installs new terminfo files (from a newer
|
|
distribution, from the net, by editing the old one, etc.). Each new
|
|
terminfo file should replace all the existing older copies of that file
|
|
(at various locations) unless you abolish redundant locations. If you
|
|
don't ensure this gets done, then some application programs could wind
|
|
up still finding and using the old (and possibly buggy) terminfo data
|
|
that sill exists in a "possible" location. Setting the environment
|
|
variable TERMINFO to the up-to-date location (as mentioned above)
|
|
would help avoid this problem.</P>
|
|
|
|
<H3><A NAME="tc_source_loc"></A> Source-code database locations </H3>
|
|
|
|
<P> While the source-code file may not be installed on your computer
|
|
there's another way to get the source-code if you have the compiled
|
|
code. Just use the "<CODE>infocmp</CODE>" command.</P>
|
|
<P>The source code file (for all terminals) may be /etc/termcap and/or
|
|
terminfo.src (or another name). See the man pages: terminfo(5) or
|
|
termcap(5) for the format required to create (or modify) these source
|
|
files. The file terminfo.src may be in various locations on your
|
|
computer or it may not be included with your Linux distribution. Use
|
|
the <CODE>locate</CODE> command to try to find it. It is available on the web
|
|
at
|
|
<A HREF="http://catb.org/terminfo/">http://catb.org/terminfo/</A>.</P>
|
|
|
|
<H3><A NAME="tic"></A> Terminfo Compiler (tic) </H3>
|
|
|
|
<P> The data in the source files is compiled with the "tic" program
|
|
which is capable of converting between termcap format and terminfo
|
|
format. Thus you can create a compiled terminfo data base from
|
|
termcap source. The installation program which was used to install
|
|
Linux probably installed the compiled files on your hard disk so you
|
|
don't need to compile anything unless you modify /etc/termcap (or
|
|
terminfo.src ). "tic" will automatically install the resulting
|
|
compiled files into a terminfo directory ready to be used by
|
|
application programs. Which location it's installed in depends on ...
|
|
See "man tic" for the explanation.</P>
|
|
|
|
<H3><A NAME="infocmp"></A> Look at Your Terminfo </H3>
|
|
|
|
<P> It's a good idea to take a look at the terminfo entry for the
|
|
terminal you are using (source code of course) and read the comments.
|
|
A quick way to inspect it without comments is to just type "infocmp".
|
|
But the comments may tell you something special about the terminal
|
|
such as how you need to set it up so that it will work correctly with
|
|
the terminfo database.</P>
|
|
|
|
<H3>Deleting Data Not Needed</H3>
|
|
|
|
<P> In order to save disk space, one may delete all of the terminfo
|
|
database except for the terminals types that you have (or might need
|
|
in the future). Don't delete any of the termcaps for a "Linux
|
|
terminal" (the console) or the ones used for x-terminal-emulation
|
|
such as xterm. The terminal type "dumb" may be needed when an
|
|
application program can't figure out what type of terminal you are
|
|
using. It would save disk space if install programs only installed
|
|
the terminfo for the terminals that you have and if you could get a
|
|
termcap for a newly installed terminal over the Internet in a few
|
|
seconds.</P>
|
|
|
|
<H2><A NAME="ss16.3">16.3</A> <A HREF="Text-Terminal-HOWTO.html#toc16.3">Bugs in Existing Terminfo Files (and Hardware)</A>
|
|
</H2>
|
|
|
|
<P> Unfortunately, there are a number of bugs in the terminfo and
|
|
termcap files. In addition, many of these terminfo files are
|
|
incomplete and do not define certain features available on the
|
|
terminals. Sometimes you can get by without modifying the terminfo
|
|
but in other cases you need to modify it or possibly use another
|
|
emulation that has a good terminfo.</P>
|
|
<P>The sad state of the supplied terminfo files is due to a number of
|
|
reasons. One is that during the 1980's when many of them were written
|
|
(often in termcap format), application programs did not utilize more
|
|
advanced terminal features. Thus if such feature were not in the
|
|
termcap (or terminfo) file, no one complained. Also, writing termcaps
|
|
was often done by volunteers who were in short supply. Today,
|
|
programs such as vim use "context highlighting" and minicom uses the
|
|
terminal's graphics character set. These often need more definitions
|
|
to be added to the old termcap. This may (or may not) have already
|
|
been done.</P>
|
|
<P>Most terminals had hardware bugs (in their firmware) and sometimes
|
|
these were "fixed" by modifying the termcap. Then the manufacturer
|
|
might send out replacement chips which would fix the bug. Not all
|
|
owners would bother to get the replacement chips. Thus there may be 2
|
|
or more terminfos for your terminal, depending on what firmware chips
|
|
it has in it. This situation was often not noted in the termcap and
|
|
only one of these termcaps may be supplied with Linux. Some hardware
|
|
bugs which existed for features that were almost never used in the
|
|
past likely never did get fixed. Also, some reported hardware bugs
|
|
may never have been fixed since they were not of much significance at
|
|
the time or because the terminal manufacturing company went out of
|
|
business, etc.</P>
|
|
|
|
<H2><A NAME="ss16.4">16.4</A> <A HREF="Text-Terminal-HOWTO.html#toc16.4">Modifying Terminfo Files</A>
|
|
</H2>
|
|
|
|
<P> To do this you need a manual for your terminal showing what escape
|
|
sequences it uses. Newer manuals from the 1990's often don't show
|
|
this. You also need a terminfo manual (the man page "terminfo" is
|
|
one). After you edit the terminfo source file you compile it using
|
|
"tic". "tic" should automatically put the compiled terminfo file in
|
|
the correct directory reserved for it.</P>
|
|
<P>If you would like to find a better terminfo entry for a certain terminal
|
|
than the one supplied, you might try searching the Internet (but what
|
|
you find could be worse). If your new terminfo entry is better than
|
|
the old one and it seems stable (you've used it for a while with no
|
|
problems) then you should send a copy to the maintainer of terminfo as
|
|
noted at the start of the source file for terminfo (or termcap).</P>
|
|
|
|
<H2><A NAME="init_string"></A> <A NAME="ss16.5">16.5</A> <A HREF="Text-Terminal-HOWTO.html#toc16.5">Init String </A>
|
|
</H2>
|
|
|
|
<P> Included in the terminfo are often a couple of initialization
|
|
strings which may be sent to the terminal to initialize it. This may
|
|
change the appearance of the screen, change what mode the terminal is
|
|
in, and/or make the terminal emulate another terminal. No
|
|
initialization string is automatically sent to the terminal to
|
|
initialize it. One might expect that the getty program should do
|
|
this. If it did, one could make a change to the set-up stored inside
|
|
the terminal but this change wouldn't happen because the init string
|
|
would override it. Application programs don't seem to initialize
|
|
(send an init string per terminfo) either.</P>
|
|
<P>To actually send an init string you must use a command given on the
|
|
command line (or in a shell script such as /etc/profile). Such
|
|
commands are: "reset" "tset", "tput init", or "setterm -initialize".
|
|
Sometimes there is no need to send an init string since the terminal
|
|
may set itself up correctly when it is powered on (using
|
|
options/preferences one has set up and saved in the non-volatile
|
|
memory of the terminal).</P>
|
|
|
|
<H2><A NAME="term_var"></A> <A NAME="ss16.6">16.6</A> <A HREF="Text-Terminal-HOWTO.html#toc16.6">TERM Variable </A>
|
|
</H2>
|
|
|
|
<P> The Environment variable TERM should be set to the name of
|
|
terminal which you are using. If TERM hasn't been set yet and you
|
|
don't know the name of your terminal see
|
|
<A HREF="#term_name">What is the terminfo name of my terminal ?</A>. It is normally
|
|
set by the terminal_type parameter passed to the getty program (look
|
|
at it in the /etc/inittab file). This name must be in the Terminfo
|
|
data base. Just type "set" at the command line to see what TERM is
|
|
set to (or type: tset -q). At a console (monitor) TERM is set to
|
|
"linux" which is the PC monitor emulating a fictitious terminal model
|
|
named "linux". Since "linux" is close to a vt100 terminal and many
|
|
text terminals are also, the "linux" designation will sometimes work
|
|
as a temporary expedient with a text terminal.</P>
|
|
<P>If more than one type of terminal may be connected to the same port
|
|
(/dev/ttyS...) (for example, if there is a switch to permit different
|
|
terminal types to use the same serial port, or if the port is
|
|
connected to a modem to which people call in from different types of
|
|
terminals) then TERM needs to be set each time someone connects to the
|
|
serial port. There is often a query escape sequence so that the
|
|
computer may ask the terminal what type it is. Another way is to ask
|
|
the user to type in (or select) the type of terminal s/he is using.
|
|
You may need to use tset for this or write a short shell script to
|
|
handle this.</P>
|
|
<P>
|
|
<A NAME="reset_"></A>
|
|
One way to do this is to use "reset" (same as "tset"; see the manual
|
|
page). reset tries to determine the terminal name of the terminal you
|
|
are using. Then it looks up the data in terminfo and sends your
|
|
terminal an init string. It can also set the value of TERM. For
|
|
example, a user dials in and logs in. The .profile login script is
|
|
executed which contains within it the following statement: eval `tset
|
|
-s ?vt100`. This results in: The user is asked if s/he is using a
|
|
vt100. The user either responds yes or types in the actual terminal
|
|
type s/he is using. Then "reset" sends the init string and sets TERM
|
|
to this terminal name (type).</P>
|
|
|
|
<H2><A NAME="termcap_docs"></A> <A NAME="ss16.7">16.7</A> <A HREF="Text-Terminal-HOWTO.html#toc16.7">Terminfo/Termcap Documents </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> manual pages for terminfo(5) (best) and/or termcap(5).
|
|
<A HREF="http://www.delorie.com/gnu/docs/termcap/termcap_toc.html">The Termcap Manual</A> (2nd ed.) by Richard M. Stallman is a GNU
|
|
manual also known as the "Termcap Library". It's somewhat obsolete
|
|
since it doesn't include terminfo. It's also at:
|
|
<A HREF="http://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html">Termcap Library</A></LI>
|
|
<LI> the files: terminfo.src and
|
|
/etc/termcap have info about various versions of termcap files,
|
|
naming conventions for terminals, and special capabilities code named
|
|
u6-u9. If you don't have one, go to
|
|
<A HREF="http://catb.org/terminfo/">http://catb.org/terminfo/</A></LI>
|
|
<LI> "Termcap and Terminfo" is a book published by O'Reilly in
|
|
1988.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s17">17.</A> <A HREF="Text-Terminal-HOWTO.html#toc17">Using the Terminal</A></H2>
|
|
|
|
<H2><A NAME="ss17.1">17.1</A> <A HREF="Text-Terminal-HOWTO.html#toc17.1">Intro to Using the Terminal</A>
|
|
</H2>
|
|
|
|
<P> This section is about controlling the terminal-computer interface
|
|
and/or changing the terminal set-up while using the terminal. It
|
|
explains (or points to explanations of) how the user of a terminal can
|
|
control and inspect the interface and how to use various commands
|
|
provided by the device driver. It does not explain how to use the
|
|
many application programs, shells or most Linux utilities. Two
|
|
commands commonly used at the terminal are:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> clear (to clear the screen)</LI>
|
|
<LI> reset (to reset the terminal</LI>
|
|
<LI> setterm -reset (alternative for "reset" in case of bug)</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss17.2">17.2</A> <A HREF="Text-Terminal-HOWTO.html#toc17.2">Starting Up the Terminal</A>
|
|
</H2>
|
|
|
|
<P> Of course the power must be on for the terminal to work. If you
|
|
don't see a login prompt hit the "return" (or "enter") key a few times.
|
|
Then type your account name (followed by a return/enter) and your
|
|
password when prompted for it (also followed by return/enter). Make
|
|
sure not to type all capital letters. If you do, the computer may
|
|
think that you have an old terminal that can't send lowercase letters
|
|
and the serial driver may set itself up to send only capital letters
|
|
to the terminal.</P>
|
|
<P>If nothing happens, make sure that both the host computer and the
|
|
terminal are OK. If the host computer is shut down (no power) what
|
|
you type at the terminal keyboard may appear on the screen since the
|
|
transmit and receive pins at the computer may be connected together
|
|
resulting in echoing of characters by an "off" computer. If you can't
|
|
log in when the host computer is running, see
|
|
<A HREF="#trouble_shoot">Trouble-Shooting</A>.</P>
|
|
|
|
<H2><A NAME="ss17.3">17.3</A> <A HREF="Text-Terminal-HOWTO.html#toc17.3">Terminal (Serial) Device Driver</A>
|
|
</H2>
|
|
|
|
<P> When typing at the command line, the shell (such as the Bash
|
|
shell) is reading what you type and reacting to it. What you type
|
|
first passes thru the terminal driver part of your operating system.
|
|
This driver may translate certain characters (such as changing the
|
|
"return" character generated by the "return" key into a "new-line"
|
|
character for Linux files). It also recognizes certain control codes
|
|
which you may type at the keyboard such as ^C to interrupt the
|
|
execution of a program. It also normally echoes what you type back to
|
|
the display.
|
|
<A HREF="#stty_">Stty</A> may be used to configure
|
|
how this terminal driver behaves, including disabling some (or all) of
|
|
its functionality.</P>
|
|
|
|
<H2><A NAME="ss17.4">17.4</A> <A HREF="Text-Terminal-HOWTO.html#toc17.4">Problems with Editors</A>
|
|
</H2>
|
|
|
|
<P> There may be some problems with using both emacs and vi on some
|
|
terminals. A few terminals have no escape key (ESC) so you may need
|
|
to type Ctrl-[ to get ESC.</P>
|
|
|
|
<H3>emacs</H3>
|
|
|
|
<P> If software flow control exists, then the ^S command in emacs will
|
|
freeze the display. The ^Q command will unfreeze the display. One
|
|
fix is to map this to another key-press by configuring emacs that way.
|
|
Some terminals have meta keys although you may need to setup the
|
|
terminal to create a meta key.</P>
|
|
|
|
<H3><A NAME="vi_k_keys"></A> vi and Cursor-Keys </H3>
|
|
|
|
<P> Vi uses the esc-key as a command to exit insert mode.
|
|
Unfortunately for most terminals the arrow-keys send an an escape
|
|
sequence (starting with the ESC character) to the host. Vi must
|
|
distinguish between these two meanings of ESC. A smart vi (such as
|
|
vim if configured for it) is able to detect the difference by noting
|
|
the time between the ESC and the next key. If it's a short time, then
|
|
it's likely that a cursor key was pressed. Use "help cursor-keys" in
|
|
vim to find out more.</P>
|
|
<P>Here's another way to fix this. On VT terminals the left-arrow-key
|
|
may be either set to send ESC [ D or ESC O D. The other arrow keys
|
|
are similar but use A, B, and C instead of D. If you're having
|
|
problems, choose ESC [ D since the "O" in the other alternative could
|
|
be interpreted by vi as a command to "Open a line". The "[" should be
|
|
interpreted by vi to mean that an arrow-key has been pressed. ESC [ D
|
|
will be sent provided "Cursor Key Application Mode" has not been set.
|
|
ESC [ D is normally the default so everything is seemingly OK. Except
|
|
that many termcaps contain a string (not the init string) which sets
|
|
what you want to avoid: "Application Mode". Editors may send this
|
|
string to the terminal when the editor starts up. Now you are in
|
|
trouble.</P>
|
|
<P>This string has the termcap code "ks" (smkx in terminfo) meaning
|
|
enable the function (and related) keys (including the arrow keys). An
|
|
application enables these keys by sending the "ks" string to the
|
|
terminal. Whoever wrote the termcap reasoned that if an application
|
|
wants to enable these keys, then they should be put into "Application
|
|
Key Mode" since this is an "application", but you don't want this.</P>
|
|
<P>The Linux console has no "ks" string so you can't fall into this trap
|
|
at the console. For other terminals you may need to edit the termcap
|
|
(or terminfo) or use another termcap entry. You need to change not
|
|
only the "ks" string but also the termcap definitions of what they
|
|
send: kd, kl, kr, ku. Then run tic to install it.</P>
|
|
<P>For vim (vi iMproved) there is a way to set it up to work OK with ESC
|
|
O D (so you don't need to edit termcap): See vim help for
|
|
"vt100-cursor-keys". You may run "gitkeys" and then press your cursor
|
|
keys to see what they send but they may be set to send something
|
|
different when you're in an editor.</P>
|
|
|
|
<H2><A NAME="slow_scroll"></A> <A NAME="ss17.5">17.5</A> <A HREF="Text-Terminal-HOWTO.html#toc17.5">Problem with Slow Scrolling </A>
|
|
</H2>
|
|
|
|
<P>The scrolling speed of the text terminal is limited by the speed
|
|
over the serial line. This limitation is good in one respect since
|
|
the scrolling speed is slow enough that you can almost read what is
|
|
scrolling on the screen before it disappears off the bottom of the
|
|
screen.</P>
|
|
<P>But there is a downside to this. For example, if you copy a large
|
|
number of files (like everything on your hard drive) and use options
|
|
to display the full name (path name) of each file copied, then the
|
|
speed limitations of the serial line may only only display 30 files per
|
|
second on the screen. But your hard drive can copy many times faster
|
|
than this but the terminal will slow down the transfer to the speed at
|
|
which it can be displayed by the terminal. It does this by
|
|
<A HREF="#flow_control">Flow Control</A>.</P>
|
|
<P>The fix is to disable "progress" information being displayed on the
|
|
screen for cases where it slows down the "progress". If it just
|
|
updates progress numbers a few times per second or less, it shouldn't
|
|
be a problem.</P>
|
|
|
|
<H2><A NAME="bash_bug"></A> <A NAME="ss17.6">17.6</A> <A HREF="Text-Terminal-HOWTO.html#toc17.6">Bugs in Bash ? </A>
|
|
</H2>
|
|
|
|
<P> One problem still outstanding is that if certain terminal keys
|
|
send bytes with the high order bit set to 1, then Bash seems to ignore
|
|
the meaning for them as defined in a terminfo entry. This may be
|
|
because, unless one is using 7-bit ASCII, bytes with the high order
|
|
bit set to 1, may represent a non-English letter. I reported this as
|
|
a bug in Bash (but years later realized that it may not have been a
|
|
bug). Other programs such as the vim editor and the lynx browser work
|
|
OK with such keys (when they are set to use 7-bit ASCII).</P>
|
|
<P>To work around this problem, one may define what these keys should do
|
|
in Bash by putting such definitions into <CODE>/etc/inputrc.</CODE> For
|
|
example, A Wyse 60 will send D0-D3 when the arrow-keys are hit
|
|
provided the terminal is in "application key mode". After modifying
|
|
the terminfo to reflect this, they still wouldn't work on the command
|
|
line in the Bash shell. So I explicitly defined the arrow-keys in
|
|
<CODE>/etc/inputrc</CODE> like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# Arrow keys in 8 bit keypad mode: Sends d0-d3. -ap means application.
|
|
$if term=wy60-25-ap
|
|
set enable-keypad on
|
|
"\xd0": backward-char
|
|
"\xd1": forward-char
|
|
"\xd2": next-history
|
|
"\xd3": previous-history
|
|
$endif
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>If the terminal is already in "application key mode" there's no need
|
|
to "set enable-keypad on". enable-keypad will send the terminal the
|
|
escape sequence named smkx in terminfo (which for wyse60 is \E~3
|
|
and makes the arrow keys send D0-D3). Many other applications (other
|
|
than Bash) send this without needing to be told to do so.</P>
|
|
|
|
<H3>A fixed Bash bug</H3>
|
|
|
|
<P>There have been problems with the readline interface to the Bash
|
|
shell. Bash 2.01 (1998) had a readline interface which was quite
|
|
corrupted if one used a dumb terminal. This was fixed in later
|
|
versions. </P>
|
|
|
|
<H2><A NAME="ss17.7">17.7</A> <A HREF="Text-Terminal-HOWTO.html#toc17.7">Color ls Corruption</A>
|
|
</H2>
|
|
|
|
<P> If <CODE>ls</CODE> is corrupting your terminal emulation with the color
|
|
feature, turn it off. <CODE>ls --color</CODE>, and <CODE>ls --colour</CODE> all use
|
|
the color feature. Some installations have <CODE>ls</CODE> set to use color
|
|
by default. Check <CODE>/etc/profile</CODE>, etc. for <CODE>ls</CODE> aliases.
|
|
See
|
|
<A HREF="#ls_color">Example for ls Function</A> for how to
|
|
have <CODE>ls</CODE> do color for the console and do monochrome for terminals.</P>
|
|
|
|
<H2><A NAME="display_freezes"></A> <A NAME="ss17.8">17.8</A> <A HREF="Text-Terminal-HOWTO.html#toc17.8">Display Freezes (hung terminal) </A>
|
|
</H2>
|
|
|
|
<P> The symptom of a hung terminal is where what you type doesn't display
|
|
on the terminal (or in some cases displays but doesn't do anything).
|
|
If what you type is invisible (or does nothing) type ^Q to restart flow
|
|
(if flow control stopped it). Hanging may also be due to:<BR>
|
|
<A HREF="#sent_bin">Sent terminal binary</A> or
|
|
<A HREF="#abnormal_exit">Abnormally exited a program</A><BR>
|
|
If you didn't do any of these two, then the program you're running
|
|
could by buggy or you interaction with it fatally illegal.</P>
|
|
<P>If you want to quit the program you were running and you can't do it
|
|
by the usual methods (some programs have special keys you must hit to
|
|
exit) then try killing it from another terminal using "top" or "kill".
|
|
If the process refuses to die, then kill it with signal 9 from top (or
|
|
use "kill" on the command line). The "9" type of forced exit may leave
|
|
some temporary files lying around as well as a corrupted interface.
|
|
If this doesn't work, killing the login shell should result in a
|
|
startup of getty with a new login prompt. If all else fails, you may
|
|
need to reboot the computer or even power it down. Just rebooting may
|
|
not alter the possibly corrupted content of the serial port hardware
|
|
registers.</P>
|
|
<P>
|
|
<A NAME="ctrl_s"></A>
|
|
People new to Linux may unintentionally press Ctrl-S (^S) (or the "No
|
|
Scroll" key) which mysteriously freezes the screen (although that is
|
|
what this key is supposed to do if you use software flow-control). To
|
|
restore normal screen interaction, press Ctrl-Q (^Q). Note that
|
|
everything typed during the "freeze" gets executed but you don't see
|
|
any report of this until you hit ^Q. Thus when it's frozen, don't
|
|
type anything drastic that might destroy files, etc. One argument for
|
|
using hardware flow-control is to prevent such freezes.</P>
|
|
|
|
<H2><A NAME="corrupt_interface"></A> <A NAME="ss17.9">17.9</A> <A HREF="Text-Terminal-HOWTO.html#toc17.9">Corrupted Terminal Interface </A>
|
|
</H2>
|
|
|
|
<P> This includes the case of a "frozen display" = "hung terminal" of
|
|
the previous section.</P>
|
|
|
|
<H3><A NAME="symptoms_"></A> Symptoms and some fixes </H3>
|
|
|
|
<P> When the display doesn't look right, or when what you type doesn't
|
|
display correctly (if at all), or nothing happens when you type a
|
|
command, you may have a corrupted terminal interface. In rare cases,
|
|
when the serial port hardware gets itself corrupted, the only fix may
|
|
be to cycle power (turn off the PC and reboot). In some cases just
|
|
cycling power for the terminal will fix it. Sometimes logging in again
|
|
will solve the problem. To do this, kill the shell process running on
|
|
the terminal (or kill getty if it's running). You may do this from
|
|
another terminal. Once killed, a new getty process respawns which
|
|
hopefully will end the corruption. Recycling power (or resetting) for
|
|
the terminal may help too.</P>
|
|
<P>The corruption may be due to things such as:
|
|
<UL>
|
|
<LI>A bug in the program you're using (including a program which
|
|
erroneously assumes that you are using a terminal of type "linux")</LI>
|
|
<LI>A hardware failure (including an obscure hardware defect that
|
|
you can normally live with)</LI>
|
|
<LI>Incorrect configuration (including an error in the terminfo or
|
|
the terminal type)</LI>
|
|
</UL>
|
|
|
|
If everything was working normally but it suddenly goes bad, it may be
|
|
that the interface got corrupted by something you did. Three mistakes
|
|
you might have made to corrupt the interface are:</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#sent_bin">Sent terminal binary</A></LI>
|
|
<LI>
|
|
<A HREF="#abnormal_exit">Abnormally exited a program</A></LI>
|
|
<LI>
|
|
<A HREF="#ctrl_s">Typed ctrl-S by mistake</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3><A NAME="sent_bin"></A> Sent terminal binary characters </H3>
|
|
|
|
<P> Your terminal will change its characteristics if sent certain
|
|
escape sequences or control characters. It you inadvertently try to
|
|
display a binary file, it might by chance contain such sequences which
|
|
may put your terminal into some strange mode of operation or even make
|
|
it unusable. Always view or edit a binary file with programs designed
|
|
for that purpose so that this doesn't happen. Most editors and pagers
|
|
will handle binary OK so as not to corrupt the interface. Some may
|
|
display a message telling you that they can't edit binary. But you're
|
|
likely to corrupt things if you: "cat ...." or "cp .... /dev/tty.." or
|
|
run a program which sends binary output to "standard output" (unless
|
|
you redirect such output with >, etc.).</P>
|
|
<P>Corruption can also happen when using a communications program where
|
|
a remote computer may send binary to your screen. There are numerous
|
|
other ways it can happen so be prepared for it. Even a supposedly
|
|
text file could contain unwanted control codes.</P>
|
|
<P>To fix this problem reset the terminal. Type either just "reset" or
|
|
"tset" or "setterm -reset" (followed by a <return> of course --
|
|
what you type will likely not be readable on the screen). This will
|
|
send the reset string from the terminfo entry to the terminal. As an
|
|
alternative to this, if the correct set-up has been saved inside the
|
|
terminal then pressing a special key(s) (perhaps in setup mode) may
|
|
restore the settings. Then you might still need to use "reset" to send
|
|
the init string if you use it to set up your terminal.</P>
|
|
|
|
<H3>Reset command was broken but now fixed</H3>
|
|
|
|
<P>Note that in 2000 the "reset" command appeared to be broken for
|
|
terminals that needed "clocal" set since "reset" seemed to unset
|
|
"clocal". In 2001 it appears to be fixed so you may not need to read
|
|
the rest of this paragraph. If you have this problem, using "reset"
|
|
will only make the situation worse by disabling communication between
|
|
the terminal and computer. You will likely need to log in again and
|
|
hope the getty sets "clocal". If you see a login prompt without
|
|
asking for it, you're in luck. Otherwise see
|
|
<A HREF="#symptoms_">Symptoms and some fixes</A> for how to get a login prompt. You
|
|
should try out "reset" before you need it and use "setterm -reset" if
|
|
"reset" logs you out or otherwise doesn't work right. I submitted a
|
|
bug report in Mar. 2000 but never got a "fixed" notice.</P>
|
|
|
|
<H3>Character corruption</H3>
|
|
|
|
<P>For the case where you see strange "graphic" characters instead of
|
|
the normal ones, pressing ^O may switch back to the normal letters.
|
|
The "reset" command also does this but it resets everything else too.</P>
|
|
<P>There's the case where all letters have the wrong attribute (too dim,
|
|
bright, blinking, or even invisible :-) but the whitespace created by
|
|
tab characters is normal. This was caused by an escape sequence which
|
|
set this attribute but the attribute doesn't apply to the whitespace
|
|
created by tab characters. Fix by resetting, etc.</P>
|
|
|
|
<H3><A NAME="abnormal_exit"></A> Abnormally exited a program </H3>
|
|
|
|
<P> Large application programs (such as editors) often use the stty
|
|
command (or the like) in their code to temporarily change the stty
|
|
configuration when you are running the program. This may put the
|
|
device driver into "raw" mode so that every character you type goes
|
|
directly thru to the application program. Echoing by the driver is
|
|
disabled so that everything you see on the screen comes directly from
|
|
the application program. Thus many control commands (such as ^C) may
|
|
not work within such applications.</P>
|
|
<P>When you tell such an application to quit, the application program
|
|
first restores the stty settings to what they were before the
|
|
application program started. If you abnormally exit the program then
|
|
you may still be in "raw mode" on the command line. You should
|
|
suspect this has happened when what you type no longer displays on the
|
|
screen.</P>
|
|
<P>To get out of raw mode and restore the normal stty settings type "stty
|
|
sane". However, you must type this just after a "return" and end it
|
|
with a "return". But hitting the "return" key doesn't do the job
|
|
since the "return" code no longer gets translated to the new-line
|
|
characters that the shell is waiting for. So just type new-line (^J)
|
|
instead of "return". The "sane" terminal interface may not be exactly
|
|
the same as the normal one but it usually works. "stty sane" may also
|
|
be useful to get out of a corrupted interface due to other causes.</P>
|
|
|
|
<H2><A NAME="stty_chars"></A> <A NAME="ss17.10">17.10</A> <A HREF="Text-Terminal-HOWTO.html#toc17.10">Special (Control) Characters </A>
|
|
</H2>
|
|
|
|
<P> A number of control characters which you may type at the keyboard
|
|
are "caught" by the terminal driver and perform various tasks. To see
|
|
these control commands type: stty -a and look at lines 2-4. They are
|
|
tersely explained in the stty manual pages. They may be changed to
|
|
different control characters or disabled using the stty command. Thus
|
|
your control characters might be different than those described below.
|
|
They are used for command-line editing, interrupting, scrolling, and
|
|
to pass the next character thru transparently.</P>
|
|
|
|
<H3>Command-Line Editing</H3>
|
|
|
|
<P> While the terminal driver has a few commands for command-line
|
|
editing, some shells have a built-in real editor (such as "readline"
|
|
in the Bash shell). Such an editor is normally on by default so you
|
|
don't need to do anything to enable it. If it's available you don't
|
|
need to learn many of the following commands although they often still
|
|
work along with the command-line editor. The most important to learn
|
|
are ^C (interrupt), ^D, and how to stop scrolling.</P>
|
|
<P>
|
|
<UL>
|
|
<LI> Delete-key (shown by stty as ^?) erases the last character</LI>
|
|
<LI> ^U kills (deletes) the line</LI>
|
|
<LI> ^W deletes a word backwards</LI>
|
|
<LI> ^R reprints the line. Useful mainly on hard copy terminals ??</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Interrupting (& Quit, Suspend, EOF, Flush)</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> ^C interrupts. Exits the program and returns you to the
|
|
command-line prompt.</LI>
|
|
<LI> ^\ quits. Same as interrupt. Also may dump a "core" file
|
|
(which you likely have no use for) into your working directory.</LI>
|
|
<LI> ^Z suspends. Stops the program and puts it in the background.
|
|
Type fg to restart it.</LI>
|
|
<LI> ^D end of file. If typed at the command-line prompt, exits the
|
|
shell and goes to where you were before the shell started.</LI>
|
|
<LI> ^O flush (or discard). Not yet implemented in Linux (but
|
|
proposed). Sends output to /dev/null.</LI>
|
|
<LI> ^T display driver status. Not yet implemented in Linux (but
|
|
proposed). Displays a status line for the interface (number of bytes
|
|
sent, etc.).</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Stop/Start Scrolling</H3>
|
|
|
|
<P> If what you want to see scrolls off the bottom of the screen,
|
|
you may prevent this by sending a "stop" signal (^S or Xoff) to the
|
|
host (provided Xon-Xoff
|
|
<A HREF="#flow_control">Flow Control</A> is
|
|
enabled). Send a "start signal to resume (^Q or Xon). Some terminals
|
|
have a "No Scroll" key which will alternately send Xoff and Xon or
|
|
possibly send the hardware flow control signals ?? Here's what
|
|
ctrl-S (^S) and ctrl-Q (^Q) do:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> ^S stops scrolling (Xoff)</LI>
|
|
<LI> ^Q resume scrolling (Xon)</LI>
|
|
</UL>
|
|
</P>
|
|
<P>If you want to both stop scrolling and quit, use ^C. If you want to
|
|
stop scrolling to do something else but want to keep the program that
|
|
was generating the output in memory so you can resume scrolling later,
|
|
use ^Z suspend.</P>
|
|
<P>An alternative scrolling method is to pipe the output thru a pager
|
|
such as more, less, or most. However, the output might not be
|
|
standard output but could be error output which the pager doesn't
|
|
recognize. To fix this you may need to use redirection "2>&1" to get
|
|
the pager to work OK. It is often simpler to just use ^S and ^Q
|
|
unless you need to scroll backwards.</P>
|
|
<P>At a PC console (emulating a terminal) you may scroll backwards by
|
|
using Shift-PageUp. This is frequently needed since the scrolling is
|
|
often too fast to stop using ^S. Once you've scrolled backwards
|
|
Shift-PageDown will scroll forward again.</P>
|
|
|
|
<H3>Take next character literally</H3>
|
|
|
|
<P> ^V sends the next character typed (usually a control character)
|
|
directly thru the device driver with no action or interpretation.
|
|
Echoed back are two ASCII characters such as ^C.</P>
|
|
|
|
<H2><A NAME="ss17.11">17.11</A> <A HREF="Text-Terminal-HOWTO.html#toc17.11">Viewing Latin1 Files on a non-Latin1 terminal</A>
|
|
</H2>
|
|
|
|
<P> Some "text" files are 8-bit Latin1 (=ISO-8859-1). See
|
|
<A HREF="#char_sets">Character-Sets</A>. If you have a terminal that
|
|
will not display Latin1 (or don't have the Latin1 character set
|
|
installed), then certain symbols (such as a bullet) will display wrong.
|
|
When viewing manual pages (they are Latin1) you may give the option -7
|
|
to man so as to translate everything to ASCII. Are there some pagers
|
|
that make these translations ??</P>
|
|
|
|
<H2><A NAME="ss17.12">17.12</A> <A HREF="Text-Terminal-HOWTO.html#toc17.12">Eliminating Overstriking in Files</A>
|
|
</H2>
|
|
|
|
<P>If one uses the "man" command to view a manual page but instead
|
|
redirects the output to a file, that file will have overstrikes in it.
|
|
Overstrikes are where some printed characters appear bold by printing
|
|
them twice in the same location. Thus to print an overstrike
|
|
character the file contains a backspace after the character and then
|
|
the same character repeated. If this is in a file, it's fine if you
|
|
are going to print it on a printer (unless the normal output from the
|
|
printer is so darks that overstriking makes little improvement). But
|
|
it's not so good if you want to use the file to email or edit.</P>
|
|
<P>One way to get rid of the overstrikes is to use the "ul" (underline)
|
|
command. You type: ul -t dumb my_overstruck_file > output_file
|
|
The ul command converts overstrikes to bold for whatever terminal is
|
|
specified and adds escape sequences to the output_file to generate the
|
|
bold. But the terminal of type "dumb" has no escape sequences so you
|
|
get the desired result. There are other ways to do this but this is a
|
|
possible use for a terminal of type "dumb".</P>
|
|
|
|
<H2><A NAME="ss17.13">17.13</A> <A HREF="Text-Terminal-HOWTO.html#toc17.13">Inspecting the Interface</A>
|
|
</H2>
|
|
|
|
<P> These utility programs will provide information about the terminal
|
|
interface:
|
|
<UL>
|
|
<LI> gitkeys: shows what byte(s) each key sends to the host.</LI>
|
|
<LI> tty: shows what tty port you are connected to.</LI>
|
|
<LI> set: shows the value of TERM (the terminfo entry name)</LI>
|
|
<LI> stty -a: shows all stty settings.</LI>
|
|
<LI> setserial -g /dev/tty?? (you fill in ??) shows UART type, port
|
|
address and IRQ number.</LI>
|
|
<LI> infocmp: shows the current terminfo entry (less comments)</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="term_settings"></A> <A NAME="ss17.14">17.14</A> <A HREF="Text-Terminal-HOWTO.html#toc17.14">Changing the Terminal Settings </A>
|
|
</H2>
|
|
|
|
<P> The terminal settings are normally set once when the terminal is
|
|
installed using the setup procedures in the terminal manual. However,
|
|
some settings may be changed when the terminal is in use. You
|
|
normally would not give any "stty" or "setserial" commands when the
|
|
terminal is in use as they are likely to corrupt the terminal
|
|
interface. However, there are changes you may make to the appearance
|
|
of the terminal screen or to its behavior without destroying the
|
|
integrity of the interface. Sometimes these changes are made
|
|
automatically by application programs so you may not need to deal with
|
|
them.</P>
|
|
<P>One direct method of making such changes is to use the setup key (or
|
|
the like) at the terminal and then use menus (or the like) to make the
|
|
changes. To do this you may need to be familiar with the terminal.
|
|
<A NAME="setterm_"></A>
|
|
<A NAME="tput"></A> The other 3 methods send an
|
|
escape sequence from the computer to the terminal to make the changes.
|
|
These 3 examples show different methods of doing this to set reverse
|
|
video:</P>
|
|
<P>
|
|
<OL>
|
|
<LI> setterm -reverse</LI>
|
|
<LI> tput -rev</LI>
|
|
<LI> echo ^[[7m</LI>
|
|
</OL>
|
|
</P>
|
|
|
|
<H3>setterm</H3>
|
|
|
|
<P> This is the easiest command to use. It uses long options (but
|
|
doesn't use the normal -- before them). It consults the terminfo
|
|
database to determine what code to send. You may change the color,
|
|
brightness, linewrap, keyboard repeat, cursor appearance, etc.</P>
|
|
|
|
<H3>tput</H3>
|
|
|
|
<P> The "tput" command is similar to "setterm" but instead of using
|
|
ordinary words as arguments, you must use the abbreviations used by
|
|
terminfo. Many of the abbreviations are quite terse and hard to
|
|
remember.</P>
|
|
|
|
<H3>echo</H3>
|
|
|
|
<P> In the example "echo ^[[7m" to set reverse video, the
|
|
^[ is the escape character. To type it type ^V^[ (or ^V
|
|
followed by the escape key). To use this "echo" method you must find
|
|
out what code to use from a terminal manual or from terminfo or
|
|
termcap. It's simpler to use setterm or tput if you are typing on the
|
|
command line. Since "echo ..." will execute faster (since it doesn't
|
|
do any lookups) it's good for using in shell scripts which run at
|
|
start-up, etc.</P>
|
|
|
|
<H3>Saving changes</H3>
|
|
|
|
<P> When you turn off the terminal the changes you made will be lost
|
|
(unless you saved them in non-volatile terminal memory by going into
|
|
set-up mode and saving it). If you want to use them again without
|
|
having to retype them, put the commands in a shell script or make it a
|
|
shell function. Then run it when you want to make the changes. One
|
|
way to make the changes semi-permanent is to put the commands in a
|
|
file that runs each time you login or start up the computer.</P>
|
|
|
|
<H2><A NAME="ss17.15">17.15</A> <A HREF="Text-Terminal-HOWTO.html#toc17.15">Multiple Sessions</A>
|
|
</H2>
|
|
|
|
<P> The "<CODE>screen</CODE>" package runs multiple sessions something like
|
|
virtual terminals on the console: See
|
|
<A HREF="#console_dev">The Console: /dev/tty?</A>. You can switch back and forth between the
|
|
sessions. The non-free Facet Term software also does this. See
|
|
<A HREF="http://www.facetcorp.com/ft_overview.html">FacetTerm</A></P>
|
|
|
|
<H2><A NAME="ss17.16">17.16</A> <A HREF="Text-Terminal-HOWTO.html#toc17.16">Logging Out</A>
|
|
</H2>
|
|
|
|
<P> To log out type either "logout" or "exit". Under some
|
|
circumstances your request will be refused, but you should be told why.
|
|
One reason for refusal is if you are not in the same shell that
|
|
you logged into. Another way to log out is to press ^D. Since ^D is
|
|
also used for other purposes, you may not want it to log you out. If
|
|
you set IGNOREEOF in the Bash shell then ^D will no longer log you
|
|
out.</P>
|
|
|
|
<H2><A NAME="ss17.17">17.17</A> <A HREF="Text-Terminal-HOWTO.html#toc17.17">Chatting between Terminals, Spying</A>
|
|
</H2>
|
|
|
|
<P> If two persons logged into terminals on the same host computer
|
|
want to chat with each other they may use the "write" or the "talk"
|
|
(better) program. One may prevent anyone (except the superuser) from
|
|
writing (sending messages) to their terminal by using the "mesg"
|
|
command.</P>
|
|
<P>For spying on what someone else is doing at their terminal use the
|
|
"ttysnoop" program. In "ttysnoop" the two terminals have the same
|
|
status and anything typed on either keyboard appears on both screens
|
|
(in the same location). So if you're really spying and don't want to
|
|
be detected, you shouldn't type anything.</P>
|
|
<P>"ttysnoop" can be used for training with instructor and trainee
|
|
sitting side-by-side, each at their own terminal. The instructor may
|
|
watch what the trainee is typing and can correct any mistakes by
|
|
typing it correctly. The trainee can watch what the instructor types
|
|
and then try typing it. It's just like they used one terminal with
|
|
both people having their hands on the keyboard at the same time.</P>
|
|
<P>There's one shortcoming to "ttysnoop" and that is that the terminals
|
|
involved should all be (or emulate) the same type of terminal (such as
|
|
vt100). Since the "Linux" emulation done by a console (monitor) and
|
|
the "minicom" (or "picocom") emulation are close to vt100 one may use
|
|
ttysnoop using two PCs, one running "minicom" which emulates a
|
|
terminal.</P>
|
|
<P>There's a non-free program called "DoubleVision" that is something
|
|
like ttysnoop but does much more. Terminals may be of different types
|
|
and it can remember and playback sessions on terminals so you can
|
|
observe what happened in the past. The webpage is at
|
|
<A HREF="http://www.tridia.com">http://www.tridia.com</A>.</P>
|
|
|
|
<H2><A NAME="ss17.18">17.18</A> <A HREF="Text-Terminal-HOWTO.html#toc17.18">Sharing the Serial Port</A>
|
|
</H2>
|
|
|
|
<P> It's possible to use the same serial port for both a text-terminal
|
|
and another serial device such as a printer or modem. Making the
|
|
physical connection is easy using one of these methods:
|
|
<UL>
|
|
<LI> Just unplug the terminal cable and plug in the other device</LI>
|
|
<LI> Use an AB switch to switch between the terminal and other
|
|
device (uses 3 cables)</LI>
|
|
<LI> Use the printer (or aux) port on the terminal for the other
|
|
device</LI>
|
|
</UL>
|
|
</P>
|
|
<P>When you are not using the serial port for a terminal, then you need
|
|
to make sure that no characters intended for the terminal are sent to
|
|
the other device by mistake. One unsafe way to do this is to let the
|
|
programs running on the terminal keep running, provided they don't
|
|
send out anything for the terminal when you are using the other
|
|
device. This sometimes works since a terminal running on a serial
|
|
port doesn't prevent another program (process) from opening the same
|
|
port. This sometimes works if the other device is a printer. But if
|
|
the other device should send bytes to the serial port on the computer,
|
|
then the program(s) for the terminal which are still running on the
|
|
port will often send back some bytes for the terminal which will
|
|
actually go to the other device as garbage.</P>
|
|
<P>To avoid this, it's best to kill all programs (processes) running on
|
|
the terminal before using the other device. This is not quite as easy
|
|
as it sounds. You normally have a shell (such as Bash) running on the
|
|
port and if you kill Bash (by logging out for example) then the
|
|
program "getty" will start up on the port to try to log you in again.
|
|
If you kill getty, it will respawn and start up again. So at first
|
|
glance it seems impossible to kill all processes on the terminal's
|
|
serial port.</P>
|
|
<P>One way to work around this problem is to switch runlevels so that no
|
|
getty program or shell is running on the port. For the runlevel fix,
|
|
you may create another runlevel in which no getty program runs on the
|
|
port. Then you enter this new runlevel and use the serial port for
|
|
something else. To set this up you need to edit <CODE>/etc/inittab</CODE>
|
|
and check and/or set the runlevels at which getty runs. For example
|
|
the line: <CODE>"S1:23:respawn:/sbin/getty</CODE> ..." means that getty
|
|
will run (on ttyS1) in runlevels 2 and 3. Now you could have it only
|
|
run in level 2 (by deleting "3") and then go to runlevel 3 when you
|
|
want to use the other serial device. Thus to use the serial port for
|
|
something else, the super-user would type "init 3" to switch to
|
|
runlevel 3. Type "init 2" to get back to runlevel 2. Note that each
|
|
runlevel may have a different set of initialization scripts but you
|
|
can change this if you want, so that the same scripts are run in both
|
|
runlevels. How the scripts and runlevels work are distribution
|
|
dependent. For the Debian distribution, the explanation of this is in
|
|
<CODE>/usr/doc/sysvinit</CODE>, but also look in <CODE>/usr/share/doc.</CODE></P>
|
|
<P>There's also the problem of the stty configuration of the port. When
|
|
the port is being used for the terminal it has certain configurations but
|
|
when say "init 3" is used to switch runlevels and disable getty on the
|
|
port, the original (boot-time) configuration of the port is not
|
|
restored. You are likely to wind up with the port configured in a
|
|
"raw" mode. This means that the serial port likely needs to be fully
|
|
reconfigured by stty, either by a script you write or by the next
|
|
application which runs on the port. Some applications such as
|
|
printing from the serial port may not capable of fully reconfiguring.
|
|
The obsolete version of /etc/printcap could only partially reconfigure
|
|
(but the new one under "lprng" can). Thus you might need to write a
|
|
script to do it. The stty configuration of a terminal will be
|
|
different depending on whether a shell is running on it, whether it's
|
|
at the "login" prompt, etc. Thus the stty configuration after
|
|
switching runlevels may vary.</P>
|
|
|
|
<H2><A NAME="ss17.19">17.19</A> <A HREF="Text-Terminal-HOWTO.html#toc17.19">Browsers for Text-Terminals</A>
|
|
</H2>
|
|
|
|
<P>See
|
|
<A HREF="http://www.linuxjournal.com/article/8148">2005 Text Mode Browser Roundup</A> for a review of text browsers.</P>
|
|
<P>The "lynx" browser works correctly with all text terminals. There
|
|
are some other text browsers: "w3m", "links2" (formerly "links", and
|
|
"elinks" that only work perfectly with the Linux console, xterm, or
|
|
vt100 terminals. But links2 and elinks will work with any terminal by
|
|
classifying the type as dumb like the
|
|
<A HREF="#early_terms">first terminals</A>. However, such an interface is slower.</P>
|
|
<P>The "netrik" browser requires a color terminal. For "links2" and
|
|
"elinks" you must set your terminal to 8-bits with no parity. (I filed
|
|
a bug report years ago for elinks since it should work with parity and
|
|
finally in 2008 I got a message that it was fixed in version 0.13
|
|
and might become fixed in 0.11 and 0.12 also). All (including netrik
|
|
??) support ssl (secure socket layer) for encoded communication.</P>
|
|
<P>"w3m", "links2", and "elinks" overcome some of the "lynx" deficiencies.
|
|
"elinks" is just a more advanced "links". They can usually display
|
|
tables better and can display frames side-by-side. Unfortunately, the
|
|
width of what they try to display (for tables and frames) is often
|
|
wider than the terminal width so the text may run off the right side
|
|
of the screen. This requires scrolling sideways to see everything.
|
|
Doing this may cause the names of the table rows to disappear from the
|
|
screen. So in some cases, using "lynx" may be better.</P>
|
|
<P>Unfortunately "w3m", "links2", and "elinks" don't have numbered links
|
|
like lynx does, nor do they have good support for cookies. Support
|
|
for Javascript may be a problem. Elinks and netrik have partial
|
|
support. Links2 also has support (full ?). Both netrik and links2 has a
|
|
graphic mode for use in X Window. </P>
|
|
<P>There are still other text browser projects. Some of them seem to be
|
|
dead.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s18">18.</A> <A HREF="Text-Terminal-HOWTO.html#toc18">Special Uses for a Terminal</A></H2>
|
|
|
|
<H2><A NAME="term_as_console"></A> <A NAME="ss18.1">18.1</A> <A HREF="Text-Terminal-HOWTO.html#toc18.1">Make a Serial Terminal the Console </A>
|
|
</H2>
|
|
|
|
<P> This will turn a text-terminal (or emulator PC) into a "serial
|
|
console". Many messages from the system are normally only sent to the
|
|
console (the PC monitor). Some of the messages sent to the console at
|
|
boot-time may also be seen on any terminal after the boot succeeds by
|
|
typing the command: dmesg. If the boot failed this will not be of any
|
|
use since the terminal can't work without an operating system. It's
|
|
possible to modify the Linux kernel so as to make a terminal serve as
|
|
the console and receive all the messages from Linux intended for the
|
|
console. Unfortunately, the messages from the BIOS (which display on
|
|
the monitor when a PC is first started) will not display on this
|
|
terminal (but still display on the monitor).</P>
|
|
<P>There's a Remote-Serial-Console-HOWTO on this topic. Some people use
|
|
a serial console when they run a PC without a monitor or keyboard.
|
|
Normally, a PC will not start up without a keyboard and video card but
|
|
some BIOSs permit it. If you are lucky enough to have such a BIOS
|
|
that supports "console re-direct" you will likely then need to setup
|
|
the BIOS using the CMOS menus when you start your PC.</P>
|
|
<P>The method of creating a "serial console" depends on your kernel
|
|
version. In any case serial support needs to be compiled into the
|
|
kernel and not supplied as a module.</P>
|
|
|
|
<H3>For Kernels 2.2 or higher</H3>
|
|
|
|
<P> The instructions for creating a serial-console are included with
|
|
the kernel documentation in: Documentation/serial-console.txt.
|
|
Kernel 2.4+ has better documentation and mentions the need to run
|
|
getty on the serial port. Normally, the device /dev/console is linked
|
|
to tty0 (the PC console). For a serial-console you create a new
|
|
/dev/console by
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
mknod -m 622 console c 5 1
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
You must also put statements regarding the serial-console into
|
|
/etc/lilo.conf and then run lilo. This is because the equivalent of
|
|
"setserial" needs to be run early before the kernel is loaded so that
|
|
the serial-console can display the booting. See the above mentioned
|
|
kernel documentation and the man page for lilo.conf for more details.</P>
|
|
<P>Here is an example <CODE>/etc/lilo.conf</CODE> file contents (for ttyS0):
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
prompt
|
|
timeout=50
|
|
boot = /dev/sda
|
|
vga = normal # force sane state
|
|
install = /boot/boot.b
|
|
message = /boot/message
|
|
image = /vmlinuz
|
|
root = /dev/sda1
|
|
label = console
|
|
serial = 0,9600n8
|
|
append = "console=ttyS0"
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The same PC may have more than one serial console but the last console
|
|
mentioned in the "append" statement becomes the main console that you
|
|
interact with ?? See the kernel docs (but it's not too clear).</P>
|
|
|
|
<H3>Serial-Console For Kernels before 2.2</H3>
|
|
|
|
<P> The Linux Journal in April 1997 had an article on patching
|
|
the Linux kernel. You add a couple of #defines at the start of
|
|
src/linux/drivers/char/console.c:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
#define CONFIG_SERIAL_ECHO
|
|
#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */
|
|
|
|
The following was not in the Linux Journal article.
|
|
In kernel 2.+ (and earlier ??) you need to also set the baud
|
|
rate (unless 9600 is OK). Find these 2 lines:
|
|
|
|
serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
|
|
serial_echo_outb(0x0c, UART_DLL);
|
|
|
|
Change 0x0c in the line above (depending on the baud rate you want):
|
|
|
|
115200 baud: 0x01 19200 baud: 0x06 2400 baud: 0x30
|
|
57600 baud: 0x02 9600 baud: 0x0c 1200 baud: 0x60
|
|
38400 baud: 0x03 4800 baud: 0x18
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>If you currently use the console to select which operating system to
|
|
boot (using LILO), but would like to do this from a terminal, then you
|
|
need to add a line to the /etc/lilo.conf file. See the manual page
|
|
for lilo.conf and search for "serial=".</P>
|
|
|
|
<H2><A NAME="ss18.2">18.2</A> <A HREF="Text-Terminal-HOWTO.html#toc18.2">Run Linux without a Monitor</A>
|
|
</H2>
|
|
|
|
<P> One way to do this is to just use a terminal (serial console) for
|
|
the monitor See
|
|
<A HREF="#term_as_console">Make a Serial Terminal the Console</A>. You may still need a video card since many BIOSs
|
|
require one to get the PC started. Your BIOS may also require a
|
|
keyboard to get started or it may have an option where you can set the
|
|
BIOS not to require a keyboard.</P>
|
|
<P>If you boot without a monitor, make sure that the boot loader (such as
|
|
LILO or GRUB) doesn't try to present any image on the screen. A
|
|
text-terminal can't display it and the booting may hang.</P>
|
|
<P>If you have a keyboardless terminal, it can also be used as a monitor
|
|
by use of the ttysnoop program. As of yet, it doesn't work like a
|
|
console since it doesn't get all the initial boot-time messages. See
|
|
<A HREF="#keyboardless_terminal">Use a Keyboardless Terminal as the Monitor</A></P>
|
|
|
|
<H2><A NAME="keyboardless_terminal"></A> <A NAME="ss18.3">18.3</A> <A HREF="Text-Terminal-HOWTO.html#toc18.3">Use a Keyboardless Terminal as the Monitor </A>
|
|
</H2>
|
|
|
|
<H3>How it works</H3>
|
|
|
|
<P> While you might think that a terminal without a keyboard is
|
|
useless it is possible to use it as the monitor and type on the PC's
|
|
own keyboard. This may be done by using the spy program
|
|
<CODE>ttysnoop</CODE>. This program permits a person at one terminal to spy
|
|
on (or snoop) what someone else is typing at another terminal (or the
|
|
PC console-monitor).</P>
|
|
<P>Now suppose you are typing away at the monitor tty1. Imagine that
|
|
someone with a terminal on ttyS2 is spying on you (with ttysnoop) and
|
|
has a screen that looks just like your screen. Everything you type
|
|
at tty1 also displays on ttyS2. Now move the spy terminal (on ttyS2)
|
|
so it is side-by-side with your monitor (on tty1). Everything you
|
|
type on the PC keyboard will now display on the two screens in front
|
|
of you: the monitor and the spy terminal. Now just look only at the
|
|
spy terminal as you type. Disconnect both the monitor and the
|
|
terminal keyboard since you're not using either. Thus you are now
|
|
using a keyboardless terminal as a monitor. What a simple but clever
|
|
solution!</P>
|
|
<P>One possible problem (which turns out to be no problem at all) is
|
|
that normally, the type of spy terminal should be the same as the type
|
|
of terminal being spied upon. Since the monitor is normally declared
|
|
as a terminal of type "linux" (which is close to vt100), you might
|
|
think that the real terminal should also be (or at least emulate) a
|
|
vt100. Not necessarily so! For example, if you have a wyse60
|
|
terminal you simply falsely declare that you have a wyse terminal on
|
|
tty1 (tell the getty program for tty1 that it's a wyse60).</P>
|
|
<P>Here's why you can get away with this. Go back the scenario where
|
|
you have both the monitor and the wyse60 terminal in front of you,
|
|
both displaying the same thing (or trying to). Ttysnoop will be
|
|
sending the wyse60 the same bytes as are going to the monitor. If
|
|
you've falsely claimed that the monitor is a wyse60, then you'll have
|
|
wyse60 escape sequences going to both the monitor and the wyse60
|
|
terminal (via ttysnoops). The display on the wyse60 is fine but the
|
|
display on the monitor is corrupted since it's getting wyse60 escape
|
|
sequences. Since you will not use the monitor (and are about to
|
|
disconnect it) this corruption is never a problem (you simply don't
|
|
see it).</P>
|
|
|
|
<H3>Example configuration</H3>
|
|
|
|
<P> This is not the ideal setup since ttysnoop runs so late that the
|
|
login prompt doesn't appear. This example is for a wyse60 terminal on
|
|
ttyS2 and the missing monitor/PC-keyboard on tty1. It uses the agetty
|
|
program for getty as supplied by the Debian distribution. Your getty
|
|
may require a different format.</P>
|
|
<P>In <CODE>/etc/inittab:</CODE>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
1:2345:respawn:/sbin/getty 38400 tty1 wyse60 -ln /usr/sbin/ttysnoops
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Note that <CODE>ttysnoop/ttysnoops</CODE> is a client-server combo so the
|
|
"s" is not a typo. If you don't use -n you may not see a login prompt
|
|
on the terminal. With no -n, agetty issues the prompt before the
|
|
ttysnoop is activated. With -n, agetty doesn't issue the prompt (but
|
|
login does instead). If you use -n, agetty will no longer
|
|
automatically detect parity but if you don't use parity all is OK.</P>
|
|
<P>In <CODE>/etc/snooptab:</CODE>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# tty snoopdev type execpgm
|
|
tty1 /dev/ttyS3 init /usr/local/bin/sterm
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
In the above, a script named sterm is used to run the stty program.
|
|
You may not need this or may want to use it for another purpose.
|
|
Here's the example sterm script in <CODE>/usr/local/bin/sterm:</CODE></P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
#!/bin/sh
|
|
stty rows 24
|
|
/bin/login $@
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="trouble_shoot"></A> <A NAME="s19">19.</A> <A HREF="Text-Terminal-HOWTO.html#toc19">Trouble-Shooting </A></H2>
|
|
|
|
<P> If you suspect that the problem is a hardware problem, see the
|
|
<A HREF="#repair_">Repair and Diagnose</A> section. If it's the
|
|
keyboard see
|
|
<A HREF="#keyboards_">Keyboards</A>. If it responds
|
|
incorrectly (if at all) to what you type. see
|
|
<A HREF="#corrupt_interface">Corrupted Terminal Interface</A>. If the
|
|
problem involves the serial port itself see the Serial-HOWTO.</P>
|
|
<P>Here is a list of possible problems:
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#term_OK">Is the Terminal OK ?</A>
|
|
Suspect the terminal is defective.</LI>
|
|
<LI>
|
|
<A HREF="#display_freezes">Display Freezes (hung terminal)</A></LI>
|
|
<LI>
|
|
<A HREF="#displays_foreign">Displays Foreign/Weird Characters/Symbols</A></LI>
|
|
<LI>
|
|
<A HREF="#displays_esc-seqs">Displays Escape Sequences</A></LI>
|
|
<LI>
|
|
<A HREF="#flow_ctrl_ng">Missing Text</A> Either skips
|
|
over some text or displays some text OK and hangs.</LI>
|
|
<LI>
|
|
<A HREF="#keys_erratic">All Keys Work Erratically; Must Hit a Key a Few Times</A></LI>
|
|
<LI>
|
|
<A HREF="#stopped_">If getty run from command line: Programs get stopped</A> with message "Stopped"</LI>
|
|
<LI>
|
|
<A HREF="#rapid_respawn">Getty Respawning Too Rapidly</A>
|
|
(console error message)</LI>
|
|
<LI>
|
|
<A HREF="#after_login">Fails Just After Login</A></LI>
|
|
<LI>
|
|
<A HREF="#cant_login">Can't Login</A> but login prompt is
|
|
OK.</LI>
|
|
<LI>
|
|
<A HREF="#garbled">Garbled Login Prompt</A></LI>
|
|
<LI>
|
|
<A HREF="#no_login_prompt">No Login Prompt</A></LI>
|
|
<LI>
|
|
<A HREF="#cursor_jumps">Cursor Jumps</A></LI>
|
|
</UL>
|
|
</P>
|
|
<P>There are two cases where the terminal goes bad. One is when it's
|
|
been recently working OK and suddenly goes bad. This is discussed in
|
|
the next sub-section. The other case is where things don't work right
|
|
just after you install a terminal. For this case you may skip over
|
|
the next section.</P>
|
|
|
|
<H2><A NAME="term_was_ok"></A> <A NAME="ss19.1">19.1</A> <A HREF="Text-Terminal-HOWTO.html#toc19.1">Terminal Was Working OK </A>
|
|
</H2>
|
|
|
|
<P> When a formerly working terminal suddenly goes bad it is often
|
|
easy to find the problem. That's because (except for hardware
|
|
failures) the problem is likely due to something that you did (or
|
|
something the software that you used did).</P>
|
|
<P>The problem may be obvious such as an error message when the terminal
|
|
is first turned on. If it makes a strange noise it likely needs
|
|
repair. See
|
|
<A HREF="#repair_">Repair & Diagnose</A>. First,
|
|
think about what has been done or changed recently as it's likely the
|
|
cause of the problem. Did the problem happen just after new system
|
|
software was installed or after a change in the configuration?</P>
|
|
<P>If the terminal isn't responding correctly (if at all) to what you
|
|
type to it, you may have a
|
|
<A HREF="#corrupt_interface">Corrupted Terminal Interface</A>.</P>
|
|
|
|
<H2><A NAME="trouble_shoot_new"></A> <A NAME="ss19.2">19.2</A> <A HREF="Text-Terminal-HOWTO.html#toc19.2">Terminal Newly Installed </A>
|
|
</H2>
|
|
|
|
<P> If you've just connected up a terminal to a computer per
|
|
instructions and it doesn't work this section is for you. If a
|
|
terminal that formerly worked OK doesn't work now then see
|
|
<A HREF="#term_was_ok">Terminal Was Working OK</A> If you suspect
|
|
that the serial port on your computer may be defective you might try
|
|
running a diagnostic test program on it. At present (June 1998) it
|
|
seems that Linux doesn't yet have such a diagnostic program so you may
|
|
need to run diagnostics under MS DOS/Windows. There are some programs
|
|
to monitor the various serial lines such at DTR, CTS, etc. and this
|
|
may help. See
|
|
<A HREF="#serial_mon">Serial Monitoring/Diagnostics</A></P>
|
|
<P>One approach is to first see if the terminal will work by trying
|
|
to copy a file to the terminal (cp my_file /dev/ttyS?) under the most
|
|
simple situation. This means with the modem control lines disabled
|
|
and at a show speed that doesn't need flow control (make sure that any
|
|
hardware flow control is disabled). If this copy works, then make the
|
|
situation a little more complicated and see if it still works, etc.,
|
|
etc. When the trouble appears just after you made a change, then that
|
|
change is likely the source of the trouble. Actually, its more
|
|
efficient (but more complex) to jump from the simple situation to
|
|
about half way to the final configuration so that the test eliminates
|
|
about half of the remaining possible causes of the problem. Then
|
|
repeat this methodology for the next test. This way it would only
|
|
take about 10 tests to find the cause out of a thousand possible
|
|
causes. You should deviate a little from this method based on hunches
|
|
and clues.</P>
|
|
|
|
<H2><A NAME="term_OK"></A> <A NAME="ss19.3">19.3</A> <A HREF="Text-Terminal-HOWTO.html#toc19.3">Is the Terminal OK ? </A>
|
|
</H2>
|
|
|
|
<P> Many terminals will start up with some words on the screen. If
|
|
these words convey no error message, it's probably OK. If there is no
|
|
sign of power (a dark screen, etc.) re-plug in the computer power cord
|
|
at both ends. Make sure there is power at the wall jack (or at the
|
|
extension cord end). Try another power cord if you have one. Make
|
|
sure the terminal is turned on and that its fuse is not blown. A
|
|
blank (or dim) screen may sometimes be fixed by just turning up the
|
|
brightness and contrast using knobs or a keyboard key in set-up mode.</P>
|
|
<P>A terminal that's been stored for a long time may take a while to
|
|
"warm up" as the electrolytic capacitors heal themselves under
|
|
voltage. If it still won't work See
|
|
<A HREF="#repair_">Repair & Diagnose</A> for tips on repairing it.</P>
|
|
<P>If the terminal starts up OK, but you suspect that something may be
|
|
wrong with it, go into "local mode" where is works like a typewriter
|
|
and try typing on it. See
|
|
<A HREF="#local_mode">Local Mode</A>.
|
|
Before you have trouble, you should find out if your terminal displays
|
|
error messages if the hardware is bad. One way to test a terminal
|
|
for this is to turn it on with the keyboard unplugged and see if it
|
|
displays an error message.</P>
|
|
|
|
<H2><A NAME="flow_ctrl_ng"></A> <A NAME="ss19.4">19.4</A> <A HREF="Text-Terminal-HOWTO.html#toc19.4">Missing Text </A>
|
|
</H2>
|
|
|
|
<P> If several lines or text displays on the terminal OK and then it
|
|
stops without finishing (in the middle of a word, etc.) or if big
|
|
chunks of text are missing, you likely have a problem with flow
|
|
control. If you can't figure out right away what's causing it,
|
|
decrease the speed. If that fixes it, it's likely a flow control
|
|
problem. It may be that flow control is not working at all due to
|
|
failure to configure it correctly, or due to incorrect cable wiring
|
|
(for hardware flow control). See
|
|
<A HREF="#flow_control">Flow Control</A></P>
|
|
<P>If you can type OK at the terminal but when text is sent to the
|
|
terminal, only about 1 in every 16 characters sent gets thru, then you
|
|
may have given the wrong UART to setserial. This will happen if the
|
|
port is an obsolete 16550 (or lower) but you've told setserial it's a
|
|
16550A or higher.</P>
|
|
<P>If single characters are missing, perhaps the serial port is being
|
|
overrun by too fast a speed. Try a slower baud rate.</P>
|
|
<P>If your device is under 1200 baud (probably a very slow old hard-copy
|
|
terminal or printer) and the text gets truncated, then the problem may
|
|
be in the serial device driver. See Printing-HOWTO under "Serial
|
|
devices" on how to fix this.</P>
|
|
|
|
<H2><A NAME="keys_erratic"></A> <A NAME="ss19.5">19.5</A> <A HREF="Text-Terminal-HOWTO.html#toc19.5">All Keys Work Erratically; Must Hit a Key a Few Times</A>
|
|
</H2>
|
|
|
|
<P> This is where you need to hit a key a few times before it works
|
|
(and see the letter you typed on the screen). If you type a word,
|
|
some (or even all) of the letters may be missing on the screen. If
|
|
letters are missing from a command it doesn't work and even if all
|
|
letters are present you may need to hit the return-key several times
|
|
to get the command to execute.</P>
|
|
<P>This may be due to two different processes opening the serial port. Both
|
|
try to read what you type. Sometimes one process (the right one
|
|
--perhaps the shell) reads what you type and at other times the other
|
|
process reads what you type. An example is where the other process is
|
|
for a serial mouse (such as gpm) which doesn't echo what you type.
|
|
So another process running on the same ttySx is eating some of what
|
|
you type. To fix this, use "ps -alx" to see what else is running on
|
|
your ttySx and kill that process.</P>
|
|
<P>You might think that lockfiles would prevent two programs from using
|
|
the same serial port at the same time. But neither the terminal nor
|
|
the gpm mouse program uses lockfiles. Since others may need to write
|
|
to your terminal, it's reasonable not to use lockfiles. See
|
|
Lock-Files in the Serial-HOWTO.</P>
|
|
|
|
<H2><A NAME="rapid_respawn"></A> <A NAME="ss19.6">19.6</A> <A HREF="Text-Terminal-HOWTO.html#toc19.6">... respawning too fast: disabled for 5 minutes</A>
|
|
</H2>
|
|
|
|
<H3>What's happening</H3>
|
|
|
|
<P>You see a message on the console like: "Getty respawning too fast:
|
|
disabled for 5 minutes". Instead of "Getty" it may display a label
|
|
(such as: Id "S2") where S2 is the label for the line in /etc/inittab
|
|
from where from where getty was called.</P>
|
|
<P>When getty starts up, it tries to send a login message to the serial
|
|
port. But if there is something seriously wrong, getty will be
|
|
immediately killed. Since the /etc/inittab file line for getty says
|
|
to "respawn", getty is started again, only to be killed again, etc.
|
|
Thus getty rapidly respawns over and over. But the operating system
|
|
intervenes and stops this nonsense (for 5 minutes). The following
|
|
sections show possible causes and fixes.</P>
|
|
|
|
<H3>Getty line in /etc/inittab file incorrect</H3>
|
|
|
|
<P>Make sure the line which calls getty in /etc/inittab is
|
|
correct. A typo in "ttySx" (or "DTxxxx" for uugetty) or in "getty"
|
|
may cause this problem. </P>
|
|
|
|
<H3>No modem control signal</H3>
|
|
|
|
<P> If the terminal doesn't send the PC a CD signal on one of the pins
|
|
of the serial port, getty will be killed unless the "local" option has
|
|
been used with getty. So a quick fix is to just use a "local" option
|
|
(-L for agetty, "CLOCAL" in /etc/gettydefs for getty_ps).</P>
|
|
<P>Another approach is to determine why CD is not being asserted. In
|
|
many cases the cable to the terminal simply doesn't have a wire for
|
|
the CD pin so you must use the "local" option. If there is a wire for
|
|
the CD pin then there may not be any signal on it until the terminal
|
|
is powered on. Note that the CD pin signal is sometimes supplied by
|
|
the DTR pin of the terminal (or the PC) by using jumper wires inside
|
|
the connector.</P>
|
|
|
|
<H3>No such serial device</H3>
|
|
|
|
<P>If the device (such as /dev/ttyS2) is bogus (doesn't physically
|
|
exist or has been disabled), then getty will be killed. You may use
|
|
"scanport" (Debian only ??) and/or "setserial" to probe for the device
|
|
or try another ttyS. Perhaps the device has been disabled in the
|
|
CMOS. See "Serial-HOWTO".</P>
|
|
|
|
<H3>No serial support</H3>
|
|
|
|
<P> Linux provides serial support either by selecting it when
|
|
compiling the kernel or by loading the serial module: serial.o. This
|
|
"respawning" error happens if serial support has neither been built
|
|
into the kernel nor provided by a serial module. You many use the
|
|
"lsmod" command to see if the serial module is loaded. To see if
|
|
serial support is built into the kernel, check a kernel configuration
|
|
file (in /boot, in the source tree, etc.)</P>
|
|
|
|
<H3><A NAME="key_shorted_getty"></A> Key shorted </H3>
|
|
|
|
<P> Another possible cause of getty respawning too rapidly is if a
|
|
keyboard key is shorted. This can happen if the key gets stuck in the
|
|
down position. With auto-repeat enabled, this "types" thousands of
|
|
characters to the login prompt. Look for a screen filled with all the
|
|
same character (in some cases, with 2 or more different characters).</P>
|
|
|
|
<H2><A NAME="after_login"></A> <A NAME="ss19.7">19.7</A> <A HREF="Text-Terminal-HOWTO.html#toc19.7">Fails Just After Login </A>
|
|
</H2>
|
|
|
|
<P> If you can login OK but then you can't use the terminal it may be
|
|
because the starting of the login shell has reconfigured the terminal
|
|
(to an incorrect setting) by a command which someone put into one of
|
|
the files that are run when you login and a shell starts. These files
|
|
include /etc/profile and ~/.bashrc. Look for a command starting with
|
|
"stty" or "setserial" and make sure that it's correct. Even if it's
|
|
done OK in one initialization file, it may be reset incorrectly in
|
|
another initialization file that you are not aware of. Ways to get
|
|
into the systems to fix it are to use another terminal or console, use
|
|
a rescue diskette, or type: "linux single" at the lilo prompt which
|
|
puts you into single user mode without running startup files.</P>
|
|
|
|
<H2><A NAME="cant_login"></A> <A NAME="ss19.8">19.8</A> <A HREF="Text-Terminal-HOWTO.html#toc19.8">Can't Login </A>
|
|
</H2>
|
|
|
|
<P> If you get a login prompt but get no response (or perhaps a
|
|
garbled response) to your login attempts a possible cause is that the
|
|
communication is bad one-way from the terminal to the computer. It
|
|
could be a bad or mis-wired cable/connector. If you're not already
|
|
using the "local" option with getty, do so to disable the modem
|
|
control lines. See
|
|
<A HREF="#getty_">Getty (used in /etc/inittab)</A>. You might also disable hardware flow control (stty
|
|
-crtscts) if it was enabled. If it now works OK then your modem
|
|
control lines are likely either not wired correctly or there's a
|
|
mistake in your set-up. Some terminals allow setting different values
|
|
(such as baud rate) for send and receive so the receive could be OK
|
|
but the send bad.</P>
|
|
<P>You should also try at another terminal (such as the console) "stty -F
|
|
/dev/ttyS1" (or ttyS whatever) to see that it's set up correctly. It
|
|
will often be in raw mode (and this is probably OK) with -icanon and
|
|
-echo etc. If the terminal incorrectly set at half-duplex (HDX), then
|
|
one set of the characters you see when you type are coming from the
|
|
terminal itself. If the characters are doubled, then the echos from the
|
|
computer are OK and you may switch to full-duplex to fix this. But if
|
|
half-duplex is set and you only see what looks like normal "echos", then
|
|
they are not coming from the computer as they should be.</P>
|
|
<P>If you get a message saying something like "login failed" then if
|
|
there is no error in typing or in the password, there may be some
|
|
restrictions on logins which will not allow you to log in.
|
|
Unfortunately, this message, may not tell you why it failed. See
|
|
<A HREF="#login_restr">Login Restrictions</A></P>
|
|
|
|
<H2><A NAME="garbled"></A> <A NAME="ss19.9">19.9</A> <A HREF="Text-Terminal-HOWTO.html#toc19.9">Garbled Login Prompt </A>
|
|
</H2>
|
|
|
|
<P> This may be due to using the wrong character set, transmission
|
|
errors due to too high of a baud rate, incompatible baud rates,
|
|
incompatible parity, or the wrong number of bits per byte. If it's a
|
|
variety of strange characters you have the wrong character set or a
|
|
high order bit is being set by mistake. If words are misspelled, try
|
|
a lower baud rate. For baud, parity, or bits/character incompatibilities
|
|
you see a lot of the same "error character" which represents a real
|
|
character that can't be displayed correctly due to an error in parity
|
|
or baud rate. The "error character" may be an upside-down question
|
|
mark or some other strange looking character such as a rectangle.</P>
|
|
<P>If you are using agetty (often just named getty), the agetty program
|
|
will detect and set parity and/or bits/character if you type something.
|
|
Try it with a return to see if it fixes it.</P>
|
|
|
|
<H2><A NAME="no_login_prompt"></A> <A NAME="ss19.10">19.10</A> <A HREF="Text-Terminal-HOWTO.html#toc19.10">No Login Prompt </A>
|
|
</H2>
|
|
|
|
<P> If there's no login prompt displayed after hitting the return-key
|
|
a few times then check the following: Use the "top" or "ps" programs
|
|
to make sure that a getty (or login) process is actually running on
|
|
the terminal. Is the terminal getting power? Is the null modem cable
|
|
plugged in to the correct ports on both the terminal and computer?</P>
|
|
<P>Check that getty isn't hanging because there is no CD signal (or no CD
|
|
wire in the cable). If such a CD signal doesn't exist you should have
|
|
specified "local" to getty by either:
|
|
<UL>
|
|
<LI>If getty_ps (Redhat, etc.) two CLOCAL flags in /etc/gettydefs
|
|
(See
|
|
<A HREF="#getty_ps">getty (part of getty_ps)</A>).</LI>
|
|
<LI>If agetty (Debian, etc.) a -L flag in /etc/inittab (See
|
|
<A HREF="#agetty_">agetty</A>).</LI>
|
|
</UL>
|
|
</P>
|
|
<P>If getty (or login) isn't running, carefully check the format for calling getty
|
|
in /etc/inittab. Make sure that it includes the current runlevel
|
|
(shown by typing the command "runlevel") and that it is valid for your
|
|
flavor of getty. Sometimes killing getty or login (it will restart
|
|
automatically) helps.</P>
|
|
|
|
<H3>Terminal was working OK</H3>
|
|
|
|
<P> Although hardware failures are possible, the problem is likely due
|
|
to something that someone did by mistake. Did someone do something
|
|
that might have loosened a cable? Did someone modify /etc/inittab or
|
|
make some other change to the software so as to prevent terminal
|
|
login? If this doesn't reveal the cause, continue reading.</P>
|
|
|
|
<H3>More diagnose</H3>
|
|
|
|
<P> The above should solve most cases (unless you've just installed a
|
|
terminal). Other causes include defective hardware or cables (must be
|
|
file-transfer), terminal setup at wrong baud-rate, terminal in local
|
|
mode, etc. At this point two different avenues of approach are (you
|
|
may pursue more than one at a time).</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#consoleD">Diagnose problem from the console</A></LI>
|
|
<LI>
|
|
<A HREF="#measure_volts">Measure voltages</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3><A NAME="consoleD"></A> Diagnose problem from the console </H3>
|
|
|
|
<P> One test is to try to copy a something to the terminal (It might
|
|
be a good idea to try this near the start of the installation process
|
|
before setting up getty). You may use the Linux copy command such as:"cp
|
|
file_name /dev/ttyS1". Or your could use: "echo any_word >
|
|
/dev/ttySx". If it doesn't work, use stty to make the interface as
|
|
simple as possible with everything disabled (such as hardware flow
|
|
control: -crtscts; parity, and modem control signals: clocal). Be
|
|
sure the baud rates and the bits/byte are the same. If nothing
|
|
happens verify that the port is alive with a voltmeter per the next
|
|
section.</P>
|
|
|
|
<H3><A NAME="measure_volts"></A> Measure voltages </H3>
|
|
|
|
<P> If you have a voltmeter handy check for a negative voltage (-4v to
|
|
-15v) at pin 3 or 2 (receive data) at the terminal side of the
|
|
file-transfer cable. The positive lead of the meter should be
|
|
connected to a good ground (a metal connector on the end of the cable
|
|
may not be grounded). If there is no such negative voltage then
|
|
check for it at the transmit pin (TxD) on the computer (see
|
|
<A HREF="#DB_pin-out">DB9-DB25</A> for the pin-out). If it's present
|
|
there but not at the receive pin (RxD) at the terminal, then the cable
|
|
is bad (loose connection, broken wire, or not a file-transfer aka
|
|
null-modem). If this voltage is absent at the computer, then its
|
|
serial port is dead. Test it with a software diagnostic test or
|
|
replace it.</P>
|
|
<P>If the serial port is alive, you may want to send a file to it (with
|
|
modem controls disabled) and watch the signal on a voltmeter (or other
|
|
electronic gadget). To check for a transmitted signal with a voltmeter,
|
|
check for a steady negative voltage when the line is idle. Then start
|
|
sending a file (or start getty). On an analog meter you should see
|
|
the needle dropping to almost 0 and fluttering about 0 as it measures
|
|
short-run averages of the bit stream. On a digital meter you will not
|
|
see the fluctuations as well but you can switch to the AC scale to see
|
|
the AC voltage created by the flow of bits. If your meter fails to
|
|
block out DC on the AC scale (the default of most analog meters), then
|
|
you could get a false high AC reading when looking at the idle DC of
|
|
-12v (or -5v) on the AC scale. Without a meter, you could connect a known
|
|
good device (such as another terminal or an external modem) to the
|
|
serial port and see if it works OK.</P>
|
|
|
|
<H2><A NAME="displays_foreign"></A> <A NAME="ss19.11">19.11</A> <A HREF="Text-Terminal-HOWTO.html#toc19.11">Displays Foreign/Weird Characters/Symbols</A>
|
|
</H2>
|
|
|
|
<P> Don't confuse this with
|
|
<A HREF="#displays_esc-seqs">Displays Escape Sequences</A>. If what you type or see on the screen is not
|
|
what's expected but looks like a foreign alphabet, math symbols,
|
|
line-drawing character, etc. then it could be that the many of bytes
|
|
that are sent to your terminal have the high order bit set (when it
|
|
shouldn't be). You are looking at the character set (or part of a
|
|
character set) which has the high order bit set. This may happen if
|
|
you have the baud rate wrong or parity set wrong (per stty). If you
|
|
have parity set per stty but inside the terminal it's 8-bit no-parity,
|
|
then the high order bit (= parity bit) will often be erroneously set.
|
|
Try stty -F /dev/ttyS? from another terminal to check if the baud
|
|
rate and parity are correct.</P>
|
|
<P>Perhaps the wrong character set (font) has been installed. An
|
|
erroneous escape sequence sent to the terminal could have switched
|
|
character sets. If you are using the mapchan program to change the
|
|
keyboard mapping, it could be incorrect.</P>
|
|
|
|
<H2><A NAME="displays_esc-seqs"></A> <A NAME="ss19.12">19.12</A> <A HREF="Text-Terminal-HOWTO.html#toc19.12">Displays Escape Sequences </A>
|
|
</H2>
|
|
|
|
<P>You may see something like "5;35H22,1" or "3;4v" or "1;24r" or
|
|
"^[[21;6H", etc., etc. Of course, the numbers and letters will be
|
|
different. They will be scattered about (either randomly or in a
|
|
strange sense of order). The display will look a mess and will likely
|
|
have other defects. Some application and commands will result in
|
|
corrupted displays.</P>
|
|
<P>What you see are escape sequences (or fragments of them) that were
|
|
sent to your terminal in order to control it, but your terminal didn't
|
|
recognize them and passed them on to the screen. It's likely that the
|
|
program you're using erroneously thinks you are using another type of
|
|
terminal. Thus it sends escape sequences that your terminal doesn't
|
|
understand. This can sometimes do strange things to your display.
|
|
Check that the TERM environment variable is set correctly (type: echo
|
|
$TERM).</P>
|
|
|
|
<H3>Telnet</H3>
|
|
|
|
<P>The problem of getting TERM right can be a bit more complex if you use
|
|
telnet. Telnet doesn't emulate a terminal but passes the value of
|
|
your TERM variable to the remote computer. If the remote computer
|
|
doesn't support your type of terminal, or changes the value of TERM to
|
|
a wrong value (on the remote) then there's trouble. Telnet
|
|
should initially set the value of TERM correctly on the remote. But
|
|
changes to the value of TERM (on the remote) could be caused by an
|
|
incorrect shell configuration file there. The first thing to do is to
|
|
check the value of TERM, both on your computer and on the remote. The
|
|
above is overly simplified since it's possible for your telnet client
|
|
to present the remote server with a list of possible TERM values which
|
|
your computer supports (if telnet knows that your computer can emulate
|
|
more than one terminal type).</P>
|
|
|
|
<H3>Terminal set to display escape sequences</H3>
|
|
|
|
<P>Another possible cause is that your terminal happens to be in a
|
|
special mode where it displays the escape sequences instead of
|
|
executing them. Then you'll also see them on the screen but they will
|
|
display in an orderly fashion. This mode is more precisely, one that
|
|
displays control codes. But since each escape sequence starts with a
|
|
control code (the "escape" character), the whole escape sequence is
|
|
not recognized by the terminal and is passed along to the screen. See
|
|
<A HREF="#control_codes">Control Codes</A>.</P>
|
|
|
|
<H2><A NAME="ss19.13">19.13</A> <A HREF="Text-Terminal-HOWTO.html#toc19.13">Slow: pauses of several seconds between bursts of characters</A>
|
|
</H2>
|
|
|
|
<P> You likely have mis-set interrupts> See the Serial-HOWTO section
|
|
starting with "Slow:"</P>
|
|
|
|
<H2><A NAME="cursor_jumps"></A> <A NAME="ss19.14">19.14</A> <A HREF="Text-Terminal-HOWTO.html#toc19.14">Cursor Jumps </A>
|
|
</H2>
|
|
|
|
<P>This error happens when you expect the cursor to move to the next
|
|
character but instead it seems to jump to another character. It can
|
|
happen in the vim editor when you've selected "showmatch" to highlight
|
|
matching brackets (or parentheses). There is nothing wrong with the
|
|
terminal and the cursor isn't jumping, but it looks like it is.</P>
|
|
<P>What is happening is that the cursor is reverse video and the
|
|
highlighting is also reverse video. So suppose you highlight (or
|
|
emphasize) a character by reverse video and then put a reverse-video
|
|
cursor over it. The cursor's reverse video will then reverse
|
|
the existing reverse video of the character and result in normal
|
|
video. The result is that both the cursor and character highlighting
|
|
have disappeared for that character and the cursor is invisible (until
|
|
you move it to a non-highlighted character).</P>
|
|
<P>OK, so the cursor suddenly disappears, but what makes it jump? For
|
|
the vim "showmatch" when you move the cursor to an opening bracket it
|
|
also highlights the closing bracket. Thus the closing bracket
|
|
suddenly becomes reverse video and it looks just like the cursor has
|
|
jumped there, but it hasn't. Similar "illusions" happen when you move
|
|
the cursor to a closing bracket (or parenthesis). This illusion when
|
|
you reverse reverse-video happens in other cases besides the vim
|
|
example just presented.</P>
|
|
|
|
<H2><A NAME="no_scroll_25"></A> <A NAME="ss19.15">19.15</A> <A HREF="Text-Terminal-HOWTO.html#toc19.15">Terminal doesn't scroll </A>
|
|
</H2>
|
|
|
|
<P> One reason may be that something is wrong with terminfo. Another
|
|
reason could be that you are outside the scrolling region set for the
|
|
terminal. Some stupid programs just assume that your terminal has 24
|
|
lines and set the scrolling region for 24 lines (by an escape sequence
|
|
sent to the terminal) without consulting terminfo to see how many
|
|
lines there actually are. Then when you use another program it may
|
|
leave the cursor on line 25 where it becomes trapped and the terminal
|
|
will not scroll. To avoid this problem, create an environment
|
|
variable "export LINES=25" and also "stty -F /dev/ttySx rows 25".
|
|
Then the programs that assume 24 lines will hopefully use 25 lines set
|
|
the scrolling region accordingly.</P>
|
|
|
|
<H2><A NAME="serial_mon"></A> <A NAME="ss19.16">19.16</A> <A HREF="Text-Terminal-HOWTO.html#toc19.16">Serial Monitoring/Diagnostics </A>
|
|
</H2>
|
|
|
|
<P> A few Linux programs will monitor the modem control lines and
|
|
indicate if they are positive (1) or negative (0).
|
|
<UL>
|
|
<LI> statserial (in Debian distribution)</LI>
|
|
<LI> The "file": /proc/tty/driver/serial. Use "watch head ..." to
|
|
monitor it. Has info on errors and byte flow.</LI>
|
|
<LI> modemstat (only works on Linux PC consoles. Will coexist with
|
|
the command line)</LI>
|
|
</UL>
|
|
|
|
You may already have the above programs. If not, go to
|
|
<A HREF="http://ibiblio.org/pub/Linux/system/serial/">Serial Software</A>. When using these, bear in mind that what you see is the
|
|
state of the lines at the host computer. The situation at the
|
|
terminal will be different since some wires are often missing from
|
|
cables while other wires cross over. As of June 1998, I know of no
|
|
diagnostic program in Linux for the serial port.</P>
|
|
|
|
<H2><A NAME="local_mode"></A> <A NAME="ss19.17">19.17</A> <A HREF="Text-Terminal-HOWTO.html#toc19.17">Local Mode </A>
|
|
</H2>
|
|
|
|
<P> In local mode, the terminal disconnects from the computer and
|
|
behaves like a typewriter (only it doesn't type on paper but on the
|
|
screen). Going back into on-line mode reconnects to the computer
|
|
allowing you to resume activities at the same point where you left off
|
|
when you went into "local". This is useful both for testing the
|
|
terminal and for educational purposes. For some terminals there is
|
|
no "local mode" but "block mode" may substitute for it. If there is
|
|
no "block mode", "half duplex" mode might work, except that what you
|
|
type gets sent to the computer also. In this case the computer may
|
|
echo the characters sent to it resulting in two characters displayed
|
|
on the screen for every character you type. To prevent this you could
|
|
shut down the computer, disconnect the RS-232 cable, etc.</P>
|
|
<P>When in local mode you may type escape sequences (starting with the
|
|
ESC key) and observe what they do. If the terminal doesn't work
|
|
correctly in local mode, it's unlikely that it will work correctly
|
|
when connected to the computer. If you're not exactly sure what an
|
|
escape sequence does, you can try it out in local mode. You might
|
|
also use it for trying out a terminal that is for sale. To get into
|
|
local mode on some terminals you first enter set-up mode and then
|
|
select "local" from a menu (or press a certain key). See
|
|
<A HREF="#enter_setup">Getting Into Set-Up (Configuration) Mode</A>.</P>
|
|
|
|
<H2><A NAME="ser_elect_test"></A> <A NAME="ss19.18">19.18</A> <A HREF="Text-Terminal-HOWTO.html#toc19.18">Serial Electrical Test Equipment </A>
|
|
</H2>
|
|
|
|
<H3>Breakout Gadgets, etc.</H3>
|
|
|
|
<P> While a multimeter (used as a voltmeter) may be all that you need
|
|
for just a few serial ports, simple special test equipment has been
|
|
made for testing serial port lines. Some are called "breakout ... "
|
|
where breakout means to break out conductors from a cable. These
|
|
gadgets have a couple of connectors which connect to serial port
|
|
connectors (either at the ends of serial cables or at the back of a
|
|
PC). Some have test points for connecting a voltmeter. Others have
|
|
LED lamps which light when certain modem control lines are asserted
|
|
(turned on). The color of the light may indicate the polarity of the
|
|
signal (positive or negative voltage). Still others have jumpers so
|
|
that you can connect any wire to any wire. Some have switches.</P>
|
|
<P>Radio Shack sells (in 2002) a "RS-232 Troubleshooter" (formerly called
|
|
"RS-232 Line Tester") Cat. #276-1401. It checks TD, RD, CD, RTS, CTS,
|
|
DTR, and DSR. A green light means on (+12 v) while red means off (-12
|
|
v). They also sell a "RS-232 Serial Jumper Box" Cat.
|
|
#276-1403. This permits connecting the pins anyway you choose. Both
|
|
these items are under the heading of "Peripheral hookup helpers".
|
|
Unfortunately, they are not listed in the index to the printed
|
|
catalog. They are on the same page as the D type connecters so look
|
|
in the index under "Connectors, Computer, D-Sub". A store chain named
|
|
"Active Components" may have them.</P>
|
|
|
|
<H3>Measuring voltages</H3>
|
|
|
|
<P> Any voltmeter or multimeter, even the cheapest that sells for
|
|
about $10, should work fine. Trying to use other methods for checking
|
|
voltage is tricky. Don't use a LED unless it has a series resistor to
|
|
reduce the voltage across the LED. A 470 ohm resistor is used for a
|
|
20 ma LED (but not all LED's are 20 ma). The LED will only light for
|
|
a certain polarity so you may test for + or - voltages. Does anyone
|
|
make such a gadget for automotive circuit testing?? Logic probes may
|
|
be damaged if you try to use them since the TTL voltages for which
|
|
they are designed are only 5 volts. Trying to use a 12 V incandescent
|
|
light bulb is not a good idea. It won't show polarity and due to
|
|
limited output current of the UART it probably will not even light up.</P>
|
|
<P>To measure voltage on a female connector you may plug in a bent paper
|
|
clip into the desired opening. The paper clip's diameter should be no
|
|
larger than the pins so that it doesn't damage the contact. Clip
|
|
an alligator clip (or the like) to the paper clip to connect up. Take
|
|
care not to touch two pins at the same time with any metal object.</P>
|
|
|
|
<H3>Taste voltage</H3>
|
|
|
|
<P> As a last resort, if you have no test equipment and are willing to
|
|
risk getting shocked (or even electrocuted) you can always taste the
|
|
voltage. Before touching one of the test leads with your tongue, test
|
|
them to make sure that there is no high voltage on them. Touch both
|
|
leads (at the same time) to one hand to see if they shock you. Then
|
|
if no shock, wet the skin contact points by licking and repeat. If
|
|
this test gives you a shock, you certainly don't want to use your
|
|
tongue.</P>
|
|
<P>For the test for 12 V, Lick a finger and hold one test lead in it.
|
|
Put the other test lead on your tongue. If the lead on your tongue is
|
|
positive, there will be a noticeable taste. You might try this with
|
|
flashlight batteries first so you will know what taste to expect.</P>
|
|
|
|
|
|
<HR>
|
|
<H2><A NAME="repair_"></A> <A NAME="s20">20.</A> <A HREF="Text-Terminal-HOWTO.html#toc20">Repair & Diagnose </A></H2>
|
|
|
|
<P> Repairing a terminal has much in common with repairing a monitor
|
|
and/or keyboard. Sometimes the built-in diagnostics of the terminal
|
|
will display on the screen. By the symptoms, one may often isolate
|
|
the trouble to one of the following: bad keyboard, CRT dead, power
|
|
electronics failure (distorted display), or digital electronics
|
|
failure. It's best to have a service manual, but even if you don't
|
|
have one, you can often still repair it.</P>
|
|
|
|
<H2><A NAME="repair_info"></A> <A NAME="ss20.1">20.1</A> <A HREF="Text-Terminal-HOWTO.html#toc20.1">Repair Books & Websites </A>
|
|
</H2>
|
|
|
|
<H3>Books</H3>
|
|
|
|
<P> Bigelow, Stephen J.: Troubleshooting & Repairing Computer
|
|
Monitors, 2nd edition, McGraw-Hill, 1997. Doesn't cover the character
|
|
generation electronics nor the keyboard.</P>
|
|
|
|
<H3>Websites</H3>
|
|
|
|
<P> The FAQ
|
|
<A HREF="http://www.repairfaq.org">http://www.repairfaq.org</A> for the newsgroup:
|
|
sci.electronics.repair is long and comprehensive, although it doesn't
|
|
cover terminals per se. See the section "Computer and Video
|
|
Monitors". Much of this information is applicable to terminals as are
|
|
the sections: "Testing Capacitors", "Testing Flyback Transformers",
|
|
etc. Perhaps in the future, the "info" on repair in this HOWTO will
|
|
consist mainly of links to the above FAQ (or the like).</P>
|
|
|
|
<H2><A NAME="ss20.2">20.2</A> <A HREF="Text-Terminal-HOWTO.html#toc20.2">Safety</A>
|
|
</H2>
|
|
|
|
<P> CRT's use high voltage of up to 30,000 volts for color (less for
|
|
monochrome). Be careful not to touch this voltage if the set is on
|
|
and the cover off. It probably won't kill you even if you do since
|
|
the amount of current it can supply is limited. But it is likely to
|
|
badly burn and shock you, etc. High voltage can jump across air gaps
|
|
and go thru cracked insulation so keep your hands a safe distance from
|
|
it. You should notice the well-insulated high voltage cable connected
|
|
to one side of the picture tube. Even when the set is off, there is
|
|
still enough residual voltage on the picture tube cable connection to
|
|
give you quite a shock. To discharge this voltage when the set is
|
|
unplugged use a screwdriver (insulated handle) with the metal blade
|
|
grounded to the picture tube ground cable with a jumper wire. Don't
|
|
use chassis ground.</P>
|
|
<P>The lower voltages (of hundreds of volts) can be even more dangerous
|
|
since they are not current limited. It is even more dangerous if your
|
|
hands are wet or if you are wearing a metal watchband, ring or the
|
|
like. In rare cases people have been killed by it so be careful. The
|
|
lowest voltages of only several volts on digital circuitry are fairly
|
|
safe but don't touch anything (except with a well insulated tool)
|
|
unless you know for sure.</P>
|
|
|
|
<H2><A NAME="ss20.3">20.3</A> <A HREF="Text-Terminal-HOWTO.html#toc20.3">Appearance of Display</A>
|
|
</H2>
|
|
|
|
<P> If the display is too dim, turn up the brightness and/or contrast.
|
|
using knobs on the exterior of the unit (if they exist). If the
|
|
width, height or centering is incorrect, there are often control knobs
|
|
for these. For some older terminals one must press an arrow key
|
|
(or the like) in set-up mode.</P>
|
|
<P>You may need to remove the cover to make adjustments, especially on
|
|
older models. You could arrange things so that a large mirror is in
|
|
front of the terminal so as to view the display in the mirror while
|
|
making adjustments. The adjustments to turn may be on a printed
|
|
circuit board. While a screwdriver (possibly Phillips-head) may be
|
|
all that's needed, inductors may require special TV alignment tools
|
|
(plastic hex wrenches, etc.). The abbreviated name of the adjustment
|
|
should be printed on the circuit board. For example, here are some
|
|
such names:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> V-Size adjusts the Vertical height (Size)</LI>
|
|
<LI> H-Size adjusts the Horizontal width (Size). It may be an inductor.</LI>
|
|
<LI> V-Pos adjusts the Vertical Position</LI>
|
|
<LI> H-Pos adjusts the Horizontal Position</LI>
|
|
<LI> V-Lin adjusts Vertical Linearity (Use if width of scan lines
|
|
differs at the top and bottom of the screen)</LI>
|
|
<LI> V-Hold adjusts Vertical Hold (Use if screen is uncontrollable
|
|
scrolling)</LI>
|
|
<LI> Bright adjusts brightness (an external knob may also exist)</LI>
|
|
<LI> Sub-Bright adjusts brightness of subdued intensity mode (often
|
|
the normal mode: dimmer than bold or bright mode).</LI>
|
|
</UL>
|
|
</P>
|
|
<P>Changing linearity may change the size so that it will need to be
|
|
readjusted. A terminal that has been stored for some time may have a
|
|
small display rectangle on the screen surrounded by a large black
|
|
Before adjusting it, leave the terminal on for a while since it will
|
|
likely recover some with use (the black borders will shrink).</P>
|
|
|
|
<H2><A NAME="ss20.4">20.4</A> <A HREF="Text-Terminal-HOWTO.html#toc20.4">Diagnose</A>
|
|
</H2>
|
|
|
|
<H3>Terminal Made a Noise or Smoked</H3>
|
|
|
|
<P> If the terminal made some noise just before it failed (or when you
|
|
turn it on after it failed) that noise is a clue to what is wrong. If
|
|
you hear a noise or see/smell smoke, immediately turn the terminal off
|
|
to prevent further damage. A pop noise may be a capacitor exploding
|
|
or a fuse blowing. A buzzing noise is likely due to arcing. The
|
|
problem may be in the high voltage power supply of several thousand
|
|
volts.</P>
|
|
<P>Remove the cover. Look for discoloration and bulging/cracked
|
|
capacitors. If the bad spot is not evident, turn it on again for a
|
|
short time and look for smoking/arcing. For arcing, a dimly lit room
|
|
will help find it. The high voltage cable (runs between the flyback
|
|
transformer and the side of the picture tube) may have broken
|
|
insulation that arcs to ground. Fix it with high-voltage insulating
|
|
dope, or special electrical tape designed say for 10,000 volts.</P>
|
|
<P>The flyback transformer (high voltage) may make only a faint clicking
|
|
or sparking noise if it fails. You may not hear it until you turn the
|
|
terminal off for a while and then turn it back on again. To track
|
|
down the noise you may use a piece of small rubber tubing (such as
|
|
used in automobiles) as a stethoscope to listen to it. But while you
|
|
are listening for the noise, the terminal is suffering more damage so
|
|
try find it fast (but not so fast as to risk getting shocked).</P>
|
|
<P>A shorted power supply may cause a fuse to blow. Replacing a blown
|
|
fuse may not solve the problem as the same short may blow the fuse
|
|
again. Inspect for any darkened spots due to high heat and test those
|
|
components. Shorted power transistors may cause the fuse to blow.
|
|
They may be tested with a transistor checker or even with an
|
|
ohm-meter. Use the low ohm scale on an ohm-meter so that the voltage
|
|
applied by the meter is low. This will reduce the possible damage to
|
|
good components caused by this test voltage.</P>
|
|
<P>If the terminal has been exposed to dampness such as being stored in a
|
|
damp place or near a kitchen with steam from cooking, a fix may be to
|
|
dry out the unit. Heating a "failed" flyback transformer with a blow
|
|
dryer for several minutes may restore it.</P>
|
|
|
|
<H3>Terminal Made No Noise</H3>
|
|
|
|
<P> A blank screen may be due to someone turning the brightness
|
|
control to the lowest level or to aging. The next thing to do is to
|
|
check the cables for loose or broken connections. If there is no sign
|
|
of power, substitute a new power cord after making sure that the power
|
|
outlet on the wall is "hot".</P>
|
|
<P>If the keyboard is suspected, try it on another terminal of the same
|
|
type or substitute a good keyboard. Wiggle the keyboard cable ends
|
|
and the plug. Wires inside cables may break, especially near their
|
|
ends. If the break is verified by wiggling it (having the problem go
|
|
on and off in synchronization with the wiggles), then one may either
|
|
get a new cable or cut into the cable and re-solder the breaks, etc.</P>
|
|
<P>One of the first things to do if the keyboard works is to put the
|
|
terminal into
|
|
<A HREF="#local_mode">Local Mode</A>. If it works OK
|
|
in local, then the problem is likely in the connection to the host
|
|
computer (or incorrect interface) or in the UART chips of the
|
|
terminal.</P>
|
|
|
|
<H2><A NAME="ss20.5">20.5</A> <A HREF="Text-Terminal-HOWTO.html#toc20.5">Detective work</A>
|
|
</H2>
|
|
|
|
<P>By carefully inspecting the circuitry, one may often find the cause
|
|
of the problem. Look for discoloration, cracks, etc. An intermittent
|
|
problem may sometimes be found by tapping on components with a
|
|
ball-point pen (not the metal tip of course). A break in the
|
|
conductor of a printed circuit board may sometimes be revealed by
|
|
flexing the board. Solder that looks like it formed a drop or a
|
|
solder joint with little solder may need re-soldering. Soldering may
|
|
heat up transistors (and other components) and damage them so use a
|
|
heat sink if feasible. One failure may cause others, so unless you
|
|
find the original cause, the failure may reoccur.</P>
|
|
<P>If you have a common brand of terminal, you may be able to search the
|
|
Internet (including newsgroup postings) to find out what the most
|
|
frequent types of problems are for your terminal and perhaps
|
|
information on how to fix it. If you find that a certain component
|
|
is bad you may search for this component (for example R214 wyse) and
|
|
hopefully find a report by someone else who had the same problem.
|
|
Such a report may indicate other components that failed at the same
|
|
time. If a component is damaged so badly that its value can't be
|
|
read, then you might find it on the Internet. The manufacturer may
|
|
have on-line data that search engines don't index.</P>
|
|
<P>To see if the digital electronics work, try (using a good keyboard)
|
|
typing at the bad terminal. Try to read this typing at a
|
|
good terminal (or the console) using the copy command or with a
|
|
terminal communication program such as picocom. You may need to hit
|
|
the return key at the terminal in order to send a line. One may
|
|
ask the bad terminal for its identity etc. from another terminal.
|
|
This will show if two-way communication works.</P>
|
|
|
|
<H2><A NAME="ss20.6">20.6</A> <A HREF="Text-Terminal-HOWTO.html#toc20.6">Error Messages on the Screen</A>
|
|
</H2>
|
|
|
|
<P> You are in luck if you see an error message on the screen. This
|
|
usually happens when you first turn the terminal on.</P>
|
|
|
|
<H3>Keyboard Error</H3>
|
|
|
|
<P> This usually means that the keyboard is not plugged in, or that
|
|
the connection is loose. For more serious problems see
|
|
<A HREF="#keyboards_">Keyboards</A></P>
|
|
|
|
<H3>Checksum Error in NVR</H3>
|
|
|
|
<P> NVR is "Non-Volatile RAM". This means that the NVR where the
|
|
set-up information is stored has become corrupted. The terminal will
|
|
likely still work but the configuration that was last saved when
|
|
someone last configured the terminal has likely been lost. Try
|
|
configuring again and then save it. It might work. On very old
|
|
terminals (early 1980's) there was a battery-powered CMOS to save the
|
|
configuration so in this case the problem could be just a dead
|
|
battery. Sometimes the EEPROM chip (no battery needed) goes bad after
|
|
too many saves. It may be hard to find. If you can't fix it you are
|
|
either stuck with the default configuration or you may have escape
|
|
sequences sent to the terminal when you start it up to try to
|
|
configure it.</P>
|
|
|
|
<H2><A NAME="ss20.7">20.7</A> <A HREF="Text-Terminal-HOWTO.html#toc20.7">Capacitors</A>
|
|
</H2>
|
|
|
|
<P> Electrolytic capacitors have a metal shell and are may become weak
|
|
or fail if they set for years without being used. Sometimes just
|
|
leaving the terminal on for a while will help partially restore them.
|
|
If you can, exercise any terminals you have in storage by turning them
|
|
on for a while every year or so.</P>
|
|
<P>Note that cheap electrolytic capacitors designed for use in audio
|
|
circuits may fail if used in high frequency horizontal circuitry. For
|
|
this, you need low resistance (low ESR) capacitors. Replace
|
|
non-polarized capacitors (NP) with the same (or with "bi-polar").</P>
|
|
<P>If the terminal display takes several minutes of warmup before it's
|
|
OK then it's likely that you have one or more bad electrolytic
|
|
capacitors. One trick to find the bad one is to parallel each
|
|
suspected bad one with a good one (of at least the same voltage rating
|
|
and capacitance of roughly the same order of magnitude). If the
|
|
display improves a lot when you do this, then you've likely found the
|
|
bad capacitor. Be careful not to get shocked when doing this. The
|
|
actual voltage with respect to ground may be much higher than the
|
|
voltage rating of the capacitor.</P>
|
|
|
|
<H2><A NAME="keyboards_"></A> <A NAME="ss20.8">20.8</A> <A HREF="Text-Terminal-HOWTO.html#toc20.8">Keyboards </A>
|
|
</H2>
|
|
|
|
<H3>Interchangeability</H3>
|
|
|
|
<P> The keyboards for terminals are not the same as keyboards for
|
|
PC's. The difference is not only in the key layout but in the codes
|
|
generated when a key is pressed. Also, keyboards for various brands
|
|
and models of terminals are not always interchangeable with each
|
|
other. Sometimes one get an "incompatible" keyboard to partially work
|
|
on a terminal: All the ASCII keys will work OK, but special keys such
|
|
as set-up and break will not work correctly.</P>
|
|
|
|
<H3>How They Work</H3>
|
|
|
|
<P> Most keyboards just make a simple contact between two conductors
|
|
when you press a key. Electronics inside a chip in the keyboard
|
|
converts this contact closure into a code sent over the keyboard's
|
|
external cable. Instead of having a separate wire (or conductor)
|
|
going from each key to the chip, the following scheme is used:
|
|
Number the conductors say from 1-10 and A-J. For example: conductor 3
|
|
goes to several keys and conductor B goes to several keys, but only
|
|
one key has both conductors 3 and B going to it. When that key is
|
|
pressed, a short circuit is established between 3 and B. The chip
|
|
senses this short and knows what key has been pressed. Such a scheme
|
|
reduces the number of conductors needed (and reduces the number of
|
|
pins needed on the chip). It's a similar scheme to what is called a
|
|
"crossbar switch".</P>
|
|
|
|
<H3>Modern vs Old Keyboards</H3>
|
|
|
|
<P> While the modern keyboard and the old fashioned type look about
|
|
the same, the mechanics of operation are different. The old ones have
|
|
individual key switches under the key-caps with each switch enclosed
|
|
in a hard plastic case. The modern ones use large flexible plastic
|
|
sheets (membrane) the size of the keyboard. A plastic sheet with
|
|
holes in it is sandwiched between two other plastic sheets containing
|
|
printed circuits (including contact points). When you press a key,
|
|
the two "printed" sheets are pressed together at a certain point,
|
|
closing the contacts printed on the sheets at that point.</P>
|
|
|
|
<H3><A NAME="two_chars"></A> One Press Types 2 Different Characters </H3>
|
|
|
|
<P> If, due to a defect, conductors 3 and 4 become shorted together
|
|
then pressing the 3-B key will also short 4 and B and the chip will
|
|
think that both keys 3-B and 4-B have been pressed. This is likely to
|
|
type 2 different characters when all you wanted was one character.</P>
|
|
|
|
<H3>Keyboard doesn't work at all</H3>
|
|
|
|
<P> If none of the keys work try another keyboard (if you have one) to
|
|
verify that the keyboard is the problem. One cause is a broken wire
|
|
inside the cord (cable) that connects it to the terminal. The most
|
|
likely location of the break is at either end of the cord. Try
|
|
wigging the ends of the cord while tapping on a key to see if it works
|
|
intermittently. If you find a bad spot, you may carefully cut into
|
|
the cord with a knife at the bad spot and splice the broken conductor.
|
|
Sometimes just a drop of solder will splice it. Seal up the cord with
|
|
electrical tape, glue, or caulk. A keyboard that has gotten wet may
|
|
not work at all until it's dry.</P>
|
|
|
|
<H3>Typing b displays bb, etc. (doubled)</H3>
|
|
|
|
<P> If all characters appear double there is likely nothing wrong with
|
|
the keyboard. Instead, your terminal has likely been incorrectly set
|
|
up for half-duplex (HDX or local echo=on) and every character you type
|
|
is echoed back both from the electronics inside your terminal and from
|
|
your host computer. If the two characters are not the same, there may
|
|
be a short circuit inside your keyboard. See
|
|
<A HREF="#two_chars">One Press Types 2 Different Characters</A></P>
|
|
|
|
<H3>Row upon row of the same character appears</H3>
|
|
|
|
<P> This may happen when auto-repeat is enabled and a key is held
|
|
pressed down (or the like). It may be a key that sticks down when
|
|
typed or it could be an electrical short that has the same
|
|
effect.</P>
|
|
|
|
<H3>Key sticks in down position (individual switches)</H3>
|
|
|
|
<P> First try tapping on it hard several times but it's not likely to
|
|
fix it. Next, your can either remove the keycap (if it is removable)
|
|
and squirt a little cleaner on the push rod or work the key up and
|
|
down while pushing on it sideways (or both). If this doesn`t work you
|
|
may need to take the switch apart and clean the components.</P>
|
|
<P>If you decide to remove the keycap see
|
|
<A HREF="#kbd_sw">Keyboards with individual switches</A>. Press repeatedly on the
|
|
push rod until it works OK and also displays its character on the
|
|
screen. At first, the cleaner may cause the key to fail to display
|
|
its character. Some keys stick due to stickiness on the keycap bottom
|
|
surface.. If the key sticks in the fully down position this could be
|
|
the problem. So you might need to clean this this area too.</P>
|
|
<P>If you decide to push it sideways, use a small screwdriver to push
|
|
sideways with while pushing the key up and down with both your finger
|
|
and the screwdriver. You should push it sideways in one of the four
|
|
directions and try different directions. What you are doing by this
|
|
is attempting to force out a foreign particles that are rubbing on the
|
|
side of the key's push-rod and making it stick. Again, the problem
|
|
may return later.</P>
|
|
<P>Always test the key just after fixing it and a short time later. To test
|
|
the key, push it down very slowly and see if it sticks. Also push it
|
|
sideways a little as you're pushing it down. If you hit it fast or
|
|
push it straight down, then you may not observe the stickiness. This
|
|
test will detect a key that seemingly works OK but is likely to cause
|
|
trouble later on.</P>
|
|
|
|
<H3>Key electrically shorted</H3>
|
|
|
|
<P>If you suspect that a key is shorted out, fix it by cleaning the
|
|
contacts per
|
|
<A HREF="#clean_keys">Cleaning Keyboard Contacts</A>.
|
|
If this problem happens at the login prompt see
|
|
<A HREF="#key_shorted_getty">Key shorted</A>.</P>
|
|
|
|
<H3>Liquid spilled on the keyboard</H3>
|
|
|
|
<P> If water or watery liquid has been spilled on the keyboard (or if
|
|
it was exposed to rain, heavy dew, or dampness) some (or all) keys may
|
|
not work right. The dampness may cause a key to short out (like it
|
|
was pressed down all the time) and you may see the screen fill up with
|
|
that letter if auto-repeat is enabled. If it's gotten wet and then
|
|
partially (or fully) dried out, certain keys may not work due to
|
|
deposits on the contact surfaces. For the modern type of keyboard,
|
|
one may readily take apart the plastic sheets inside and dry/clean
|
|
them. For the old type one may let it dry out in the sun or oven (low
|
|
temp.). When it's dry it may still need contact cleaner on some keys
|
|
as explained below.</P>
|
|
|
|
<H3><A NAME="clean_keys"></A> Cleaning keyboard contacts </H3>
|
|
|
|
<H3>Keyboards with membranes</H3>
|
|
|
|
<P> On some newer keyboards, the plastic sheets (membranes) are easy
|
|
to remove for inspection and cleaning if needed. You only need to
|
|
remove several screws to take apart the keyboard and get to the
|
|
sheets. On some old IBM keyboards the sheets can't be removed without
|
|
breaking off many plastic tabs which will need to be repaired with
|
|
glue to put back (probably not worthwhile to repair). Such a keyboard
|
|
may sometimes be made to work by flexing, twisting, and/or pounding
|
|
the assembly containing the plastic sheets.</P>
|
|
|
|
<H3><A NAME="kbd_sw"></A> Keyboards with individual switches </H3>
|
|
|
|
<P> What follows is for older keyboards that have separate hard
|
|
plastic switches for each key. Before going to all the work of
|
|
cleaning electrical contacts first try turning the keyboard
|
|
upside-down and working the bad keys. This may help dislodge dirt,
|
|
especially if you press the key hard and fast to set up vibration.
|
|
Pressing the key down and wiggling it from side to side, etc. often
|
|
helps.</P>
|
|
<P>If this doesn't work, you may try to clean the key switch with a
|
|
liquid contact cleaner (available at electronic supply stores) which
|
|
usually comes in a spay can. To get to the switch, you first need to
|
|
remove the key-cap (the square that you hit with your finger while
|
|
typing). Warning: Key-caps on modern keyboards can't be removed.
|
|
Often, the key-caps may be removed by prying them upward using a small
|
|
screwdriver with the tip placed under a key while preventing excessive
|
|
tilting of the key with a finger. There exists a special tool known
|
|
as keycap puller but you can get by without it. The key-cap may tilt
|
|
a bit and wobble as it comes loose. It may even fly up into the air
|
|
and onto the floor.</P>
|
|
<P>Then you may have two choices on how to clean the contacts: Use
|
|
contact cleaner spray directly on top of the key switch, or take the
|
|
key switch apart and clean it (the best way if it comes apart easily).
|
|
Still another choice is to replace the key switch with a new or used
|
|
one but this is often more work (and more cost if you have to go thru
|
|
the trouble of finding a replacement.</P>
|
|
<P>Directly spraying contact cleaner into the top of the key switch,
|
|
without taking the switch apart, is the fastest method but the cleaner
|
|
may not reach the contacts it's supposed to clean. Before spraying,
|
|
clean the area around it a little. With the keyboard live (or with
|
|
the key contacts connected to an ohm-meter) use the plastic tube which
|
|
came with the spray to squirt cleaner so it will get inside the key
|
|
switch. Try to move the key push rod up and down while spraying.
|
|
Don't let the cleaning liquid get under nearby keys where it may pick
|
|
up dust and then seep (with the dust) into adjacent key switches. If
|
|
you make this mistake you may fix one key but damage nearby keys. If
|
|
this should happen, immediately work (repeatedly press) the affected
|
|
nearby keys until they continue to work OK.</P>
|
|
<P>You might tilt the keyboard so that the cleaner flows better into the
|
|
contacts. For the CIT101e terminal with an Alps keyboard, this means
|
|
tilting the top row of numeric keys up toward the ceiling. While
|
|
moving the key switch up and down with a pen or small screwdriver
|
|
handle avoid getting the toxic cleaner liquid on your skin (or wear
|
|
gloves). You might try turning the keyboard upside-down while working
|
|
the key to drain off remaining cleaner. The more cleaner you squirt
|
|
in the more likely it will fix it but it is also more likely to do
|
|
more damage to the plastic or contaminate adjacent keys, so use what
|
|
you think is just enough to do the job. Once the key works OK, work
|
|
it up and down a little more and test it a half minute later, etc. to
|
|
make sure it will still work OK.</P>
|
|
<P>Sometimes a key works fine when the contacts inside are saturated with
|
|
contact cleaner liquid. But when the liquid dries a few minutes later
|
|
then the resulting scale deposit left from the evaporation of the
|
|
cleaning liquid on the contacts, prevents good contact. Then the key
|
|
may work erratically (if at all). Operating the key when the liquid
|
|
is drying inside may help. Some switches have the contacts nearly
|
|
sealed inside so little if any contact cleaner reaches the contacts.
|
|
The cleaner that does get to the contacts may carry contamination with
|
|
it (cleaning around the tops before spraying helps minimize this).</P>
|
|
<P>If you want to disassemble the key switch, first inspect it to see
|
|
if it comes apart (and if so, how). Sometimes one may remove the cover
|
|
of the switch without removing the switch from the keyboard. To do
|
|
this pry up (or pull up) the top of the key switch after prying apart
|
|
thin plastic tabs that retain it. You may be able to use two small
|
|
screwdrivers for this and be able to pry up the switch while prying
|
|
apart the plastic retaining tabs. Don't pry too hard or you may break
|
|
the plastic. If this can't be done, you may have to unsolder the
|
|
switch and remove it in order to take it apart (or replace it). Once
|
|
the switch has been taken apart you still may not be able to see the
|
|
contacts if the contact surfaces are sandwiched together (nearly
|
|
touching). You may put contact cleaner on the contacts by squirting
|
|
some cleaner on an edge so it can penetrate onto the contacts. Insert
|
|
a tiny screwdriver blade just a little so as to pry apart the edges as
|
|
you apply the cleaner. This will help the cleaner reach the contacts.
|
|
Work the contacts open and closed with a screwdriver to help clean
|
|
them and note if the key is working by looking at the terminal screen. </P>
|
|
<P>There may be some kind of clip holding the contact surfaces together
|
|
which needs to be removed so you can pry them apart. Take care not to
|
|
loose small parts as they may fly up into the air when taking apart a
|
|
key switch. As a last resort, you may try bending the moving part
|
|
that the push-rod pushes so as to make a stronger contact. In my
|
|
terminal, this part looks like the electrical contact but it just
|
|
pushes the real electrical contact thru a thin insulator.</P>
|
|
<P>When putting the key switch back together, make sure that the spring
|
|
is in the right place. If, after you assemble the switch, the key
|
|
pushes down too hard or too easy, the spring is likely not positioned
|
|
right. If the spring is supposed to be recessed into a hole on the
|
|
push rod, one way to temporarily "glue" the spring into the push-rod
|
|
is to use a half-drop of water on the end of the spring. Then insert
|
|
this end into the push rod and assemble quickly before the water
|
|
dries. This should keep the spring from falling out of the push rod
|
|
during assembly. Instead of using water, you may stand the keyboard on
|
|
end (or upside-down) to keep the spring from falling out during
|
|
assembly.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s21">21.</A> <A HREF="Text-Terminal-HOWTO.html#toc21">Appendix A: General</A></H2>
|
|
|
|
<H2><A NAME="ss21.1">21.1</A> <A HREF="Text-Terminal-HOWTO.html#toc21.1">List of Linux Terminal Commands</A>
|
|
</H2>
|
|
|
|
<H3>Sending a command to the terminal</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#setterm_">setterm</A>: long options</LI>
|
|
<LI>
|
|
<A HREF="#tput">tput</A>: terse options</LI>
|
|
<LI> reset: initializes only</LI>
|
|
<LI> tset: same as reset</LI>
|
|
<LI> clear: clears screen</LI>
|
|
<LI> setterm -reset: sends reset string</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Configuring the terminal device driver</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#set_serial">Setserial</A>:</LI>
|
|
<LI>
|
|
<A HREF="#stty_">Stty</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Terminfo</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="#tic">Terminfo Compiler (tic)</A> terminfo compiler
|
|
& translator</LI>
|
|
<LI> toe: shows list of terminals for which you have terminfo
|
|
files</LI>
|
|
<LI>
|
|
<A HREF="#infocmp">infocmp</A> compares or displays terminfo
|
|
entries</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Other</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> gitkeys: shows what bytes each key sends to the host.</LI>
|
|
<LI> tty: shows what tty port you are connected to.</LI>
|
|
<LI> reset -q: shows the value of TERM, the terminfo entry name</LI>
|
|
<LI>
|
|
<A HREF="#reset_">reset</A>: sets TERM interactively and initializes</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss21.2">21.2</A> <A HREF="Text-Terminal-HOWTO.html#toc21.2">The Internet and Books</A>
|
|
</H2>
|
|
|
|
<H3><A NAME="internet_"></A> Terminal Info on the Internet </H3>
|
|
|
|
<P> In the first decade of the 20th century,
|
|
http://www.cs.utk.edu/ shuford/terminal_index.html was Shuford's Website
|
|
at the University of Tennessee. It was the major sit for information
|
|
about text terminals but is now (2013) defunct. Perhaps one can find it
|
|
archived on the "Wayback" machine.
|
|
http://www.cs.utk.edu/ shuford/terminal/repair_hints_news.txt was
|
|
Shuford's repair archive of newsgroup postings on terminal repair. See
|
|
below for the vt100 part of this website which is still on the internet.</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="http://www.vt100.net">vt100 section of Shuford's Website</A> </LI>
|
|
<LI>
|
|
<A HREF="http://en.wikipedia.org/wiki/Text_terminal">Text-terminal - Wikipedia</A></LI>
|
|
<LI>
|
|
<A HREF="http://en.wikipedia.org/wiki/POSIX_terminal_interface">Terminal Interface per Wikipedia</A> </LI>
|
|
<LI>
|
|
<A HREF="www.gnu.org/manual/glibc/html_chapter/libc_12.html">Low-Level Terminal Interface</A> part of "GNU C Library Reference
|
|
Manual" (in libc (or glibc) docs package). It covers the detailed
|
|
meaning of "stty" commands, etc.</LI>
|
|
<LI>
|
|
<A HREF="http://www.boundless.com/terminals.html">Boundless</A> purchased the VT and Dorio terminal business from
|
|
DEC. Boundless used to have online Specs of their ADDS, VT, and
|
|
DORIO terminals but that link (in previous versions of this HOWTO) is
|
|
now dead. </LI>
|
|
<LI> Wyse had detailed info (such as escape sequences) in it's
|
|
knowledge base. It's not as complete as a real manual since it mainly
|
|
cover "native" personality. It was Wyse text-terminals database" at
|
|
http://www.wyse.com/service/support/kbase/wyseterm.aspi but it's defunct.
|
|
You may still access their knowledge base (does it still cover
|
|
text-terminals) by registering. Start at
|
|
<A HREF="www.wyse.com">www.wyse.com</A>.</LI>
|
|
<LI>
|
|
<A HREF="http://dickey.his.com/ncurses/ncurses.faq.html">ncurses FAQ</A> </LI>
|
|
<LI> comp.terminals is the newsgroup for
|
|
terminals </LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Books related to terminals</H3>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> EIA-232 serial port see
|
|
<A HREF="#RS232_books">EIA-232 (RS-232) Books</A>.</LI>
|
|
<LI> Repair see
|
|
<A HREF="#repair_info">Repair Books & Websites</A>.</LI>
|
|
<LI> Terminfo database see
|
|
<A HREF="#termcap_docs">Termcap Documents</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H3>Entire books on terminals</H3>
|
|
|
|
<P> As far as I know, there is no satisfactory book on text terminals
|
|
Although this HOWTO has been published as a book, I don't suggest that
|
|
that you buy it if you have access to the online version which I'm
|
|
improving on every few months or so. The following are mainly of
|
|
historical interest:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> Handbook of Interactive Computer Terminals by Duane E. Sharp;
|
|
Reston Publishing Co. 1977. (mostly obsolete)</LI>
|
|
<LI> Communicating with Display Terminals by Roger K. deBry;
|
|
McGraw-Hill 1985. (mostly on IBM synchronous terminals)</LI>
|
|
</UL>
|
|
</P>
|
|
<P>The "HANDBOOK ... " presents brief specifications of over 100 different
|
|
models of antique terminals made in the early 1970's by over 60
|
|
different companies. It also explains how they work physically but
|
|
has a diagram for a CRT which erroneously shows electrostatic
|
|
deflection of the electron beam (p. 36). Terminals actually used
|
|
magnetic deflection (even in the 1970's). This book explains a number
|
|
of advanced technical concepts such as "random scan" and "color
|
|
penetration principle".</P>
|
|
<P>The "COMMUNICATING ... " book in contrast to the "Handbook ... " ignores
|
|
the physical and electronic details of terminals. It has an entire
|
|
chapter explaining binary numbers (which is not needed in a book on
|
|
terminals since this information is widely available elsewhere). It
|
|
seems to mostly cover old IBM terminals (mainly the 3270) in block and
|
|
synchronous modes of operation. It's of little use for the commonly
|
|
used ANSI terminals used today on Unix-like systems. Although it does
|
|
discuss them a little it doesn't show the various wiring schemes used
|
|
to connect them to serial ports.</P>
|
|
|
|
<H3>Books with chapters on terminals</H3>
|
|
|
|
<P> These chapters cover almost nothing about the terminals themselves
|
|
and their capabilities. Rather, these chapters are mostly about how
|
|
to set up the computer (and its terminal driver) to work with
|
|
terminals. Due to the differences of different Unix-like systems,
|
|
much of the information does not not apply to Linux.</P>
|
|
<P>
|
|
<UL>
|
|
<LI> Unix Power Tools by Jerry Peck et. al. O'Reilly 1998.
|
|
Ch. 5 Setting Up Your Terminal, Ch. 41: Terminal and Serial Line
|
|
Settings, Ch. 42: Problems With Terminals</LI>
|
|
<LI> Advanced Programming in the Unix Environment by W. Richard Stevens
|
|
Addison-Wesley, 1993. Ch. 11: Terminal I/O, Ch. 19: Pseudo Terminals</LI>
|
|
<LI> Essential System Administration by Aleen Frisch, 2nd ed.
|
|
O'Reilly, 1998. Ch. 11: Terminals and Modems.</LI>
|
|
</UL>
|
|
</P>
|
|
<P>The "UNIX POWER TOOLS" book has 3 short chapters on text terminals.
|
|
It covers less ground than this HOWTO but gives more examples to help
|
|
you.</P>
|
|
<P>The "ADVANCED PROGRAMMING ... " Chapter 11 covers only the device driver
|
|
included in the operating system to deal with terminals. It explains
|
|
the parameters one gives to the stty command to configure the
|
|
terminal.</P>
|
|
<P>The "ESSENTIAL SYSTEM ..." book's chapter has more about terminals
|
|
than modems. It seems well written.</P>
|
|
|
|
<H2><A NAME="non_linux"></A> <A NAME="ss21.3">21.3</A> <A HREF="Text-Terminal-HOWTO.html#toc21.3">Non-Linux OSs </A>
|
|
</H2>
|
|
|
|
<P>Under Microsoft's DOS one may use the DOS command "ctty COM2" so
|
|
that the DOS command line will display on a serial terminal (on COM2
|
|
in this example). Unfortunately one can then no longer
|
|
use the computer monitor since MS DOS is not a multiuser operating
|
|
system. Nor can more than one terminal be used. So this capability
|
|
is of little (if any) benefit. If you emulate DOS under Linux with
|
|
the free dosemu, it's reported that you can run several terminals
|
|
(multiuser). But it's reported that PCTerm emulation doesn't work
|
|
with it (yet ??).</P>
|
|
<P>While MS didn't create a "multiuser DOS" OS, others did. This permits
|
|
the use of many terminals on one DOS PC. It's compatible with most
|
|
MS-DOS software. One multiuser DOS OS is named "REAL/32". The
|
|
terminal's "pcterm" emulation is used here. There also may be a
|
|
"scan" (scancodes) setup mode which needs to be set. Other OSs such
|
|
as PICK, PC-MOS, and Concurrent DOS were/are multiuser and support
|
|
terminals.</P>
|
|
<P>There are 3 programs for Linux which let you run Windows applications
|
|
on a Linux PC: free: Wine, non-free: VMware and NeTraverse. Can they
|
|
use text-terminals under DOS? Wine can't since it doesn't have a DOS
|
|
mode. The other two require you to run the MS Windows OS software as
|
|
a "guest OS". The guest MS Windows OS has a DOS mode but it's not of
|
|
much use for text-terminals since it's not multiuser.</P>
|
|
<P>For other unix-like OSs, the configuration of the host computer for
|
|
terminals is usually significantly different than for Linux. Here are
|
|
some links to on-line manuals for non-linux systems.</P>
|
|
<P>
|
|
<UL>
|
|
<LI>
|
|
<A HREF="http://docsrv.sco.com:507/en/HANDBOOK/serial_terminal_adding.html">Adding Serial Terminals</A> in SCO OpenServer Handbook.</LI>
|
|
<LI> Hewlett-Packard's HP-UX
|
|
<A HREF="http://docs.hp.com/en/B2355-90675/ch03.html">Configuring Terminals and Modems</A></LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="esc"></A> <A NAME="s22">22.</A> <A HREF="Text-Terminal-HOWTO.html#toc22">Appendix B: Escape Sequence Commands Terminology </A></H2>
|
|
|
|
<P> These are sometimes called "control sequences". This section of
|
|
Text-Terminal-HOWTO is incomplete (and may never be complete as there
|
|
are such a huge number of control sequences). This section is for
|
|
reference and perhaps really belongs in something that would be called
|
|
"Text-Terminal-Programming-HOWTO".</P>
|
|
<P>An example of an ANSI standard escape sequence is ESC[5B which moves
|
|
the cursor down 5 lines. ESC is the Escape character. The parameter
|
|
5 is included in the sequence. If it were 7 the cursor would move
|
|
down 7 lines, etc. A listing for this sequence as "move cursor down x
|
|
lines: ESC[xB" is easy to to understand. But command jargon such as:
|
|
"tertiary device attribute request" is less comprehensible. This
|
|
section will try to explain some of the more arcane jargon used for
|
|
escape sequence commands. A full listing (including the escape
|
|
sequence codes for the ANSI standard) is a "wish list" project. Since
|
|
many escape sequences do the same thing as is done when setting up the
|
|
terminal with
|
|
<A HREF="#set_up_pars">Set-Up Options</A>, such
|
|
escape sequences options will not be repeated here.</P>
|
|
|
|
<H2><A NAME="esc_seq_lists"></A> <A NAME="ss22.1">22.1</A> <A HREF="Text-Terminal-HOWTO.html#toc22.1">Esc Sequence Lists </A>
|
|
</H2>
|
|
|
|
<P>See url url= "http://www.neoware.com/docs/teemtalk/t2k17pro.pdf"
|
|
name="TeemTalk.2000 Programmer's Guide v 1.7"> in pdf format. But
|
|
there are some sites that have info for certain terminals. For VT
|
|
terminals see
|
|
<A HREF="http://www.vt100.net/">VT Manuals</A>.
|
|
Other lists have disappeared from the internet. </P>
|
|
|
|
<H2><A NAME="ss22.2">22.2</A> <A HREF="Text-Terminal-HOWTO.html#toc22.2">8-bit Control Codes</A>
|
|
</H2>
|
|
|
|
<P> Table of 8-bit DEC control codes (in hexadecimal). Work on VT2xx or
|
|
later. CSI is the most common.
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ACRONYM FULL_NAME HEX REPLACES
|
|
IND Index (down one line) 84 ESC D
|
|
NEL Next Line 85 ESC E
|
|
RI Reverse Index (one line up) 8D ESC M
|
|
SS2 Single Shift 2 8E ESC N
|
|
SS3 Single Shift 3 8F ESC O
|
|
DCS Device Control String 90 ESC P
|
|
CSI Control Sequence Introducer) 9B ESC [
|
|
ST String Terminator 9C ESC \
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
<H2><A NAME="printer_esc"></A> <A NAME="ss22.3">22.3</A> <A HREF="Text-Terminal-HOWTO.html#toc22.3">Printer Esc </A>
|
|
</H2>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI> Auto Print on/off: When on, data from the host is also teed
|
|
(sent) to the printer port of the terminal (and also shows on the
|
|
terminal screen).</LI>
|
|
<LI> Print Controller on/off: When on, data from the host is sent
|
|
only to the printer (nothing shows on the terminal screen).</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss22.4">22.4</A> <A HREF="Text-Terminal-HOWTO.html#toc22.4">Reports</A>
|
|
</H2>
|
|
|
|
<P> These sequences are usually a request sent from the host to
|
|
request a report from the terminal. The terminal responds by sending
|
|
a report (actually another escape sequence) to the host which has
|
|
embedded in it certain values telling the host about the current state
|
|
of the terminal. In some cases a report may be sent to the host even
|
|
if it wasn't asked for. This sometimes happens when set-up is exited.
|
|
By default no unsolicited reports should be sent.</P>
|
|
<P>
|
|
<UL>
|
|
<LI> Request for Status (Report Operating Status): Meaning of
|
|
replies for VT100 is either "I'm OK" or "I'm not OK"</LI>
|
|
<LI> Request for Device Attributes: The "device" is usually the
|
|
printer. Is there a printer? Is it ready?</LI>
|
|
<LI> Reqest for Tertiary Device Attributes (VT): Reply is report that
|
|
was entered during set-up. The tertiary device is the 3rd device
|
|
(the printer or auxiliary port device ??). The 1st device may
|
|
be the host computer and the 2nd device the terminal.</LI>
|
|
<LI> Request for Terminal Parameters: What is the parity, baud
|
|
rate, byte width, etc. This request doesn't seem to make much sense,
|
|
since if the host didn't already know this it couldn't communicate
|
|
with the terminal or send a reply.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss22.5">22.5</A> <A HREF="Text-Terminal-HOWTO.html#toc22.5">Cursor Movements</A>
|
|
</H2>
|
|
|
|
<P> The cursor is where the next character received from the host will
|
|
be displayed. Most of the cursor movements are self-explanatory.
|
|
"index cursor" means to move the cursor down one line. Cursor
|
|
movements may be relative to the current position such as "move 4
|
|
spaces left" or absolute such as "move to row 3, column 39". Absolute
|
|
is called "Direct Cursor Positioning" or "Direct Cursor Addressing".</P>
|
|
<P>The home position is row 1 col. 1 (index origin is 1). But where this
|
|
home position is on the physical screen is not completely clear. If
|
|
"Cursor Origin Mode" = "Relative Origin Mode" is set, then home is at
|
|
the top of the scrolling region (not necessarily the top of the
|
|
screen) at the left edge of the screen. If "Absolute Origin Mode" is
|
|
set (the same as unsetting any of the two modes in the previous
|
|
sentence) then home is at the upper left corner of the screen. On
|
|
some old terminals if "Cursor Origin Mode" is set it means that it's
|
|
relative.</P>
|
|
|
|
<H2><A NAME="pages_def"></A> <A NAME="ss22.6">22.6</A> <A HREF="Text-Terminal-HOWTO.html#toc22.6">Pages (definition) </A>
|
|
</H2>
|
|
|
|
<P> See
|
|
<A HREF="#pages_">Pages</A> for an explanation of pages.
|
|
There are a number of escape sequences to deal with pages. Text may
|
|
be copied from one page to another and one may move the cursor from
|
|
page to page. Switching pages may or may not be automatic: when the
|
|
screen becomes full (page 1) then more data from the host goes to page
|
|
2. The cursor may only be on one page at a time and characters which
|
|
are sent to the terminal go there. If that page is not being
|
|
displayed, new text will be received by the terminal and go into
|
|
display memory, but you will not see it (until the terminal is
|
|
switched to that page).</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s23">23.</A> <A HREF="Text-Terminal-HOWTO.html#toc23">Appendix C: Serial Communications on EIA-232 (RS-232)</A> </H2>
|
|
|
|
<H2><A NAME="ss23.1">23.1</A> <A HREF="Text-Terminal-HOWTO.html#toc23.1">Intro to Serial Communication</A>
|
|
</H2>
|
|
|
|
<P> (Much of this section is now found in Serial-HOWTO.) Text
|
|
terminals on Unix-like systems (and on PC's) are usually connected to
|
|
an asynchronous 232 serial port of a computer. It's usually a
|
|
RS-232-C, EIA-232-D, or EIA-232-E. These three are almost the same
|
|
thing. The original RS prefix became EIA (Electronics Industries
|
|
Association) and later EIA/TIA after EIA merged with TIA
|
|
(Telecommunications Industries Association). The EIA-232 spec
|
|
provides also for synchronous (sync) communication but the hardware to
|
|
support sync is almost always missing on PC's. The RS designation is
|
|
obsolete but is still in use. EIA will be used in this article.</P>
|
|
<P>The serial port is more than just a physical connector on the back of
|
|
a computer or terminal. It includes the associated electronics which
|
|
must produce signals conforming to the EIA-232 specification. The
|
|
standard connector has 25 pins, most of which are unused. An
|
|
alternative connector has only 9 pins. One pin is used to send out
|
|
data bytes and another to receive data bytes. Another pin is a common
|
|
signal ground. The other "useful" pins are used mainly for signalling
|
|
purposes with a steady negative voltage meaning "off" and a steady
|
|
positive voltage meaning "on".</P>
|
|
<P>The UART (Universal Asynchronous Receiver-Transmitter) chip does most
|
|
of the work. Today, the functionality of this chip is usually built
|
|
into another chip.</P>
|
|
|
|
<H2><A NAME="ss23.2">23.2</A> <A HREF="Text-Terminal-HOWTO.html#toc23.2">Voltages</A>
|
|
</H2>
|
|
|
|
<H3>Voltage for a bit</H3>
|
|
|
|
<P> At the EIA-232 serial port, voltages are bipolar (positive or
|
|
negative with respect to ground) and should be about 12 volts in
|
|
magnitude (newer ones are 5 volts but the 12 volt example is given
|
|
here). For the transmit and receive pins +12 volts is a 0-bit
|
|
(sometimes called "space") and -12 volts is a 1-bit (sometimes called
|
|
"mark"). This is known as inverted logic since normally a 0-bit is
|
|
both false and negative while a one is normally both true and
|
|
positive. Although the receive and transmit pins are inverted logic,
|
|
other pins (modem control lines) are normal logic with a positive
|
|
voltage being true (or "on" or "asserted") and a negative voltage
|
|
being false (or "off" or "negated"). Zero voltage has no meaning
|
|
(except it usually means that the PC is powered off).</P>
|
|
<P>A range of voltages is allowed. The specs say the magnitude of a
|
|
transmitted signal should be between 5 and 15 volts but must never
|
|
exceed 25 V. Any voltage received under 3 V is undefined (but some
|
|
terminals will accept a lower voltage as valid). One sometimes saw
|
|
erroneous claims that the voltage is commonly 5 volts (or even 3
|
|
volts) but it's usually 11-12 volts on older PCs. If you are using a
|
|
EIA-422 port on a Mac computer as an EIA-232 (requires a special
|
|
cable) or EIA-423 then the voltage will actually be only 5 V. The
|
|
discussion here assumes 12 V. There was much confusion about voltages
|
|
on the Internet.</P>
|
|
<P>Note that normal computer logic normally is just a few volts (5 volts
|
|
was once the standard) so that if you try to use test equipment
|
|
designed for testing 3-5 volt computer logic (TTL) on a 12 volt serial
|
|
port, it may damage the test equipment.</P>
|
|
|
|
<H3><A NAME="byte_seq"></A> Voltage sequence for a byte </H3>
|
|
|
|
<P> The transmit pin (TxD) is held at -12 V (mark) at idle when nothing
|
|
is being sent. To start a byte it jumps to +12 V (space) for the
|
|
start bit and remains at +12 V for the duration (period) of the start
|
|
bit. Next comes the low-order bit of the data byte. If it's a 0-bit
|
|
nothing changes and the line remains at +12 V for another bit-period.
|
|
Then comes the next bit, etc. Finally, a parity bit may be sent and
|
|
then a -12 V (mark) stop bit. The line remains at -12 V (idle) until
|
|
the next start bit. Note that there is no return to 0 volts and thus
|
|
there is no simple way (except by a synchronizing signal) to tell
|
|
where one bit ends and the next one begins for the case where 2
|
|
consecutive bits are the same polarity (both zero or both one).</P>
|
|
<P>A 2nd stop bit would also be -12 V, just the same as the first stop
|
|
bit. Since there is no signal to mark the boundaries between these
|
|
bits, the only effect of the 2nd stop bit is that the line must remain
|
|
at -12 V idle twice as long. The receiver has no way of detecting the
|
|
difference between a 2nd stop bit and a longer idle time between
|
|
bytes. Thus communications works OK if one end uses one stop bit and
|
|
the other end uses 2 stop bits, but using only one stop bit is
|
|
obviously faster. In rare cases 1 1/2 stop bits are used. This means
|
|
that the line is kept at -12 V for 1 1/2 time periods (like a stop bit
|
|
50% wider than normal).</P>
|
|
|
|
<H2><A NAME="parity_def"></A> <A NAME="ss23.3">23.3</A> <A HREF="Text-Terminal-HOWTO.html#toc23.3">Parity Explained </A>
|
|
</H2>
|
|
|
|
<P> Characters are normally transmitted with either 7 or 8 bits (of
|
|
data). An additional parity bit may (or may not) be appended to this
|
|
resulting in a byte length of 7, 8 or 9 bits. Some terminal emulators
|
|
and older terminals do not allow 9 bits. Some prohibit 9 bits if 2
|
|
stop bits are used (since this would make the total number of bits too
|
|
large: 12 bits total).</P>
|
|
<P>The parity may be set to odd, even or none (mark and space parity may
|
|
be options on some terminals). With odd parity, the parity bit is
|
|
selected so that the number of 1-bits in a byte, including the parity
|
|
bit, is odd. If a such a byte gets corrupted by a bit being flipped,
|
|
the result is an illegal byte of even parity. This error will be
|
|
detected and if it's an incoming byte to the terminal an
|
|
error-character symbol will appear on the screen. Even parity works
|
|
in a similar manner with all legal bytes (including the parity bit)
|
|
having an even number of 1-bits. During set-up, the number of bits
|
|
per character usually means only the number of data bits per byte (7
|
|
for true ASCII and 8 for various ISO character sets).</P>
|
|
<P>A "mark" is a 1-bit (or logic 1) and a "space" is a 0-bit (or logic
|
|
0). For mark parity, the parity bit is always a one-bit. For space
|
|
parity it's always a zero-bit. Mark or space parity only wastes
|
|
bandwidth and should be avoided when feasible. "No parity" means that no
|
|
parity bit is added. For terminals that don't permit 9 bit bytes,
|
|
"no parity" must be selected when using 8 bit character sets since
|
|
there is no room for a parity bit.</P>
|
|
|
|
<H2><A NAME="ss23.4">23.4</A> <A HREF="Text-Terminal-HOWTO.html#toc23.4">Forming a Byte (Framing)</A>
|
|
</H2>
|
|
|
|
<P> In serial transmission of bytes via EIA-232 ports, the low-order
|
|
bit is always sent first. Serial ports on PC's use asynchronous
|
|
communication where there is a start bit and a stop bit to mark the
|
|
beginning and end of a byte. This is called framing and the framed
|
|
byte is sometimes called a frame. As a result a total of 9, 10, or 11
|
|
bits are sent per byte with 10 being the most common. 8-N-1 means 8
|
|
data bits, No parity, 1 stop bit. This adds up to 10 bits total when
|
|
one counts the start bit. One stop bit is almost universally used.
|
|
At 110 bits/sec (and sometimes at 300 bits/sec) 2 stop bits were once
|
|
used but today the 2nd stop bit is used only in very unusual
|
|
situations (or by mistake since it seemingly still works OK that way).</P>
|
|
|
|
<H2><A NAME="ss23.5">23.5</A> <A HREF="Text-Terminal-HOWTO.html#toc23.5">Limitations of EIA-232</A>
|
|
</H2>
|
|
|
|
<H3>Low Speed & Short Distance</H3>
|
|
|
|
<P> The conventional EIA-232 serial port is inherently low speed and
|
|
is severely limited in distance. Ads often read "high speed" but it
|
|
can only work at high speed over very short distances such as to a
|
|
modem located right next to the computer. All of the wires use a
|
|
common ground return so that twisted-pair technology (needed for high
|
|
speeds) can't be used without additional hardware. However some
|
|
computers have more modern interfaces. See
|
|
<A HREF="#non_232">Successors to EIA-232</A>.</P>
|
|
<P>It is somewhat tragic that the RS-232 standard from 1969 did not use
|
|
twisted pair technology which could operate about a hundred times
|
|
faster. Twisted pairs have been used in telephone cables since the
|
|
late 1800's. In 1888 (over 110 years ago) the "Cable Conference"
|
|
reported its support of twisted-pair (for telephone systems) and
|
|
pointed out its advantages. But over 80 years after this approval by
|
|
the "Cable Conference", RS-232 failed to utilize it. Since RS-232
|
|
was originally designed for connecting a terminal to a low speed modem
|
|
located nearby, the need for high speed and longer distance
|
|
transmission was apparently not recognized.</P>
|
|
|
|
<H3><A NAME="non_232"></A> Successors to EIA-232 </H3>
|
|
|
|
<P> See the Serial-HOWTO section "Other Serial Devices" for a longer
|
|
discussion about non-EIA-232 ports. A number of EIA standards have
|
|
been established for higher speeds and longer distances using
|
|
twisted-pair (balanced) technology. Balanced transmission can
|
|
sometimes be a hundred times faster than unbalanced EIA-232. For a
|
|
given speed, the distance (maximum cable length) may be many times
|
|
longer with twisted pair. Few terminals seem to support them. While
|
|
many terminals also support EIA-423 is is almost like EIA-232 but is
|
|
only 5 volts and somewhat higher speeds (without using twisted pair).
|
|
Twisted pair includes EIA-422, EIA-530-A, HSSI (High Speed Serial
|
|
Interface), USB (Universal Serial Bus), and of course ethernet.</P>
|
|
|
|
<H3>Line Drivers</H3>
|
|
|
|
<P> For a text terminal, the EIA-232 speeds are fast enough but the
|
|
usable cable length is often too short. Balanced technology could
|
|
fix this. The common method of obtaining balanced communication with
|
|
a text terminal is to install 2@ line drivers in the serial line to
|
|
convert unbalanced to balanced (and conversely). They are a
|
|
specialty item and are expensive if purchased new.</P>
|
|
|
|
<H2><A NAME="sync"></A> <A NAME="ss23.6">23.6</A> <A HREF="Text-Terminal-HOWTO.html#toc23.6">Synchronization & Synchronous </A>
|
|
</H2>
|
|
|
|
<H3>How "Asynchronous" is Synchronized</H3>
|
|
|
|
<P> Per EIA-232 there are only two states of the transmit (or receive)
|
|
wire: mark (-12 V) or space (+12 V). There is no state of 0 V. Thus
|
|
a sequence of 1-bits is transmitted by just a steady -12 V with no
|
|
markers of any kind between bits. For the receiver to detect
|
|
individual bits it must always have a clock signal which is in
|
|
synchronization with the transmitter clock. Such clocks generate a
|
|
"tick" in synchronization with each transmitted (or received) bit.</P>
|
|
<P>For asynchronous transmission, synchronization is achieved by framing
|
|
each byte with a start bit and a stop bit (done by hardware). The
|
|
receiver listens on the line for a start bit and when it detects one
|
|
it starts its clock ticking. It uses this clock tick to time the
|
|
reading of the next 7, 8 or 9 bits. (It actually is a little more
|
|
complex than this since several samples of a bit are often taken and
|
|
this requires additional timing ticks.) Then the stop bit is read, the
|
|
clock stops and the receiver waits for the next start bit. Thus async
|
|
is actually synchronized during the reception of a single byte but
|
|
there is no synchronization between one byte and the next byte.</P>
|
|
|
|
<H3>Defining Asynchronous vs Synchronous</H3>
|
|
|
|
<P> Asynchronous (async) means "not synchronous". In practice, an
|
|
async signal is what the async serial port sends and receives which is
|
|
a stream of bytes each delimited by a start and stop bit. Synchronous
|
|
(sync) is most everything else. But this doesn't explain the basic
|
|
concepts.</P>
|
|
<P>In theory, synchronous means that bytes are sent out at a constant
|
|
rate one after another in step with a clock signal tick. There is
|
|
often a separate wire or channel for sending the clock signal.
|
|
Asynchronous bytes may be sent out erratically with various time
|
|
intervals between bytes (like someone typing characters at a
|
|
keyboard).</P>
|
|
<P>There are borderline situations that need to be classified as either
|
|
sync or async. The async serial port often sends out bytes in a
|
|
steady stream which would make this a synchronous case but since they
|
|
still have the start/stop bits (which makes it possible to send them
|
|
out erratically) its called async. Another case is where data
|
|
bytes (without any start-stop bits) are put into packets with possible
|
|
erratic spacing between one packet and the next. This is called sync
|
|
since the bytes within each packet must be transmitted synchronously.</P>
|
|
|
|
<H3>Synchronous Communication</H3>
|
|
|
|
<P> Did you ever wonder what all the unused pins are for on a 25-pin
|
|
connector for the serial port? Most of them are for use in
|
|
synchronous communication which is seldom implemented on PC's. There
|
|
are pins for sync timing signals as well as for a sync reverse
|
|
channel. The EIA-232 spec provides for both sync and async but PC's
|
|
use a UART (Universal Asynchronous Receiver/Transmitter) chip such as
|
|
a 16450, 16550A, or 16650 and can't deal with sync. For sync one
|
|
needs a USART chip or the equivalent where the "S" stands for
|
|
Synchronous. Since sync is a niche market, a sync serial port is
|
|
likely to be quite expensive.</P>
|
|
<P>Besides the sync part of the EIA-232, there are various other EIA
|
|
synchronous standards. For EIA-232, 3 pins of the connector are
|
|
reserved for clock (or timing) signals. Sometimes it's a modem's task
|
|
to generate some timing signals making it impossible to use
|
|
synchronous communications without a synchronous modem (or without a
|
|
device called a "synchronous modem eliminator" which provides the
|
|
timing signals).</P>
|
|
<P>Although few serial ports are sync, synchronous communication
|
|
does often take place over telephone lines using modems which use
|
|
V.42 error correction. This strips off the start/stop bits and puts
|
|
the date bytes in packets resulting in synchronous operation over the
|
|
phone line.</P>
|
|
|
|
<H2><A NAME="block"></A> <A NAME="ss23.7">23.7</A> <A HREF="Text-Terminal-HOWTO.html#toc23.7">Block Mode </A>
|
|
</H2>
|
|
|
|
<H3>Introduction to Block Mode</H3>
|
|
|
|
<P> Block mode is seldom used with Linux and is mainly of historical
|
|
interest. In block mode, when one types at a terminal the results are
|
|
saved in the terminal memory and are not sent just yet to the host
|
|
computer. Such terminals often have built-in editing capabilities.
|
|
When the user presses certain keys (such as the send key) what has
|
|
been saved in the terminal memory is sent to the host computer. Now
|
|
the Linux editors vi and emacs, must react instantly to typing certain
|
|
keys so block mode isn't feasible. Such editors and other interactive
|
|
programs can't permit the long delay in sending a keystroke to the
|
|
computer which is inherent in block mode. So they can't use block
|
|
mode.</P>
|
|
<P>The old IBM mainframe interface uses block mode (see
|
|
<A HREF="#ibm_">IBM Terminals </A> so many IBM terminals are block-mode only and
|
|
also synchronous (see Section
|
|
<A HREF="#sync">Synchronization & Synchronous</A>).</P>
|
|
|
|
<H3>Types of Block Modes, Forms</H3>
|
|
|
|
<P> Block mode may itself have various sub-modes such as "page" (a
|
|
page at a time) and "line" (a line at a time). Some terminals have
|
|
both block transmission modes and conventional character modes and may
|
|
be switched from one mode to another. Async terminals which have
|
|
block modes include HP2622A, Wyse60, VT130, VT131, VT330, VT340, and
|
|
Visual500. Many later model terminals can emulate block mode. But
|
|
the Linux console can't. Block modes may include a forms capability
|
|
where the host computer sends a form to the terminal. Then the user
|
|
fills it out and hits the send key which sends only the data in the
|
|
form back to the host computer. The form itself (not the data) is
|
|
displayed on the screen in protected fields which don't get
|
|
transmitted to the host.</P>
|
|
|
|
<H3>Efficiency</H3>
|
|
|
|
<P> Block mode takes load off the host computer, especially if the
|
|
host computer's hardware is designed for block modes (as IBM
|
|
mainframes were). In character mode every character typed is sent
|
|
immediately to the serial port and usually causes an interrupt at the
|
|
host computer. The host that receives the byte must stop whatever it
|
|
is doing and fetch that character from the port hardware. Even with
|
|
UART's that have FIFO hardware buffers, the hardware timeout is
|
|
normally only the transmission time of 3 bytes so that an interrupt is
|
|
usually issued for every character typed.</P>
|
|
<P>In true block mode a long block of characters is received using only
|
|
one interrupt. If block mode is used with conventional async FIFO
|
|
serial ports, an interrupt is needed only every 14 bytes since they
|
|
have 16-byte hardware buffers. Thus much of the load and overhead of
|
|
interrupt handling is eliminated and the computer has more time to do
|
|
other tasks when block mode is used.</P>
|
|
<P>A significant savings for block mode occurs if the terminal is
|
|
connected to its host via a network. Without block mode, every
|
|
character (byte) typed is sent in its own packet including all the
|
|
overhead bytes (40 in a TCP/IP packet as used on the Internet). With
|
|
block mode, a large number of characters are sent in a single packet.</P>
|
|
|
|
<H3>Problems with block mode</H3>
|
|
|
|
<P>While block mode is more efficient, it is nearly extinct, and for
|
|
good reason. Faster and cheaper computers made the higher efficiency
|
|
less important. For example, a 56k modem results in hundreds of
|
|
interrupts per second (every 14 characters) while typing at a terminal
|
|
only causes a few interrupts per second (one for each character
|
|
typed). So the number of interrupts caused by typing at a terminal
|
|
is not very significant (unless you have hundred of terminals
|
|
connected to the same computer).</P>
|
|
<P>Another point is that the efficiency is not of much significance where
|
|
the user doesn't type in very much. Editors are a primary example of
|
|
where the user types in a lot. But if you use block mode for
|
|
editing, you must then use the crude editor built into terminal. Modern
|
|
editors like vim and emacs are much better but can't use block mode.
|
|
Even in the days of mainframes with terminals, block mode wasn't used
|
|
much except by IBM. A major reason was that software to utilize it
|
|
was not widely available (except for IBM). The terminfo data base
|
|
doesn't seem to include it and this would complicate writing software
|
|
for it.</P>
|
|
|
|
<H2><A NAME="RS232_books"></A> <A NAME="ss23.8">23.8</A> <A HREF="Text-Terminal-HOWTO.html#toc23.8">EIA-232 (RS-232) Books </A>
|
|
</H2>
|
|
|
|
<P> (Note: The first book covers much more than just EIA-232.)
|
|
<UL>
|
|
<LI> Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE
|
|
Computer Society Press, Los Alamitos, CA, 1996.</LI>
|
|
<LI> Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982.</LI>
|
|
<LI> Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987.</LI>
|
|
<LI> Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall,
|
|
1991.</LI>
|
|
</UL>
|
|
</P>
|
|
|
|
<H2><A NAME="ss23.9">23.9</A> <A HREF="Text-Terminal-HOWTO.html#toc23.9">Serial Software</A>
|
|
</H2>
|
|
|
|
<P> See
|
|
<A HREF="ftp://ibiblio.org/pub/Linux/system/serial/">Serial Software</A> for Linux software for the serial ports
|
|
including getty and port monitors.</P>
|
|
|
|
<HR>
|
|
<H2><A NAME="s24">24.</A> <A HREF="Text-Terminal-HOWTO.html#toc24">Appendix D: Notes by Brand/Model</A></H2>
|
|
|
|
<P> Here are notes by brand name that were too specific to a certain
|
|
terminal to be put elsewhere in this HOWTO. If you have some info to
|
|
contribute on a certain terminal that is not covered elsewhere, it
|
|
could go here. Various models often have much in common so such
|
|
common information need only be written about once. It would be
|
|
nice if for each terminal model, there were a set of links linking to
|
|
most of the documentation relevant to that model (including escape
|
|
codes). But it hasn't been done. Note that some VT (DEC) manuals are
|
|
now available on the Internet. See and
|
|
<A HREF="#dec_">VT (DEC)</A>. Wyse put the information from its manuals on the
|
|
Internet but it can't be readily found now (2013). </P>
|
|
|
|
<H2><A NAME="ss24.1">24.1</A> <A HREF="Text-Terminal-HOWTO.html#toc24.1">Adds</A>
|
|
</H2>
|
|
|
|
<P>The Adds terminal menu incorrectly used "Xon/Xoff" to mean any kind
|
|
of flow control. True for which models ??</P>
|
|
<P>Adds, which made the Adds Viewpoint terminal, was taken over by
|
|
Boundless Technologies in 1994 but they continued to use the "Adds"
|
|
name.</P>
|
|
|
|
<H2><A NAME="ss24.2">24.2</A> <A HREF="Text-Terminal-HOWTO.html#toc24.2">CIT</A>
|
|
</H2>
|
|
|
|
<P> CIT terminals were made in Japan in the 1980's for CIE Terminals.
|
|
They ceased to be imported in the late 1980's. The company, CIE,
|
|
still made CItoh printers (in 1997) but has no parts for its
|
|
abandoned terminals. Ernie at (714) 453-9555 in Irvine CA sold (in
|
|
1997) some parts for models 224, 326, etc. but has nothing for the 80
|
|
and 101.</P>
|
|
<P>To save the Set-Up parameters press ^S when in Set-Up mode.
|
|
cit80: Contrast: knob on rear of terminal,
|
|
cit101e: Brightness: use up/down arrow keys in Set-Up mode.</P>
|
|
|
|
<H2><A NAME="ibm_"></A> <A NAME="ss24.3">24.3</A> <A HREF="Text-Terminal-HOWTO.html#toc24.3">IBM Terminals </A>
|
|
</H2>
|
|
|
|
<P> Don't confuse IBM terminals with IBM PC monitors. Many IBM
|
|
terminals don't use ASCII but instead use an 8-bit EBCDIC code. It's
|
|
claimed that in EBCDIC the bit order of transmission is reversed from
|
|
normal with the high-order bit going first. The IBM mainframe
|
|
communication standards are a type of synchronous communication in
|
|
block mode (sends large packets of characters). Two standards are
|
|
"BISYNC" and "SNA" (which includes networking standards). Many of
|
|
their terminals connect with coax cable (RG62A/U) and naive persons
|
|
may think the "BNC" connecter on the terminal is for ethernet (but
|
|
it's not).</P>
|
|
<P>While this IBM system is actually more efficient than what is
|
|
normally used in Linux, terminals meeting this IBM standard will not
|
|
currently work with Linux. However, some IBM terminals are
|
|
asynchronous ASCII terminals and should work with Linux on PC's. The
|
|
numbers 31xx may work with the exception that 317x and 319x are not
|
|
ASCII terminals. Before getting an IBM terminal, make sure there is a
|
|
termcap (terminfo) for it. If their isn't, it likely will not work
|
|
with Linux. Even if there is a terminfo, it may not work. For
|
|
example, there is a termcap for 327x but the 3270 is an EBCDIC
|
|
synchronous terminal.</P>
|
|
<P>The 3270 series includes the 3278 (late 1970's), 3279 with color and
|
|
graphics, and the 3274 terminal controller (something like the 3174).
|
|
They may be used for both BISYNC and SNA. The 3290 has a split screen
|
|
(splits into quarters).</P>
|
|
<P>The synchronous IBM terminals don't connect directly to the IBM
|
|
mainframe, but connect to a "terminal controller" (sometimes called
|
|
"cluster controller" or "communication controller"). Some of these
|
|
controllers can convert a synchronous signal to asynchronous so that in
|
|
this case a synchronous terminal could indirectly connect to a
|
|
Unix-like host computer via its serial port. But there is still a
|
|
major problem and that is block transmission. See section
|
|
<A HREF="#block">Block Mode</A>.</P>
|
|
|
|
<H3>IBM 3153</H3>
|
|
|
|
<P> It's claimed that the Aux port is DCE and uses a straight-thru
|
|
cable.</P>
|
|
|
|
<H2><A NAME="teletype"></A> <A NAME="ss24.4">24.4</A> <A HREF="Text-Terminal-HOWTO.html#toc24.4">Teletypes </A>
|
|
</H2>
|
|
|
|
<P> These are antiques and represent the oldest terminals. They are
|
|
like remotely controlled typewriters but are large and noisy. Made by
|
|
the Teletype Corp., the first models were made in the 1920's and
|
|
predate the computer by over 30 years. Early models used
|
|
electro-mechanical relays and rotating distributors instead of
|
|
electronics. Their Baudot code was only 5-bits per character as
|
|
compared to 7-bit ASCII. See the book "Small Computer Systems
|
|
Handbook" by Sol Libes, Hayden Books, 1978: pp. 138-141 ("Teletypes").</P>
|
|
|
|
<H2><A NAME="dec_"></A> <A NAME="ss24.5">24.5</A> <A HREF="Text-Terminal-HOWTO.html#toc24.5">VT (originally DEC, now Boundless) </A>
|
|
</H2>
|
|
|
|
<P> Digital Equipment Corporation (DEC) made the famous VT series of
|
|
terminals including the commonly emulated VT100. </P>
|
|
<P>In 1995 DEC sold their terminal business to Boundless Technologies.
|
|
Boundless went bankrupt in 2003 but emerged from bankruptcy in 2006 as
|
|
a division of "Visual Technologies". Then in 2008 they were acquired
|
|
by Video Display Corporation and given to their Z-AXIS subsidiary
|
|
located near Rochester, New York. The
|
|
<A HREF="http://www.boundless.com/terminals.html">Boundless</A> name
|
|
and url have been retained.</P>
|
|
<P>Detailed VT terminal information, some manuals, and
|
|
history is at
|
|
<A HREF="http://www.vt100.net/">http://www.vt100.net/</A>.</P>
|
|
<P>VT220: Some have a BNC connector for video output (not for input).
|
|
Sometimes people erroneously think this is for an ethernet connection.</P>
|
|
<P>VT510, 520, 525: Supports full DTR/DSR flow control. Some are "low
|
|
emissions" models. The 520 is multi-session and the 525 has colors for
|
|
highlighting.</P>
|
|
<P>Dorio is a lower quality model which can emulate many other terminals.
|
|
The "sco unix console" is claimed to be a powerful emulation using the
|
|
"scoansi" terminfo.</P>
|
|
|
|
<H2><A NAME="ss24.6">24.6</A> <A HREF="Text-Terminal-HOWTO.html#toc24.6">Links</A>
|
|
</H2>
|
|
|
|
<P> The terminal maker Links was taken over by Wyse.</P>
|
|
|
|
<H2><A NAME="ss24.7">24.7</A> <A HREF="Text-Terminal-HOWTO.html#toc24.7">Qume</A>
|
|
</H2>
|
|
|
|
<P> Qume was taken over by Wyse in the early 1990s.</P>
|
|
|
|
<H2><A NAME="wyse_"></A> <A NAME="ss24.8">24.8</A> <A HREF="Text-Terminal-HOWTO.html#toc24.8">Wyse Terminals </A>
|
|
</H2>
|
|
|
|
<P> detailed manual-like information on old terminals see
|
|
<A HREF="http://www.wyse.com/service/support/kbase/wyseterm.asp">http://www.wyse.com/service/support/kbase/wyseterm.asp</A>. This
|
|
information includes specs, lists of escape sequences, part lists,
|
|
FAQs, setup info, etc. Thanks to Wyse for providing this even though
|
|
as of 2006 they are no longer making text terminals.</P>
|
|
<P>Wyse terminals were lower in cost than other brands and they captured
|
|
a major share of the market. There were concerns about the quality of
|
|
these terminals, especially the Wyse 50. But the large number of
|
|
failure reports (other than Wyse 50) may be due in part to the large
|
|
number of Wyse terminals in use.</P>
|
|
<P>See
|
|
<A HREF="en.wikipedia.org/wiki/Dell_Wyse">en.wikipedia.org/wiki/Dell_Wyse</A> for a history of Wyse.</P>
|
|
|
|
<H3>Wyse 50</H3>
|
|
|
|
<P>Reported not to last very long.</P>
|
|
|
|
<H3>Wyse 60</H3>
|
|
|
|
<P> Display adjustments (must remove cover): Brightness VR202, Height
|
|
VR302, Width VR101 (also affects height). If you want to use it in
|
|
Native Personality, then the arrow-key codes will conflict with the
|
|
codes used in vi (such as ^L). To fix this set "Application key mode"
|
|
with ESC ~ 3. This results in the arrow keys sending 0xd0 - 0xd3.
|
|
Due to a bug in the readline interface of the Bash shell, you need to
|
|
edit /etc/inputrc so that the arrow keys will work in Bash. See
|
|
<A HREF="#bash_bug">Bugs in Bash</A></P>
|
|
|
|
<H3>Wyse 85</H3>
|
|
|
|
<P> Can emulate VT52/VT100/VT200. Press F3 for setup. After moving
|
|
left/right to go a menu "icon", press space to select it. Scroll
|
|
thru setup menus with up/down keys. Press F3 at any time to reenter
|
|
setup (without loosing any settings).</P>
|
|
|
|
<H3>Wyse 99-GT</H3>
|
|
|
|
<P> Here is the setup Menus of the Wyse99GT (late 1980's). Note that
|
|
TERM means "termination" (character) and not "terminal".</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
WYSE 99-GT Terminal Set-Up as used at the University of CA, Irvine
|
|
|
|
by David Lawyer, April 1990
|
|
|
|
F1 DISP:
|
|
COLUMNS=80 LINES=24 CELL SIZE=10 X 13
|
|
STATUS LINE=STANDARD BACKGROUND=DARK SCROLL SPEED=JUMP
|
|
SCREEN SAVER=OFF CURSOR=BLINK BLOCK DISPLAY CURSOR=ON
|
|
ATTRIBUTE=CHAR END OF LINE WRAP=ON AUTO SCROLL=ON
|
|
----------------------------------------------------------------------------
|
|
F2 GENERAL:
|
|
PERSONALITY=VT 100 ENHANCE=ON FONT LOAD=OFF
|
|
COMM MODE=FULL DUPLEX RCVD CR=CR SEND ACK=ON
|
|
RESTORE TABS=ON ANSWERBACK MODE=OFF ANSWERBACK CONCEAL=OFF
|
|
WIDTH CHANGE CLEAR=OFF MONITOR=OFF TEST=OFF
|
|
----------------------------------------------------------------------------
|
|
F3 KEYBRD:
|
|
KEYCLICK=OFF KEYLOCK=CAPS KEY REPEAT=ON
|
|
RETURN=CR ENTER=CR FUNCT KEY=HOLD
|
|
XMT LIMIT=NONE FKEY XMT LIMIT=NONE BREAK=170MS
|
|
LANGUAGE=US MARGIN BELL=OFF PRINTER RCV=OFF
|
|
----------------------------------------------------------------------------
|
|
F4 COMM:
|
|
DATA/PRINTER=AUX/MODEM MDM RCV BAUD RATE=9600 MDM XMT BAUD RATE=9600
|
|
MDM DATA/STOP BITS=8/1 MDM RCV HNDSHAKE=NONE MDM XMT HNDSHAKE=NONE
|
|
MDM PARITY=NONE AUX BAUD RATE=9600 AUX DATA/STOP BITS=8/1
|
|
AUX RCV HNDSHAKE=NONE AUX XMT HNDSHAKE=NONE AUX PARITY=NONE
|
|
(There is a main port (Modem=MDM) and an Auxiliary Port (AUX)
|
|
----------------------------------------------------------------------------
|
|
F5 MISC 1:
|
|
WARNING BELL=ON FKEY LOCK=OFF FEATURE LOCK=ON
|
|
KEYPAD=NUMERIC DEL=DEL/CAN XFER TERM=EOS
|
|
CURSOR KEYS=NORMAL MARGIN CTRL=0 DEL FOR LOW Y=ON
|
|
GIN TERM=CR CHAR MODE=MULTINATIONAL
|
|
----------------------------------------------------------------------------
|
|
F6 MISC 2:
|
|
LOCAL=OFF SEND=ALL PRINT=NATIONAL
|
|
PORT=EIA DATA SEND AREA=SCREEN PRINT AREA=SCREEN
|
|
DISCONNECT=60 MSEC SEND TERM=NONE PRINT TERM=NONE
|
|
PRINT MODE=NORMAL VT100 ID=VT100 POUND=US
|
|
----------------------------------------------------------------------------
|
|
F7 TABS: You should see several "T" characters spaced 8 dots apart.
|
|
If you don't, hit backspace.
|
|
F8 F/KEYS: Normally you will see no definitions for the Function Keys
|
|
here (unless someone has set them up and saved them). This means that
|
|
they will normally generate their default settings (not displayed here).
|
|
<ctrl><F5> shows the "user defined definition" of the F5 key, etc.
|
|
F9 A/BACK: Normally not defined: ANSWERBACK =
|
|
F10 EXIT: Selecting "DEFAULT ALL" will make the factory default settings
|
|
the default.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>HINTS on use of WY-99GT User's Guide:
|
|
Note that much that is missing from this Guide may be found in the
|
|
WY-99GT Programmer's Guide. The VT100 emulation (personality) is
|
|
known as ANSI and uses ANSI key codes per p. A-10+ even though the
|
|
keyboard may be ASCII. A sub-heading on p. A-13 "ASCII Keyboard" also
|
|
pertains to VT100 because it has an "ANSI KEY ..." super-heading a few
|
|
pages previously. But not all ASCII keyboard headings pertain to
|
|
VT100 since they may fall under a non-ANSI personality super-heading
|
|
which may found be a few pages previously. Appendix H is the "ANSI
|
|
Command Guide" except for the VT52 (ANSI) personality which is found
|
|
in Appendix G.</P>
|
|
|
|
<H3>Wyse 150</H3>
|
|
|
|
<P> When exiting set-up using F12, hitting space changes "no" to "yes"
|
|
to save the set-up. The sentence to the left of this no/yes is about
|
|
"vertical alignment" and has nothing to do with this no/yes for saving
|
|
the set-up (confusing menu design).</P>
|
|
|
|
<H3>Wyse 185</H3>
|
|
|
|
<P>Has 10x20 character cells. Can emulate DEC VT320. Uses 45 watts power.
|
|
Later models were 185e.</P>
|
|
|
|
<H3>Low Emissions: -ES</H3>
|
|
|
|
<P>ES after the model number means low emissions: low magnetic field,
|
|
etc.</P>
|
|
<P>END OF Text-Terminal-HOWTO</P>
|
|
<HR>
|
|
</BODY>
|
|
</HTML>
|