Linux文本终端使用指南

需积分: 9 42 浏览量更新于2024-07-15 收藏 761KB PDF 举报

"Text-Terminal-HOWTO.pdf" 是一份详细介绍Linux文本终端使用的文档，由David S. Lawyer编写。这份文档旨在帮助用户理解终端的历史、类型、工作原理以及如何在Linux环境中配置和使用终端。 1. 终端类型文档中提到终端有多种类型，包括早期的哑终端和现在的模拟终端。哑终端不具备处理能力，只能接收和显示数据，而模拟终端则可以在个人计算机上模拟传统终端的功能，支持各种平台和系统。 2. 安装与使用快速安装指南帮助用户快速设置终端。为何使用终端？因为它们提供了一种与操作系统交互的简单方式，特别是在没有图形界面或需要远程访问时。 3. 终端工作原理在Linux中，终端工作涉及到终端特殊文件（如/dev/tty），这些文件是操作系统与终端之间的接口。文档还深入探讨了终端的工作细节，包括如何处理输入输出、流控制（Handshaking）以及物理连接。 4. 终端配置配置终端涉及硬件设置（如串行通信和EIA-232标准，即RS-232）和软件设置（如terminfo和termcap数据库）。这些设置确保终端正确地显示字符和处理控制序列。 5. 使用与调试用户将学习如何有效地使用终端，包括命令行操作，以及遇到问题时的软件故障排除和诊断方法。每个终端可能有其特定的特性，文档会介绍如何利用这些特性。 6. 附录附录提供了通用信息、关于终端控制序列的术语解释，以及各品牌终端的特别注意事项。这有助于用户更全面地了解终端及其操作。这份“Text-Terminal-HOWTO”是Linux和Unix用户深入了解和操作文本终端的宝贵资源，涵盖了从基础知识到高级特性的广泛内容。无论是新手还是经验丰富的用户，都能从中受益。通过阅读这份文档，用户可以更好地掌握终端的使用，提高工作效率，并解决可能出现的问题。

1. Introduction

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

1.1 Copyright, Trademarks, Disclaimer, & Credits

Please freely copy and distribute (sell or give away) this document in any format. Forward any corrections

and comments to the document maintainer. You may create a derivative work and distribute it provided that

you:

