home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  


UNIX Power Tools

UNIX Power ToolsSearch this book
Previous: 9.18 Process Substitution Chapter 9
Saving Time on the Command Line
Next: 9.20 Too Many Files for the Command Line
 

9.19 For the Impatient: Type-Ahead

The UNIX shells have a feature called type-ahead that allows you to continue typing while the computer is thinking about something. This is convenient if you have a sequence of commands that need to run in order, and you don't like waiting for the last command to finish before typing the next one.

Basically, type-ahead just means that the shell lets you keep typing, even when it's apparently "busy" (i.e., even when you don't have a prompt). You can even continue typing while the current command (in the foreground ( 1.26 ) ) is spraying data to the screen - although you may find that confusing. Any further commands you type will be executed as soon as the foreground command finishes. The easiest way to demonstrate type-ahead is with the sleep ( 40.2 ) command, which just waits:

% 

sleep 25




lpr article


% %

This sleep command does nothing for 25 seconds. Therefore, you don't see a prompt after pressing RETURN at the end of the sleep command line. However, you can type the next command ( lpr ), which will be executed as soon as the sleep is finished. The terminal driver ( 42.1 ) reads the characters you type, sticks them in a buffer, and hands them to the shell whenever the shell is ready.

What happens if something goes wrong? You can press your interrupt key ( 38.9 ) (like CTRL-c) at any time to cancel the foreground job. In this case, UNIX will discard the type-ahead, rather than execute it. (The same goes for CTRL-z, or any other signal the foreground job receives from the terminal. [3]) This is usually what you want; that is, if you press CTRL-c to terminate the foreground job, you usually don't want to execute any jobs that you've queued up afterward. Type-ahead isn't only good for giving additional commands. If your command takes a long time to start, you can type its input while you're waiting. Here's an example that's about as extreme as you're likely to see. It uses ftp ( 52.7 ) , a program for connecting to a remote host:

[3] There are some situations - like executing commands within an Emacs "shell window"-where stopping the foreground command may not flush the type-ahead commands.

% 

ftp
open golgonooza
loukides


ftp> Connected to golgonooza.
220 golgonooza FTP server ready.
Name (golgonooza:mikel): 331 Password required for loukides.
Password:

I managed to enter my first ftp command and my login name (which I knew ftp would ask for) before ftp started. You probably can't use type-ahead for your password, though I've seen some odd systems on which this would work. Even if it works on your system, you shouldn't try it; ftp hasn't had time to turn keyboard echoing off, so your password will appear on your terminal, where anyone can read it.

Using type-ahead like this takes some guts; you have to know exactly what input your application will want, and when it will want it. But it's also fun in a perverse sense. You will find occasional applications (particularly applications that take over the screen) that don't allow type-ahead. However, there's no way to predict what will and what won't. I've seen some Emacs implementations that would let you start editing the file before the editor "came up" on the screen; I've seen others that wouldn't. [ vi almost always lets you type commands as it starts. -JP  ]

I have a really terrible way of using type-ahead-I don't recommend it, but it shows what you can do. Rather than use a news reader ( 1.33 ) , I often cd to a news directory and use grep ( 27.1 ) to search for interesting articles. While I watch pages of grep output scroll by, I start typing a more ( 25.3 ) command, using the article numbers that I'm interested in. By the time grep has worked through the whole newsgroup, I've finished the more command, and I'm ready to read the articles that grep told me about. (I didn't say this wasn't perverse. And it's easier on terminals that use a slow data rate.)

- ML


Previous: 9.18 Process Substitution UNIX Power Tools Next: 9.20 Too Many Files for the Command Line
9.18 Process Substitution Book Index 9.20 Too Many Files for the Command Line

The UNIX CD Bookshelf Navigation The UNIX CD BookshelfUNIX Power ToolsUNIX in a NutshellLearning the vi Editorsed & awkLearning the Korn ShellLearning the UNIX Operating System