case "$ans" in [Yy]*) ;;
*) exec $HOME/bin/-sh ;;
esac
The last line uses some trickery to start a new login shell (Section 3.19). The shell closes your tty (Section 36.15) before reading your .sh_logout file; the
exec < $TTY
reconnects the shell's standard input to your terminal.Note that if your system is very slow, you may not get the reminder message for a couple of seconds — consequently, you might forget that it's coming and walk away. That hasn't been a problem where I've tested this. If it is for you, though, replace the
read ans
with a program like grabchars that times out and gives a default answer after a while. There may be some Bourne shells that need other tricks — and others that don't need these tricks — but this should give you an idea of what to do.—JP and SJC
[1] I haven't seen prompts described this way before. I invented the terms static prompt and dynamic prompt to make them easier to talk about.
[2] Some terminals and windows have "scroll back" memory of previous screens. clear usually doesn't erase all of that.
To set scrollback in xterm, use the -sb and -sl options. Most other terminal emulators have similar mechanisms to set the number of lines to keep in the scrollback buffer.
CONTENTS
CONTENTS
Chapter 5. Getting the Most out of Terminals, xterm, and X Windows
5.1 There's a Lot to Know About Terminals 5.2 The Idea of a Terminal Database
5.3 Setting the Terminal Type When You Log In 5.4 Querying Your Terminal Type: qterm
5.5 Querying Your xterm Size: resize
5.6 Checklist: Terminal Hangs When I Log In 5.7 Find Out Terminal Settings with stty
5.8 Setting Your Erase, Kill, and Interrupt Characters 5.9 Working with xterm and Friends
5.10 Login xterms and rxvts 5.11 Working with Scrollbars 5.12 How Many Lines to Save?
5.13 Simple Copy and Paste in xterm
5.14 Defining What Makes Up a Word for Selection Purposes 5.15 Setting the Titlebar and Icon Text
5.16 The Simple Way to Pick a Font 5.17 The xterm Menus
5.18 Changing Fonts Dynamically 5.19 Working with xclipboard
5.20 Problems with Large Selections
5.21 Tips for Copy and Paste Between Windows 5.22 Running a Single Command with xterm -e 5.23 Don't Quote Arguments to xterm -e
5.1 There's a Lot to Know About Terminals
This chapter covers most of what you need to know to set up your terminal or terminal emulator from your shell setup files (Section 3.3).
In the latter half of the chapter, we cover the ins and outs of working with some of the most popular terminal-emulator software for the X Window System, including xterm, rxvt, and others, where applicable. The list of terminals and emulators you might come into contact with is long and getting longer, though, so the advice we give in the first section of the chapter regarding how to configure your terminal will be helpful. As you find yourself suddenly confronted with the prospect of configuring the terminal emulator on your cell phone or tablet computer, remember: you can usually make it work, with enough time and effort.
It is important to remember, however, that the tricks and tips we discuss in this chapter, if implemented
incorrectly, may cause your terminal to hang. One way around a hung terminal is always to keep at least one other terminal emulator window, with sane settings, open all the time you're modifying the setup of the other. That way, if you hang up the terminal you're actively modifying, you can always go back to the other and save yourself. On systems that support virtual consoles, such as Linux, you can also use
command keys (e.g., ALT and the first five function keys) to switch between various virtual consoles, just as you might with a terminal emulator. Don't just reach for the power switch!
—TOR and SJC
5.2 The Idea of a Terminal Database
In the past few years, terminals have been standardized to a few types. In fact, most terminals nowadays are terminal emulators (like xterm) that simulate a terminal on a graphical display. Years ago, though, terminals differed widely. Rather than simply being implemented in software, they were hardware — keyboards and monitors or even teletypes, with which the user interacted to communicate with an often faraway mainframe or other big iron. All were specialized, and differences between them often came down to how much you paid and to what manufacturer. This lets you take advantage of other features of the manufacturer's primary hardware — the big computers they considered their main product.
Manufacturers produced a variety of terminals, each one including a particular set of features for a certain price. There were smart terminals and dumb ones, terminals with big screens and terminals with small screens, printing terminals and video displays, and terminals with all sorts of special features.
Differences between terminals do not matter much to programs like cat (Section 12.2) or who (Section 2.8) that use the terminal screen as a sort of typewriter with an endless scroll of paper. These programs produce sequential output and do not make use of the terminal's special features; they do not need to know much to do their job. Only programs such as screen editors, which make use of screen-handling features, need to know a lot about differences between terminals.
However, even today, we find a wide variety of terminal emulators across a multitude of platforms. My new Kyocera Smartphone, for example, is a Palm device integrated with a PCS telephone; one of the main reasons I bought it was for remote, emergency ssh access to my servers, using a tiny terminal emulator that runs on the PalmOS. Many Unix programs assume a basic environment that this terminal emulator does not provide — an 80-column screen — so even simple commands such as w, which prints a list of who is logged in, where they logged in from, and what they're currently running, become impossible to run. But let's go back to the early days and revisit some of the old problems that plagued early Unix developers, so that we might better understand how to deal with today's problems.
In the late 1970s, Bill Joy created the vi (Section 17.2) text editor at UC Berkeley. Like all screen-oriented editors, vi uses the terminal screen nonsequentially (in stark contrast to earlier editors such as ed, which were designed for a teletype, and so use even more terse commands and feature even more terse output). A program performing nonsequential output does not just print character after character, but must manipulate the text that was sent before, scroll the page, move the cursor, delete lines, insert
characters, and more. While it would be possible to keep redrawing the screen in its entirety, many features are provided in hardware or firmware by the terminal itself, saving too much time and trouble to be ignored.
The first version of vi was written specifically for Lear Siegler ADM3a terminals. vi was such an improvement over line-oriented editors that there was great demand to port vi to other brands of
terminals. The problem was that each terminal had different features and used different control codes to manipulate the features that they did have in common.
Rather than write separate terminal drivers for each terminal type, Bill Joy did something very clever, which all Unix users now take for granted. He wrote a version of vi with generic commands to manipulate the screen instead of hardcoding the control codes and dimensions for a particular terminal.[1]
Joy came up with a generic terminal-handling mechanism that had two parts: a database describing the capabilities of each of the terminals to be supported and a subroutine library that allows programs to query that database and make use of the capability values it contains. Both the library and the database were given the name termcap, which is short for terminal capabilities.
At this point, users take for granted that you can use just about any terminal with a Unix system and use screen-oriented programs like vi without any problem. But this is really quite remarkable!
The termcap database is contained in a single text file, which grew quite large over the years to include descriptions of hundreds of different terminals. To improve performance, AT&T later introduced a
database called terminfo, which stores terminal descriptions in compiled form in a separate file for each terminal.
If a program is designed to use termcap or terminfo, it queries an environment variable called TERM to determine the terminal type (or terminal type being emulated), then looks up the entry for that terminal in the terminal database, and reads the definition of any capabilities it plans to use as external variables.
Programs that use termcap or terminfo range from screen editors like vi and emacs (Section 19.1), which use the complete terminal description, to a program like clear, which needs to know only one capability (the escape sequence to clear the screen). Other programs include more, pg, rogue, tset (Section 5.3), ul, and nroff.
—JS and SJC
5.3 Setting the Terminal Type When You Log In
If you always work at the same terminal or use the same terminal emulator, there's no problem with setting the terminal type explicitly in your shell setup file (Section 3.3) — like .login or .profile. Just set the TERM environment variable (Section 35.3):