[The usual conventions apply. |foo| should be in courier, and *foo* in italics. Where I have 1/2, use a 1/2 symbol, in troff it would be \(12] What's GNU Arnold Robbins In this two-part article, Arnold shows us how small is beautiful when it comes to user interfaces. This month's column briefly describes [italic] Plan 9 From Bell Labs [normal], 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. Plan 9 ====== 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 [italic] Plan 9 From Bell Labs. [normal] 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 |sam| Editor ================ 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: 1. It is multi-file and multi-window. 2. It has a powerful command language that makes many editing operations easy. 3. It is possible to *edit your commands*. 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 |9term| Terminal Emulator ============================= The Plan 9 windowing system is called 8-1/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 8-1/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 heart's content. Then leave hold mode, and out goes your mail to the |Mail| program. Finally, by default, 8-1/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 8-1/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 8-1/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 8-1/2 emulation. ------------- split here -------------------- What's GNU Arnold Robbins This month's column concludes the article on [italics] Plan 9 From Bell Labs [normal], and those parts of it that have been re-implemented in freely available software. Last month we described the origins of Plan 9, the |sam| editor, and the |9term| terminal emulator. The |rc| Shell ============== Well, what about the shell to run inside the window? Here too, the Plan 9 people took the opportunity to rethink the issue of just how should a shell work. The Plan 9 shell is called |rc|, because it ``runs commands''. Although in many ways the Bourne shell is a simple, elegant, high-level programming language, it has a serious flaw, in that it was designed to be much like a macro-processing language. Input text is scanned, rescanned, and rescanned again, as each stage of processing is performed. (This is carried to an almost absurd length in the Korn shell, with something like eleven different processing stages.) This leads to rather complicated and baroque quoting rules, with the need for nested escape sequences. In |rc|, the input text is scanned and parsed exactly once. The language has a real |yacc|-based grammar, making it clear what everything means. The quoting rules are very simple. Quoted text must be enclosed between single quotes. To get a single quote inside a quoted string, double it (as in FORTRAN). An explicit operator is used to provide string concatenation, and variables can be lists of strings, not just single strings. The syntax is closer to that of C or |awk|, instead of Bourne's Algol 68. This leads to less clutter, avoiding unnecessary keywords and semi-colons. It is much more like C than the fabled |csh| is. |rc| provides shell functions, and signal handlers are written as functions with special names (|sighup|, |sigterm|, etc.), instead of using strings. I/O redirection is also more powerful, with a notation for hooking up file descriptors besides 0 and 1 to the input and output ends of a pipe. A freely distributable clone of |rc| is available. It was written by Byron Rakitzis, and implements the language described in the |rc| paper, with some extensions. The beauty of |rc| is that it is small and fast, and shell programs can be quite elegant. It also runs on just about any kind of Unix system. When using |rc| with |9term|, it is conventional to set the primary prompt to be just a single semi-colon, and the secondary prompt to be empty. This allows you to snarf entire commands, including the prompt, and resend them. The semi-colon is treated as a simple null statement. The use of double-clicking to select the whole line, and the default saved action of the menus make sending and resending the same line over again extremely simple; most of the work can be done with just the mouse. The Resources sidebar lists the |ftp| location of the |rc| shell. There is also a mailing list of people who use |rc|. es == |es| is the ``extensible shell.'' Paul Haahr and Byron Rakitzis thought it would be interesting to try and combine some of the capabilities of functional languages with those of Unix shells. Many internal capabilities of the shell (such as I/O redirection and setting up pipelines) are available as built-in functions in the language, and program fragments can be passed around as arguments to functions. |es| provides first class functions, lexical scope, an exception system, and rich return values (i.e. functions can return values other than just numbers). Most of this is beyond the scope of this article to explain. |es| is described in a paper in the Winter 1993 Usenix Conference Proceedings. It helps to read this paper, and also to go through the archives of the mailing list to see how the language evolved. For the full details on |es|, you'll need to read the paper, the man page, and the file initial.es in the |es| distribution. It is a good idea to also look at the sample .esrc file, too. Basically, the idea behind |es| is to take the primitive operations that a shell does, such as forking processes, creating pipes, and setting up I/O redirections, and make them available as functions that a user program can call directly. In turn, traditional shell syntax is built on top of these primitive operations. Lexical scoping allows you to save the definition of an operation, and then replace it with your own operation on top of the previous one. Here is an example from the paper on |es|. This code implements a pipeline profiler. It saves the definition of |%pipe|, which creates pipes, and provides a new one that times each component of the pipeline, using the old |%pipe| to actually create the pipeline. (|es>| is the prompt from |es| used for examples in the paper. The default prompt is a semi-colon.) es> let (pipe = $fn-%pipe) { fn %pipe first out in rest { if (~ $#out 0) { time first } { $pipe { time $first } $out $in { %pipe $rest } } } } es> cat paper9 | tr -cs a-zA-Z0-9 '\012' | sort | uniq -c | sort -nr | sed 6q 213 the 150 a 120 to 115 of 109 is 96 and 2r 0.3u 0.2s cat paper9 2r 0.3u 0.2s tr -cs a-zA-Z0-9 \012 2r 0.5u 0.2s sort 2r 0.4u 0.2s uniq -c 3r 0.2u 0.1s sed 6q 3r 0.6u 0.2s sort -nr This is a simple example, yet it illustrates some of the power available in |es|. |es| really deserves a column on its own. For more information, see the above sources and the mailing list archive. The sidebar lists the |ftp| location for |es|, and a mailing list is also available. The |9wm| Window Manager ======================== The tools we've seen so far, notably |sam| and |9term|, are built on top of X Windows, and work with any window manager. For some time, I ran them using |mwm|. In the fall of 1993, I obtained a version of |gwm|, the Generic Window Manager, with WOOL (Windows Object Oriented Lisp) code that implemented an interface very similar to that of the original Bell Labs Blit terminal. This provides a simple, clean interface, similar to that used on Plan 9 (8-1/2 can be considered a further evolutionary step from the Blit). This code was written by John Mackin at the University of Sydney. The resources sidebar shows where you can get this code, if you're interested. This code works, but it is large and slow. However, a new window manager recently became available, |9wm|. |9wm| implements the window management policies of 8-1/2, under X windows. Written by David Hogan at the University of Sydney, it uses raw Xlib (not a pretty sight), and is completely ICCCM compliant. |9wm| is also small, and very fast. To quote from the README file: 9wm is an X window manager which attempts to emulate the Plan 9 window manager 8-1/2 as far as possible within the constraints imposed by X. It provides a simple yet comfortable user interface, without garish decorations or title-bars. Or icons. And it's click-to-type. This will not appeal to everybody, but if you're not put off yet then read on. (And don't knock it until you've tried it). |9wm| is ``click to type.'' This means you have to move the mouse into a particular window and then click button one. That window becomes the current window, indicated by a thick black border. Other windows have a thin black border. This behavior is identical to |sam|'s. The |9wm| menu (accessed through button 3 on the root window) consists of five items: |New| - open a new window (|9term|, or |xterm| if no |9term|) |Reshape| - change the shape of a window on the screen |Move| - move a window |Delete| - blow away a window |Hide| - ``iconify'' a window What is perhaps most noticable about |9wm| (and the way 8-1/2 works) is that there are no icons. Instead, to remove a window from the screen, you select |Hide| from the main menu. The cursor becomes a target. You move the target to the window to be hidden, and then click button 3. Clicking any other button cancels the operation. When a window is hidden, it disappears from the screen completely, not even leaving an icon. Instead, a new item appears at the bottom of the button 3 |9wm| menu, with the name of the window. To open the window again, you simply select the window's name from the menu. As with the other programs, the |9wm| menu remembers what you did last time, so that the next time you pop up the menu, the previous selection is already highlighted The |9menu| Command Line Menu Program ===================================== And now, my own small contribution to the picture. The GWM Blit emulation, which I used for quite awhile, understood that it was built on top of X, and when you selected |New|, it gave you a menu of hosts (that you defined in a configuration file) on which to start remote |xterm|s. This was nice, and I found it missing under |9wm|. (In Plan 9, this is not an issue; the multiple hosts in the network are very tightly integrated, but in X with Unix, it is a problem.) What I wanted was a simple program to which you could give menu items and associated commands, and this program would pop up a window that was nothing but a menu. Selecting an item would run a command. The program would be long lived, leaving the menu up permanently. There exists a program that is close to this, |xmenu|. Unfortunately, |xmenu| goes away after executing the command, and is not well behaved when interacting with |9wm|. Inspired by |9wm|, starting with its menu code, and with help from David Hogan, I wrote |9menu|. |9menu| pops up a window containing the list of items, and executes the corresponding command when a button is pressed. |9menu| allows you to write your own menus and customize the behavior to suit you, without the headaches of a .twmrc or .mwmrc file. It is real easy to have one item spawn another |9menu|, giving a similar effect to pull-right menus. Here is how I use it, one for remote systems, the other for programs I may want to run. Being lazy, I have |xterm| in both. I use a shell script named |rxterm| that knows about the remote hosts I will want to open windows on, and whether they can start a |9term| or an |xterm|. (This is left over from the GWM Blit code, and is mostly for convenience.) These examples are from my .xinitrc. The |-geometry| strings are to get |9wm| to place the windows even though they start out iconified. 9menu -geometry 67x136-4+477 -iconic -popdown -label Remotes \ 'solaria:rxterm solaria.cc.gatech.edu' \ 'burdell:rxterm burdell.cc.gatech.edu' \ 'chrome:rxterm chrome.cc.gatech.edu' \ 'xterm:rxterm xterm' \ exit & 9menu -geometry 103x102-3+624 -iconic -popdown -label 'X programs' \ 'xterm:rxterm xterm' \ xtetris xlock '9wm restart' '9wm exit' exit & I start the programs using |-iconic| so that they'll be automatically hidden and part of the |9wm| menu. The |-popdown| option causes the menu to automatically iconify itself after an item is selected, since I find this to be the most convenient way for me to work: pop up the menu, select an item, and then go on with what I want to do without the menu hanging around. Although not nearly as large scale a program as |sam|, |9term|, or |9wm|, I find that |9menu| completes the package for me. Experiences =========== I have been using this environment for almost two years, and find it to be clean, elegant, and easy to use. Initially, I started by using |rc|, and then |sam| when it became available in early 1993. Shortly after that, I started beta-testing |9term|, in particular getting it to work correctly under SunOS. In the fall of 1993, the GWM Blit code became available, and I switched to that, using it for almost a year. In the spring of 1994, I started beta-testing |9wm|, which was finally released at the end of 1994. I switched to |es| in January of 1993 after reading about it and hearing the presentation at the winter Usenix. The research group at Bell Labs is well known for applying the ``small is beautiful'' principle to software design. This was initially true of Unix, and has been re-applied to distributed systems, shells, and user interfaces with Plan 9. The interface is simple, consistent, easy to use, and very clean. All the programs described in this column behave the same way, in terms of what the buttons do, which window is current, and how the menus remember the previous operation. An important point that I have not emphasized so far, is that all the programs use pop-up menus. I find this to be an enormous convenience, particularly compared to systems like Windows or the Macintosh, where you *must* move the mouse to the menu bar to pull down a particular menu. Pop-up menus save an incredible amount of otherwise useless mouse motion, leading to a system that is much easier to use. My first exposure to window systems was long ago, on a Blit terminal. The interface was simple, clean and elegant. Ever since then, I had been searching for an X windows environment that matched the Blit's elegance. Now, with the combination of |sam|, |9term|, |9wm| and |rc| or |es|, I feel that I have finally found that environment, and I'm very happy. What's even nicer is that all of these programs are fast, and I have the broad range of X applications available to me also (|xoj|, anyone?). This latter point is unfortunately not true of the only other alternative, |mgr| (which I used until |9term| became available. Using These Programs Under Linux ================================ All the programs described here can be made to compile under Linux. I don't have a Linux system of my own (believe or not!), but for a while I borrowed one, and was able to bring up all of these programs. Unfortunately, the system was a laptop, with too small a screen to make using X worthwhile. |sam| comes up fine, using the Make.solaris makefile as a starting point. |9wm| also compiled just fine. |9term| took a little bit of work, but it did compile and run. After asking on the mailing lists, I learned that |9term| does not (yet) work quite correctly under Linux. This may be fixed by the time you read this column, though. Two people to contact for information about porting |9term| to Linux are: Pete Fenelon (|pete@minster.york.ac.uk|), and Markus Friedl (|msfriedl@faui01.informatik.uni-erlangen.de|). |rc| and |es|, both compile and run under Linux, but with some work. For |rc|, you have to generate the sigmsgs.c file by hand, based on /usr/src/linux/include/sys/signal.h. There is one other bug, reported by Jeremy Fitzhardinge, which is that |rc| uses |int|s for the array of additional groups, while Linux uses |gid_t|s, which are |short|s. |es| requires similar changes for the signal handling, but these are actually documented in the Makefile. Summary ======= The combination of |9term| and |9wm| provides a very close emulation of the elegant Plan 9 user interface. |sam| is a powerful, easy to use editor. |rc| is a simple, clean shell, and |es| is a nifty shell with lots of promise. It is worth reading the papers describing each of these components. The complete combination proves once again that ``small is beautiful.'' Acknowledgements ================ Thanks to Chris Seibenmann and Daniel Ehrlich, maintainers of the various mailing lists, for their help, as well as to the members of the lists who responded to my questions about Linux. Thanks to Bob Flandrena, Paul Haahr, and Miriam Robbins for their comments. References ========== 1. Rob Pike, Dave Presotto, Ken Thompson, and Howard Trickey, ``Plan 9 from Bell Labs'', Proc. of the Summer 1990 UKUUG Conf., London, July, 1990, pp. 1-9. 2. Rob Pike, Dave Presotto, Ken Thompson, and Howard Trickey, ``Plan 9, A Distributed System'', Proc. of the Spring 1991 EurOpen Conf., Troms, May, 1991, pp. 43-50. 3. Rob Pike, ``The Text Editor |sam|'', Software---Practice and Experience, November 1987, Vol. 17, #11, pp. 133-153. 4. Rob Pike, ``8-1/2, the Plan 9 Window System'', Proc. of the Summer 1991 Usenix Conf., Nashville, June 1991, pp. 257-265. 5. Tom Duff, ``Rc - A Shell for Plan 9 and UNIX Systems'', Proc. of the Summer 1990 UKUUG Conf., London, July, 1990, pp. 21-33. These papers are all available in Postscript as part of the Plan 9 documentation. 6. Paul Haahr and Byron Rakitzis, ``Es: A shell with higher-order functions'', Proceedings of the Winter 1993 Usenix Conf., January 1993, pp. 53-62. This paper is available for |ftp| along with the |es| source code. RESOURCES sidebar: plan9.att.com:/plan9/plan9doc/* plan9.att.com:/plan9/plan9man/* information on Plan 9 (including the 8-1/2 manual entry). plan9.att.com:/plan9/doc/* troff and Postscript for papers describing the current system. netlib.att.com:/netlib/research/sam.msg.Z source code and information on Rob Pike's editor |sam|. ftp.cs.su.oz.au:/matty/unicode/* source to |9term| and the Unicode X fonts (get README first). rtfm.mit.edu:/pub/usenet/comp.unix.shell/rc-FAQ information on |rc| (or look in |comp.unix.shell|). ftp.sys.toronto.edu:/pub/rc/rc-1.4.tar.Z source to |rc|. ftp.sys.toronto.edu:/pub/es/es-0.84.tar.Z ftp.sys.toronto.edu:/pub/es/usenix-w93.ps.Z source to |es| and the Usenix paper describing it. ftp.sys.toronto.edu:/pub/9term/gwm-dist.tar source to the GWM Blit distribution. ftp.cs.su.oz.au:/dhog/9wm/* source code for |9wm|. ftp.cc.gatech.edu:/pub/people/arnold/9menu-1.3.shar.gz source code and man page for |9menu|. Here are the mailing list addresses for |sam|, |rc|, and |es|. |9term| is generally discussed on the |sam-fans| list. |sam-fans-request@hawkwind.utcs.utoronto.ca|: subscriptions |sam-fans@hawkwind.utcs.utoronto.ca|: messages |rc-request@hawkwind.utcs.utoronto.ca|: subscriptions |rc@hawkwind.utcs.utoronto.ca|: messages |es-request@hawkwind.utcs.utoronto.ca|: subscriptions |es@hawkwind.utcs.utoronto.ca|: messages Mailing list archives are all on ftp.sys.utoronto.ca. The mailing list for Plan 9 is |9fans@cse.psu.edu|, which is the list itself, and |9fans-request@cse.psu.edu|. This latter address is an automated mail server that will reply with a message telling you how to subscribe. The server also manages the archives. According to Daniel Ehrlich, the manager, ``You can get a list of available files by sending e-mail to with 'index plan9-fans' as the message body. Files can be retrieved with 'get plan9-fans '. If you want a complete list of available commands send 'help' to majorodomo@cse.psu.edu.''