|
|
|
|
|
|
|
|
In this two-part article, Arnold shows us how small is beautiful when it comes to user interfaces.
by Arnold Robbins
This column briefly describes Plan 9 From Bell Labs, an operating system done by the original group at Bell Labs that did Unix. We will be focusing on the user interface part of Plan 9. It is interesting, since the major components are either freely available from AT&T, or have been cloned in freely available software. The article will be concluded next month.
In the late 1980's, the research group at Bell Labs started to feel that Unix had reached the end of its useful life as a research vehicle. They decided that it was time to start over, taking the useful lessons learned from Unix, and going on from there. A brand new operating system was developed, named Plan 9 From Bell Labs.
The result is documented in two sets of papers. The early papers discuss the overall design of Plan 9, its shell, compiler, and window system. The later set contains additional papers about the system and the entire reference manual for the system. What is really neat is that PostScript for all of this is available via anonymous ftp (see the sidebar). The reference manual is huge, over 650 pages; it helps to print it on a duplexing printer, if you have one available. A mailing list of Plan 9 licensees and other folks who are interested in Plan 9 is also available.
Plan 9 is a distributed system. It consists of three components: File servers, where all the user files live; CPU servers, where computing intensive tasks are done; and terminals, which handle the user interface. The compute and file servers are large machines that live in a machine room. At Bell Labs, they are connected by a high-speed fiber network, although the software does not require this. The terminals are small computers with mice, keyboards, bitmapped displays, and network connections to the file and compute servers. Terminals may have local disk drives for performance reasons, but they are used for caching files and are not strictly necessary.
Plan 9 is also a heterogeneous system. The operating system has been ported to the MIPS, Motorola 680x0, Intel 80386/486, and Sun SPARC architectures. At Bell Labs, they tend to use the MIPS systems for their servers and the other systems for the terminals, but again, that is not built in to the software.
Plan 9 also has a number of nice innovations in the software architecture seen by the programmer. As a simple example of this, in Unix, there are multiple system calls that affect the meta-information about a file (owner, mode, etc) such as chown, chmod, and utime. In Plan 9, there is only one, wstat, which writes the stat information about a file. As another example, all user and group names are returned by the system as strings, the programmer never has to manage the conversion between numeric user ids and strings. There are many other very elegant improvements upon the Unix design in Plan 9.
Plan 9 is also one of the first systems to use Unicode, a 16 bit character set. The sam and 9term programs discussed below also support Unicode, making it possible, for example, to type a real smiley character, instead of the usual three-character ASCII glyph.
(A parenthetical note on my soapbox. In many ways, Plan 9 is a considerably superior design over Unix. It would be worthwhile for those interested in a free version of Plan 9 to consider starting from the Linux code base, using the device drivers, memory management, and whatnot. Linux itself is and will remain a Unix clone, and Unix is not Plan 9. Starting from Linux will be particularly easy when Linux 2.0 comes out, as it will be multi-platform, like Plan 9, or so I'm told.)
This should whet your appetite. Both the early and the current Plan 9 papers are well worth reading. The manual is also fun to browse.
Plan 9 is not (unfortunately) generally available. Universities may license it from AT&T for no cost (other than time spent by the lawyer to review the license). Upon signing a license, AT&T sends one hard-copy of the manual and a CD-ROM. The current (as of December 1994) release is almost two years old, and the system has evolved somewhat. A new release, using PC based hardware as the porting base, is in preparation, but no release date is known yet. The AT&T researchers are working towards a way to release it more generally, but it will still require some kind of license; it will not be freely available the way Linux, NetBSD, or FreeBSD are.
In this article, we will take a look at the Plan 9 editor, windowing system, and shell. They are important, because the editor is freely available, and there are freely available clones of the others.
The Plan 9 editor is named sam. (Some history here. The original Unix editor was ed. It was command-driven. Rob Pike wrote a mouse-driven editor for the Blit terminal named jim. The successor to jim was sam, also written by Rob Pike. Basically, they're all a bunch of friendly, down to earth sort of programs.... :-) (I'm told that sam is short for "samantha", and female.)
sam is a multi-file, multi-window editor that elegantly combines extended regular expressions (egrep-style) and the powerful ed command set with mouse driven text selection, cutting, and pasting. In particular, all operations act upon the selected text, which can include multiple lines. Replacement text can include newline characters as well.
sam also provides an infinite "undo" capability, so you don't have to worry about making mistakes.
One of the windows that sam provides you is the command window, where you type in commands. What is nice is that, just like the text in any other window, you can edit the text in the command window, then select the edited line with the mouse, and send it again as input. In other words, you can edit previous commands and submit them for execution again. If a substitution didn't work or do quite what you wanted it to do, undo the change, edit the command, and try again. Do this as often as you like. Or, if you used a series of commands on a chunk of text once, and need to do that series again, select all the command lines, and send them all at once. (The command window is similar to the mini-buffer in Emacs.)
As an example, when replying to email, I'll often include the original letter, preceded with > signs. Sometimes I end up with text that has only part of a line, like this:
> So what > is your opinion about the future life of > systems like MVS, VMS, VM, and Solaris?
I can select these lines as a single group, and then reformat it with the following commands:
s/^> //g |fmt s/^/> /g
This removes the > signs, runs the text through fmt to make it look nice, and then adds the > signs back in. The result might be:
> So what is your opinion about the future life of systems >like MVS, VMS, VM, and Solaris?
(In fact, I was able to snarf the commands out of my article text, paste them into the command window, edit them a bit, and then submit them to make the new text above.)
The command language is particularly powerful, using a notation called "structural regular expressions". Essentially, regular expressions can be cascaded together to select increasingly more specific chunks of text upon which to operate. Here is an example from the sam paper. Suppose you wish to change all occurrences of a variable n to now be called num. You could use the following command:
, x/[A-Za-z_][A-Za-z_0-9]*/ g/n/ v/../ c/num/
The comma selects all lines (an abbreviation for 0 through $, the last line). The x command extracts text to operate upon. It is an iterator, meaning that the command following it will be executed for each match of the text. The sam paper explains the rest of the command: "The pattern [A-Za-z_][A-Za-z_0-9]* matches C identifiers. Next, g/n/ selects those containing an n. Then v/../ rejects those containing two (or more) characters, and finally c/num/ changes the remainder (identifiers n) to num." The g and v commands are conditionals. g says execute the command only if the pattern matches; v is the opposite--execute the command only if the pattern does not match.
Simple changes are often made with the mouse. But for complex, sweeping changes, a command language such as the one in sam is essential. Indeed, this is why vi includes the ed command set as a subset.
As mentioned, sam is a multi-file editor. You can have several files open in windows at once, and several windows on the same file. This is particularly useful for cut and paste operations when going from one file to the next. The command language also provides commands for doing operations on all files that contain, or do not contain, a particular regular expression.
To summarize why I find sam attractive:
This last is particularly useful; it is one of those things that once you have it, you can't believe you ever lived without it.
sam is implemented on top of two libraries. The libframe library provides windows (frames) of text. This library is implemented in turn on top of libg, a graphics library. For Unix, the Plan 9 sam and libframe code is used, essentially unchanged, on top of libXg, an implementation of libg for X windows using the Xt toolkit. All of this software supports Unicode. It is possible, for example, to enter the 1/2 symbol by typing ALT-1-2.
See the sidebar for the ftp location of sam; AT&T has graciously made it available free of any licensing worries. There is also a mailing list for sam users.
The mailing list archive includes a sam emulator for Emacs, written by Rick Sladkey (jrs@world.std.com).
The Plan 9 windowing system is called 81/2, since it was the Eight and a half'th windowing system that Rob Pike had written. To create a new window, you select New from the right button menu, and sweep out the window you want. That window then runs a shell (rc, discussed below).
What is unusual about the windows in 81/2 is that you can edit the text directly in the window. Thus, if you make a typing error in a command, you fix the error, select the entire line, and resubmit it. This obsoletes the need for built-in command history as found in current Unix shells, such as ksh, bash and tcsh.
Furthermore, windows provide more complicated text editing capabilities. By pressing the ESCAPE key, the window goes into "hold mode". All text is kept in the window. It is not sent to the program running in the window until the ESCAPE key is hit again, leaving hold mode. Hold mode is indicated by an extra white border inside the window, and a larger, white arrow for the mouse cursor.
You might use this, for example, when sending mail to someone. Run the Mail command, and then go into hold mode. Type in, edit, and rearrange your letter to your hearts content. Then leave hold mode, and out goes your mail to the Mail program.
Finally, by default, 81/2 windows do not scroll. Instead, text just buffers up inside them until you are ready to look at it. The down-arrow key on the keyboard allows you to quickly move through the buffered text. You can use the button 2 menu to change the behavior of the window so that it does scroll. The non-scrolling mode is a feature; it obviates the need for pager programs like more, pg, and less.
The Unix program that emulates 81/2 windows is called 9term. 9term was written by Matty Farrow, at the University of Sydney, in Australia. It adds an additional library, libtext, on top of libframe and libXg. 9term is both small and fast. On a Sun SPARCstation LX, 9term starts almost instantly, while an xterm can take several seconds to start up, noticeably longer.
Besides hold mode described above, 9term provides cut and paste editing and the ability to search backwards or forwards in the window for a particular piece of text (whatever is currently selected). 9term also uses the up-arrow key to allow you to go backwards in the window, something that must be done with the mouse in 81/2.
The 9term interface is consciously similar to that of sam. Button 1 in both programs selects text, button 2 supplies the editing menu, and button 3 provides the control menu. Double-clicking button 1 at the end of a line selects the whole line, and double-clicking in the middle of a word selects the word. Finally, in both programs, menus "remember" the last command issued. Thus, the next time you call up a menu, the default action is to do what you did last time, which is often what you want to do.
Having the identical interface makes using your system much easier; you don't have to mentally "switch gears" when moving from one window to the next: your mouse and keyboard work the same way, no matter what.
9term is fast because it is simple. Unlike xterm, it is not emulating a real terminal (or two or three), trying to interpret and process escape sequences. This means, for example, that you can't run vi or emacs inside a 9term window. On the other hand, why would you want to? sam is considerably more powerful than vi, and much easier to learn than Emacs. My intent is not to start Yet Another Religious Editor War. Rather, the philosophy is that 9term doesn't have to be complicated to support screen editors, since a powerful editor, sam, is already available.
In the same directory as the 9term distribution there is a tar file with a large set of Unicode fonts for use with X. I particularly like the pelm.latin1.9 font.
The sidebar describes where to get 9term and the Unicode fonts.
In next month's conclusion, we'll discuss the shells to run inside 9term, and the 9wm window manager that completes the 81/2 emulation.
Arnold Robbins is a professional programmer and semi-professional author. He has been doing volunteer work for the GNU project since 1987 and working with Unix and Unix-like systems since 1981. Questions and/or comments can be addressed to the author via postal mail c/o Linux Journal, or via e-mail to arnold@gnu.ai.mit.edu .