ftp.freefriends.org/ftp.freefriends.org.tar/ftp.freefriends.org/arnold/Writings/plan9.interface.for.unix

Text File | 1995-02-19 | 33KB | 692 lines

[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 (|[e-mail]).

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 (|[e-mail]|),
and Markus Friedl (|[e-mail]|).

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

    |[e-mail]|: subscriptions
    |[e-mail]|: messages

    |[e-mail]|: subscriptions
    |[e-mail]|: messages

    |[e-mail]|: subscriptions
    |[e-mail]|: messages

Mailing list archives are all on ftp.sys.utoronto.ca.

The mailing list for Plan 9 is |[e-mail]|, which is the list
itself, and |[e-mail]|.  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 <[e-mail]> with 'index plan9-fans' as
the message body.  Files can be retrieved with 'get plan9-fans
<filename>'.  If you want a complete list of available commands send
'help' to [e-mail].''