1. Send your derivative work (in the most suitable format such as sgml) to the LDP (Linux

Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know

where it is available. Except for a translation, send a copy to the previous maintainer's url as shown in

the latest version.

2. License the derivative work in the spirit of this license or use GPL. Include a copyright notice and at

least a pointer to the license used.

3. Give due credit to previous authors and major contributors.

If you're considering making a derived work other than a translation, it's requested that you discuss your plans

with the current maintainer.

Disclaimer

While I haven't intentionally tried to mislead you, there are likely a number of errors in this document. Please

let me know about them. Since this is free documentation, it should be obvious that I cannot be held legally

responsible for any errors.

Trademarks

If certain words are trademarks, the context should make it clear to whom they belong. For example "MS

Windows NT" implies that "Windows NT" belongs to Microsoft (MS). Mac is by Apple Computer.

Trademarks belong to their respective owners.

The Linux Text−Terminal−HOWTO

1. Introduction 7

Credits

Much of the section "Physical Connection" is from Serial−HOWTO v. 1.11 by Greg Hankins (with his

permission). His "How Do I Set Up A Terminal Connected To My PC?" was incorporated into v1.00 at

various places. v1.09 has about 25 changes (and error corrections) suggested by Alessandro Rubini who

reviewed this HOWTO.

1.2 Future Plans: You Can Help

Please let me know of any errors in facts, opinions, logic, spelling, grammar, clarity, links, etc. But first, if

the date is over a few months old, check to see that you have the latest version. Please send me any info that

you think belongs in this document.

Starting with version 1.00, a first attempt was made to help people set up terminals without recourse to a

terminal manual. Much more is needed in this respect. One way to solve this problem would be if terminal

manufacturers put their manuals on the Internet. I suggest that you encourage them to do so. The task of

providing information on how to configure most terminals in this HOWTO is daunting. There are so many

different terminals, but there are far fewer models than there used to be in the 1980,s so the task is not totally

infeasible.

Please send me any surplus terminal manuals which you may have, especially on terminals made within the

past 10 years (but I'll accept older ones also). Also, you might want to write up something on a certain

terminal to put in the Appendix D: Notes by Brand Name.

1.3 New Versions of this HOWTO

New versions of the Text−Terminal−HOWTO will be available to browse and/or download at LDP mirror

sites. For a list of mirror sites see: http://metalab.unc.edu/LDP/mirrors.html. Various formats are available. If

you only want to quickly check the date of the latest version look at

http://metalab.unc.edu/LDP/HOWTO/Text−Terminal−HOWTO.html. The version your are currently reading

is v1.09, 28 November 1999.

1.4 Related HOWTO's

Go to the websites shown above to get these.

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

• Modem−HOWTO

• Serial−Programming−HOWTO

• Xterminal−HOWTO (unmaintained). It's at

http://sunsite.unc.edu/pub/Linux/docs/HOWTO/unmaintained/mini/Xterminal

The Linux Text−Terminal−HOWTO

Credits 8

1.5 Terminology Used in this Document

Configuration means the same as set−up. While Linux commands take options (using − symbols), options in

a broader sense include various other types of choices. Install in the broad sense includes setting up

(configuring) software and hardware. A statement that I suspect is true (but may not be) ends with 2 question

marks: ?? If you know for sure, let me know.

1.6 What is a Terminal ?

A terminal consists of a screen and keyboard that one uses to communicate remotely with a (host) computer.

One uses it just like it was a personal computer but the terminal is remote from its host computer (on the

other side of the room or even on the other side of the world). Programs execute on the host computer but the

results display on the terminal screen. Its computational ability is relatively low (otherwise it would be a

computer and not a terminal). This computational ability is generally limited to the ability to display what is

sent to it (possibly including full−screen graphics) and the ability to send to the host what is typed at the

keyboard.

In the days of mainframes from the mid 1970's to the mid 1980's, most people used terminals to communicate

with computers. They typed in programs, ran programs, wrote documents, issued printing commands, etc. A

cable connected the terminal to the computer (often indirectly). It was called a terminal since it was located at

the terminal end of this cable.

If you've been using Linux (except for X−Window use) with a computer monitor and keyboard you already

know what a terminal is because you have been using one (or more precisely a "virtual terminal"). The

monitor (along with the keyboard) is emulating a terminal. In X−Windows the programs xterm, rxvt, and

zterm emulate terminals.

A real terminal is different from a monitor because it's a different electronic setup. A text terminal is often

connected to a serial port of the computer via a long cable. Thus, in contrast to a monitor which is usually

located right next to the computer, a terminal may be quite a distance away from its host computer. The video

card inside a computer stores the video image seen on the monitor screen. For a terminal, the equivalent of

this video card is built right into the terminal but since text terminals are often monochrome without much

graphics, the capabilities of its "video card" are rather weak. Also, most text terminals do not have mice.

In network client−server terminology, one might think that the terminal is the client and that the host

computer is the server. The terminal has been called a "thin client" by some. But it is not actually a "client"

nor is the host a "server". The only "service" the host provides is to receive every letter typed at the keyboard

and react to this just like a computer would. The terminal is like a window into the computer just like a

monitor (and keyboard) are. You may have already used virtual terminals in Linux (by pressing Left Alt−F2,

etc.). A real terminal is just like running such a virtual terminal but you run it on its own terminal screen

instead of having to share the monitor screen. In contrast to using a virtual terminal at the console (monitor),

this allows another person to sit at the real terminal and use the computer simultaneously with others.

Next Previous ContentsNextPreviousContents

The Linux Text−Terminal−HOWTO

1.5 Terminology Used in this Document 9

10. Flow Control (Handshaking)

Flow control (= handshaking = pacing) is to prevent too fast of a flow of bytes from overrunning a terminal,

computer, modem or other device. Overrunning is when a device can't process what it is receiving quickly

enough and thus loses bytes and/or makes other serious errors. What flow control does is to halt the flow of

bytes until the terminal (for example) is ready for some more bytes. Flow control sends its signal to halt the

flow in a direction opposite to the flow of bytes it wants to stop. Flow control must both be set at the terminal

and at the computer.

There are 2 types of flow control: hardware and software (Xon/Xoff or DC1/DC3). Hardware flow control

uses dedicated signal wires such as RTS/CTS or DTR/DSR while software flow control signals by sending

DC1 or DC3 control bytes in the normal data wires. For hardware flow control, the cable must be correctly

wired.

The flow of data bytes in the cable between 2 serial ports is bi−directional so there are 2 different flows (and

wires) to consider:

1. Byte flow from the computer to the terminal

2. Byte flow from the terminal keyboard to the computer.

10.1 Why Is Flow Control Needed ?

You might ask: "Why not send at a speed slow enough so that the device will not be overrun and then flow

control is not needed?" This is possible but it's usually significantly slower than sending faster and using flow

control. One reason for this is that one can't just set the serial port baud rate at any desired speed such as

14,500, since only a discrete number of choices are available. The best choice is to select a rate that is a little

higher than the device can keep up with but then use flow control to make things work right.

If one decides to not use flow control, then the speed must be set low enough to cope with the worst case

situation. For a terminal, this is when one sends escape sequences to it to do complex tasks that take more

time than normal. In the case of a modem (with data compression but no flow control) the speed from the

computer to the modem must be slow enough so that this same speed is usable on the phone line, since in the

worst case the data is random and can't be compressed. If one failed to use flow control, the speed (with data

compression turned on) would be no faster than without using any compression at all.

Buffers are of some help in handling worst case situations of short duration. The buffer stores bytes that come

in too fast to be processed at once, and saves them for processing later.

10.2 Padding

Another way to handle a "worst case" situation (without using flow control or buffers) is to add a bunch of

nulls (bytes of value zero) to escape sequences. Sometimes DEL's are used instead provided they have no

other function. See Recognize Del.

The escape sequence starts the terminal doing something, and while the terminal is busy doing it, it receives a

bunch of nulls which it ignores. When it gets the last null, it has completed its task and is ready for the next

The Linux Text−Terminal−HOWTO

10. Flow Control (Handshaking) 10

command. This is called null padding. These nulls formerly were called "fill characters". These nulls are

added just to "waste" time, but it's not all wasted since the terminal is usually kept busy doing something else

while the nulls are being received. It was much used in the past before flow control became popular. To be

efficient, just the right amount of nulls should be added and figuring out this is tedious. It was often done by

trial and error since terminal manuals are of little or no help. If flow control doesn't work right or is not

implemented, padding is one solution. Some of the options to the stty command involve padding.

10.3 Overrunning a Serial Port

One might wonder how overrunning is possible at a serial port since both the sending and receiving serial

ports involved in a transmission of data bytes are set for the same speed (in bits/sec) such as 19,200. The

reason is that although the receiving serial port electronics can handle the incoming flow rate, the

hardware/software that fetches and processes the bytes from the serial port sometimes can't cope with the

high flow rate.

One cause of this is that the serial port's hardware buffer is quite small. Older serial ports had a hardware

buffer size of only one byte (inside the UART chip). If that one received byte of data in the buffer is not

removed (fetched) by CPU instructions before the next byte arrives, that byte is lost (the buffer is overrun).

Newer UART's, namely most 16550's, have 16−byte buffers (but may be set to emulate a one−byte buffer)

and are less likely to overrun. It may be set to issue an interrupt when the number of bytes in its buffer

reaches 1, 4, 8, or 14 bytes. It's the job of another computer chip (usually the main CPU chip for a computer)

to take these incoming bytes out of this small hardware buffer and process them (as well as perform other

tasks).

When contents of this small hardware receive buffer reaches the specified limit (one byte for old UART'S) an

interrupt is issued. Then the computer interrupts what it was doing and software checks to find out what

happened. It finally determines that it needs to fetch a byte (or more) from the serial port's buffer. It takes

these byte(s) and puts them into a larger buffer (also a serial port buffer) that the kernel maintains in main

memory. For the transmit buffer, the serial hardware issues an interrupt when the buffer is empty (or nearly

so) to tell the CPU to put some more bytes into it to send out.

Terminals also have serial ports and buffers similar to the computer. Since the flow rate of bytes to the

terminal is usually much greater than the flow in the reverse direction from the keyboard to the host

computer, it's the terminal that is most likely to suffer overrunning. Of course, if you're using a computer as a

terminal (by emulation), then it is likewise subject to overrunning.

Risky situations where overrunning is more likely are: 1. When another process has disabled interrupts (for a

computer). 2. When the serial port buffer in main (or terminal) memory is about to overflow.

10.4 Stop Sending

When its appears that the receiver is about to be overwhelmed by incoming bytes, it sends a signal to the

sender to stop sending. That is flow control and the flow control signals are always sent in a direction

opposite to the flow of data which they control (although not in the same channel or wire). This signal may

either be a control character (^S = DC3 = Xoff) sent as an ordinary data byte on the data wire (in−band

signalling), or a voltage transition from positive to negative in the dtr−to−cts (or other) signal wire

(out−of−band signalling). Using Xoff is called "software flow control" and using the voltage transition in a

The Linux Text−Terminal−HOWTO

10.3 Overrunning a Serial Port 11

剩余115页未读，继续阅读

linuxdog2

粉丝: 23
资源: 31

Linux文本终端使用指南

PyPI官方发布：eremetic-synchronous-client-0.28.2.tar.gz

PyPI 官网发布 warden_terminal-*.*.*.* Python库

Python库exam-terminal下载指南

BSD Hacks.pdf

Linux Shell Scripting Essentials 无水印pdf 0分

bochs user manual 单html文件+pdf 英文原版

Introduction to 64Bit Windows Assembly

Python库 ton_client_py-*.*.*.* 下载及安装指南

SL-ST 差速器3D模型 SL-ST 差速器

C#大型药品进销存管理系统源码数据库 Access源码类型 WinForm

最新资源

PyPI 官网发布 warden_terminal-... Python库

Python库 ton_client_py-... 下载及安装指南