A New Object-Oriented Programming Language: sh

Jeffrey S. Haemer
Canary Software, Inc.

Abstract Sessions’ talk used application code size as one

Many have frittered away their time on C++, measure of the advantages of object-oriented pro-
while overlooking the new, POSIX.2-required, object- gramming. By that measure, and with the same
oriented language: sh. As will be clear from the examples, this system is better than C++. In fact, the
enclosed code, the name may allude to the fact that core of the entire system, the two shell scripts create
the author would be embarrassed to have anyone find and send, total a little over 100 lines of code. If you
out about it. don’t find your favorite OOP feature, it may not be
very hard to add it.
This paper introduces a tiny, object-oriented
programming system written entirely in POSIX-
conforming shell scripts. $ cat animalia
new animal pooh bugs
1. Overview
send pooh setName Pooh Bear
Object-oriented programming is currently all the rage
send pooh setFood Hunny
[King89]. Though we normally use languages
send bugs setName Bugs Bunny
designed specifically for the task, they aren’t always
send bugs setFood Carrots
necessary. Here, we illustrate this point by doing
object-oriented programming in the shell.
for i in pooh bugs
In what follows, object classes are shell scripts do
and objects are running processes. Methods are send $i getName
invoked by messages passed to objects through send $i getFood
FIFOs (named pipes). The methods themselves are done
implemented as shell functions; function polymor-
phism is guaranteed because separate programs have echo
separate name spaces. A class hierarchy is provided
by the file system itself. new dog Snoopy
Sensible default actions are taken by objects new littleDog Toto
when they’re sent messages for which they lack new bigDog Lassie
explicitly defined methods. Debugging code can be
added to objects on the fly, that is, after they’ve been for i in Snoopy Toto Lassie
created. do
echo $i says
While the system is unconventional, only a toy, send $i bark
and downright slow, its implementation is straightfor- echo
ward and its use instructive. For example, figure 1 done
shows an implementation of the examples used in
Roger Sessions’ Summer, ’93 USENIX Invited Talk destroy bugs pooh
[Sessions93]. destroy Snoopy Toto Lassie
$ ./animalia operate on from their ‘‘parent’’ classes. This
My name is: Pooh Bear sort of inheritance produces a tree-structured
My favorite food is: Hunny class hierarchy. Implementing class hierarchies
My name is: Bugs Bunny means picking a way to define trees.
My favorite food is: Carrots UNIX has two ubiquitous tree structures that
seem plausible choices, either of which might
Snoopy says be worth barking up: the file system and the
Unknown Dog Noise process tree. Deciding to make object classes
conceptually distinct from objects, and making
Toto says the latter simply instances of object classes,
woof woof guides our choice. In this system, executing
woof woof processes are objects; programs are their defi-
nitions, the object classes. The file system
Lassie says implements the class hierarchy. Although a
WOOF WOOF process can be any executing program image,
WOOF WOOF in this system all objects will be shell scripts.
WOOF WOOF
WOOF WOOF • Polymorphism
WOOF WOOF A good object-oriented system lets the pro-
grammer extend the suite of object classes
Figure 1. Animalia without changing existing software. Programs
can operate on new kinds of data that get
defined long after the code is written. The
same operation may be implemented different
ways for different kinds of data, but the invoca-
2. Design
tion of the operation is identical. What sepa-
As a foundation, we begin by reviewing the three rate compilation provides for functions, object-
basic object-oriented features: encapsulation, func- oriented programming provides for data.
tion polymorphism, and inheritance. These require-
For example, if each new object responds to
ments, plus sloth — an eagerness to let UNIX and the
pass(), there is no need to change base code
shell do as much of the job as possible — lead
from
directly to most major design decisions.
pass(X)
• Encapsulation
to
All object-oriented systems provide data
abstraction and encapsulation; they let pro- if (object_type(X)==BILL)
grammers create and operate on objects that pass_bill(X);
have user-defined types, while hiding all else if (object_type(X)==BUCK)
knowledge about how those operations and pass_buck(X);
types are implemented. Programs are pre- else if (object_type(X)==GAS)
vented from manipulating an object’s internal ...
data structures except through the methods that
operate on those objects. C++ and UNIX device drivers implement this
sort of behavior by using tables of function
UNIX processes are attractive candidates for pointers. read() is always read(), whatever the
objects. Each running, UNIX process has its device, because the kernel figures out what
own name and address space; it’s impossible to routine to call based on the device that’s being
look at or tweak the insides of an already run- read from.
ning process unless the process is running
under a debugger. Many other object-oriented systems, like
Smalltalk, implement polymorphism by pass-
• Objects and the object-class hierarchy ing messages between objects, which interpret
Object-oriented programming systems try to the messages at runtime. Thus, the instruction
maximize code reuse by letting new data types X pass
inherit methods and the data structures they
works whether X is a bill or a buck, because it
 just sends a message. Both bill and buck Taken together, send and create are cur-
understand the message ‘‘pass,’’ but each rently only a little over 100 lines of shell code. (The
implements the operation with a data-type- new and destroy commands, used in the example
specific method. in the first section, are just loops that call create
Here, we take this latter approach. Class defi- and send exit for each of their arguments.)
nitions are shell scripts. Methods are shell A handful of interesting things fall out of
functions. Messages are just the names of the implementing objects this way.
functions, sent as ASCII strings. Two different • Process manipulation commands can be used
scripts are free to use identical names for com- to handle objects. You can search for objects
pletely different functions. with ps and destroy them with kill -9.
One side-effect of this approach is that mes- • Every object understands normal shell com-
sages sent to objects that are not names of mands. Not only can you see if an object is
functions are interpreted as other sorts of exe- alive, but you can see if it’s paying attention
cutable statements: built-ins and shell com- with commands like this:
mands. On first blush, this seems like a horri-
ble bug; in practice, and to my surprise, it feels $ send pooh date
like a feature. Sun Jan 23 21:00:25 MST 1994

• You can kill objects with exit. This is enor-

3. Implementation mously comforting. (Since I haven’t gone to
great lengths to make this system any more
Each object is a simple, infinite loop:
bullet-proof than it deserves to be, it’s also
forever enormously necessary.)
read message from FIFO
• You can add methods to objects on the fly.
execute it as a command
This sort of thing actually works:
The FIFOs are created in a pre-arranged spot in the
$ send X ’zzazz() { echo foo }’
file system and have names tied to the names of their
$ send X zzazz
corresponding objects. Messages are sent with the
foo
program send. The command
From time to time, this last feature has proven
$ send pooh setFood Hunny
itself a useful debugging tool.
just writes the message setFood Hunny to pooh’s
input channel /tmp/ipc/pooh/in.
4. Real Code
Object creation is trickier, but not by much.
Each object class is a shell script, stored in a direc- Enough abstract chatter. Let’s see some code.
tory tree where the directory and subdirectory names
are class and subclass names. Each directory con- 4.1. send
tains one script, named class, that defines the
send, shown in figure 2, sends messages to
methods for the class corresponding to that directory.
objects.
A request to create an object of type name starts up a
process like this:
use find to find directory name # send a message

source all the class methods case $1 in

from the root of the class tree -d) msgtype=D
down to that definition shift ;;
*) msgtype=C ;;
create a FIFO tagged to esac
the name of the object
T_NAME=$1
loop forever, reading and executing messages shift
(as shown above).
T_DIR=/tmp/ipc/$T_NAME
T_IN=$T_DIR/in The first of these is the deadlock that arises
T_OUT=$T_DIR/out when object A sends a message to object B and
USAGE=\ object B, or some object further down the line, sends
"usage: $(basename $0) obj msg" a message to object A before object B has replied to
A’s original message. In these cases, object A cannot
abort() { # print and bail read the incoming message because it is blocked
echo $* 1>&2 reading B’s output channel. The general case is a
exit 1 general problem, but in a some cases object A doesn’t
} really need B’s answer, and can go on to listen for
incoming messages as soon as it dispatches a mes-
test $# -gt 0 || abort $USAGE sage to B. For just such cases, send accepts a flag,
-d, that means ‘‘don’t wait for an answer.’’ Send
test -d $T_DIR || prepends a ‘D’ to such ‘‘datagrams,’’ and replies are
abort $T_NAME: no such object neither expected nor supplied.
The second problem is trickier. In the absence
echo -e $msgtype "$*" > $T_IN of special arrangements, an open of a FIFO for writ-
test $msgtype = "D" || cat $T_OUT ing will only complete when that FIFO has an avail-
able reader. Consider, then, what happens when
exit 0 object A sends a message to itself, using a command
like
Figure 2. send
echo $msg > /tmp/ipc/A/in.
The echo will block, awaiting a reader, preventing A
All object I/O channels are in subdirectories of from ever executing the read that would move echo
/tmp/ipc. Each named object has a subdirectory that past the block.
corresponds to its name, T_DIR, and all files associ- The current implementation side-steps this
ated with that object are within that directory. By problem by providing each object with a built-in ver-
default, each object has at least an input channel, sion of send. Whenever an object notices that it is
T_IN, through which messages arrive, and an output sending a message to itself, it executes the message
channel, T_OUT, to which returns are sent. directly instead of trying to write the message to its
The code shown above sets environment vari- own input channel. (See figure 7.) An alternative to
ables to point at the right channels, and then, after a this would be putting echo in the background, but
brief sanity check, echoes its argument into the input that would use up process slots, a resource that this
channel and reads the objects response from the out- system already strains. Another alternative might be
put channel. writing substitutes for read and echo.
There are at least two restrictions of this
design. First, the name space is global to the system; 4.2. create
only one object on the entire system can be called More complex than send is create, shown in
‘‘foo’’ at any given time. Second, there’s no provi- figure 3.
sion for tying returns to the messages that elicited
them; if two objects send messages to a third at
nearly the same time, there isn’t any way to guarantee # create a new object
that the return value one of the senders retrieves cor-
responds to the message it sent. A more sophisti- O_DIR=/tmp/ipc/$2
cated implementation might nest object directories as O_IN=$O_DIR/in
subdirectories under the directories of the objects that O_OUT=$O_DIR/out
created them, and use a more sophisticated messag-
ing scheme to provide a virtual circuit between the O_BIN=${O_BIN:-$HOME/obj/bin}
messenger and the messagee. O_CLASS=$1
Even after accepting these limitations, at least O_NAME=$2
two problems require immediate solution. O_PATH=/bin:/usr/bin:$O_BIN
O_ROOTS=${O_ROOTS:-$HOME/obj/objs}
export O_BIN O_CLASS O_NAME
export O_PATH O_ROOTS done
test -z $obj_root && abort $USAGE
USAGE=\
"usage: $(basename $0) class obj" # now set up paths
d=$obj_root
abort() { O_PATH=$O_PATH:$d
echo $* 1>&2 O_DEFS=$d
exit 1 while test "$d" != "$i"
} do
d=${d%/*}
test $# -eq 2 || abort $USAGE O_DEFS=$d" $O_DEFS"
O_PATH=$O_PATH:$d
# cleanliness is next to godliness done
cleanup() {
trap "" 0 1 2 3 15 unset d i
rm -rf $O_DIR }
exit 0
} # create message channels
make_channels() {
event_loop() { test -d $O_DIR &&
trap "cleanup" 0 1 2 3 15 abort "Duplicate $O_NAME"
while read pkt < $O_IN mkdir -p $O_DIR ||
do abort "Can’t make $O_DIR"
type=${pkt%% *} mkfifo $O_IN ||
msg=${pkt#[A-Z] } abort "Can’t make $O_IN"
mkfifo $O_OUT ||
if test $type = "D" abort "Can’t make $O_OUT"
then }
PATH=$O_PATH eval $msg
else # build the object from definitions
PATH=$O_PATH eval $msg \ mkobj() {
>$O_OUT for d in $O_DEFS
fi do
# hack around BSDI timing bug . $d/class 2>/dev/null
sleep 1 done
done }
}
get_obj_chain
get_obj_chain() { make_channels
mkobj
# find object and superclasses event_loop &
IFS=:
set $O_ROOTS Figure 3. create
IFS=’ ’
for i
do Following initialization and sanity checks, create
test -f $i/class || continue makes four function calls to create an object. The
obj_root=$( first, get_obj_chain, sets the variable O_DEFS to a
find $i \ list of directory names, starting at the root object
-type d \ directory, that end in the directory that defines the
-name $O_CLASS \ class. For the class littleDog, from our earlier exam-
-print ple, O_DEFS would be set to objs objs/animal
) objs/animal/dog
test -n $obj_root && break objs/animal/dog/littleDog
 Next, make_channels creates the input and out- multiple inheritance, everyone knows that multiple
put channels used by send. inheritance is a bad idea [Cargill91].
Third, mkobj visits the directories in O_DEFS,
reading class definitions. Because of the order in 4.3. new and destroy
which get_obj_chain sets up O_DEFS, methods
Returning now to the example, we can show
defined in subclasses supplement or override those
new (figure 4) and destroy (figure 5).
defined in parent classes.
Finally, event_loop loops infinitely, reading
messages and writing responses on the pair of mes- # create a set of objects
sage queues set up by make_channels. If the mes-
sage is the name of a function call — a method — USAGE=\
that function is invoked. Otherwise, eval looks for a "new class obj [obj ...]"
shell built-in or a UNIX command to execute. abort() {
A disadvantage of the approach sketched above echo $* 1>&2
is that there isn’t an easy way to say ‘‘use my parent’s exit 1
definition of this method’’; when an object definition }
overrides a method defined by a parent, that parental
method becomes completely unavailable. test $# -ge 2 ||
abort "$USAGE"
In an earlier version of this code, event_loop
looked like this:
class=$1
event_loop() { shift
trap "cleanup" 0 1 2 3 15
while read msg < $O_ICHAN for i
do do
eval $msg > $O_OCHAN create $class $i
done done
cleanup
} Figure 4. new

In the version shown in figure 3, get_obj_chain stores

the path to the directory that contains the object defi- # destroy a set of objects
nition in O_PATH, for later use in creative ways,
including prefixing it to the path used by eval. Hav- USAGE=\
ing that path available makes it possible to back up "destroy obj [obj ...]"
through the class hierarchy searching for a parental abort() {
method. I’ve experimented with this, but the trick echo $* 1>&2
isn’t entirely satisfactory; a more sophisticated imple- exit 1
mentation should find a more interesting way to use }
O_PATH or O_DEFS to gain access to parental-class
methods. test $# -ge 1 ||
abort "$USAGE"
Like send, which has a single, global name-
space for objects, create uses a global name space for for i
object classes. The system will not support two dif- do
ferent definitions of class ‘‘dog’’. On the other hand, send $i destroy
users can point at their own object-class definitions done
by setting O_ROOTS, even invocation by invocation.
Another limitation of this system is that it is Figure 5. destroy
restricted to single inheritance; each class has one
and only one parent class — that of its parent direc-
tory. Although links might make it possible to pro- As advertised earlier, each of these is a simple
vide an interesting way to implement and explore loop. The earliest version of destroy was even
simpler: The entire class definition is a single method: hop.
for i Although this is an elementary example, it
do illustrates a few interesting points:
send $i exit (1) Defining methods is easy; it doesn’t require a
done lot of special syntax.
This works because each object inherits the methods (2) Class definitions are small. While code size
understood by the base class — the shell augmented is not the only measure of the quality of a
by a few basic methods. The current version calls programming language — else we would all
destroy instead, which lets each object define its own program in APL — code size strongly affects
destructor. (The base class defines a simple default maintenance and debugging efforts; bug fre-
destroy, shown in the next section.) quency per line appears to be roughly con-
One alternative to explicit calls to destroy for stant across languages [Brooks75]. Less
each object would be to make new keep track of code, fewer bugs.
objects it has created and let destroy destroy every-
thing. As an illustration, Sessions contrasts the code
Because of encapsulation, the easiest imple- to make a dog bark in C:
mentation would incorporate new as a method in a void printDog(dog *thisDog,
more sophisticated base class. An odd side-effect of int dogType)
this is that classes could redefine new. {
printf("\n%s says\n",
getName((dog *) thisDog));
4.4. hop: a simple class
switch dogType {
Having constructed the infrastructure, let’s case DOG:
look at a simple class definition (figure 6). dogBark(
(dog *) thisDog);
break;
case LITTLEDOG:
$ cat objs/hop littleDogBark(
# class hop (littledog *)
thisDog);
hop() { break;
if test "$*" = "on pop" case BIGDOG:
then bigDogBark(
echo -n "Stop! " (bigdog *) thisDog);
echo "You must not hop on pop." break;
else }
echo "hippity hop" }
fi
with the code to do the same job in C++:
return 0
} void printDog(dog *thisDog)
$ create hop X {
$ send X hop printf("\n%s says\n",
hippity hop thisDog->getName());
$ send X hop on pop thisDog->bark();
Stop! You must not hop on pop. }
$ send X foo Here’s the same code in the shell:
$ send X exit
echo $thisDog says
$ send X hop
send $thisDog bark
X: no such object
(3) We’ve chosen to ignore nonsense requests.
Figure 6. Class hop The consequences of changing that decision
can be explored by toying with event_loop in
 create echo $O_NAME
(4) Methods can have arguments. }

This example becomes even more interesting send() { # send a message

when we notice that we can invoke methods that
aren’t defined by the class. As figure 7 shows, meth- case $1 in
ods defined by parent classes (in this case, the class -d) msgtype=D;
defined in directory objs) are inherited by their sub- shift ;;
classes *) msgtype=C ;;
esac

$ create hop X T_NAME=$1

$ send X self shift
X T_DIR=/tmp/ipc/$T_NAME
$ send X class T_IN=$T_DIR/in
hop T_OUT=$T_DIR/out
$ cat objs/class
# fundamental methods USAGE="usage: send obj msg"
test $# -gt 0 || abort $USAGE
abort() { # print and bail
echo $* 1>&2 if test "$T_NAME" = "$O_NAME" ||
exit 1 test "$T_NAME" = "self"
} then
PATH=$O_PATH eval $*
class() { return 0
echo $O_CLASS fi
}
test -d $T_DIR ||
debug() { abort $T_NAME: no such object
echo $O_NAME: $*
} echo -e $msgtype "$*" > $T_IN
test $msgtype = "D" || cat $T_OUT
defs() { }
for d in $O_DEFS
do Figure 7. The base class
cat $d/class 2>/dev/null
done
}
Most of the methods defined in objs/class
_destroy() { are simple utility methods. The motivation for the
test $# -eq 0 && exit 0 one long method, send, was given in section 4.1.
test $0 = "self" && exit 0
4.5. animals
for i
The code for to our original animal example
do
shows inheritance in practice (figure 8).
send -d $i destroy
done
}
$ cat objs/animal
destroy() {
# base animals methods
_destroy $*
}
name=$O_NAME
food="Unknown food."
self() {
setName() { ‘‘Cute idea,’’ you say, ‘‘but is this good for
name=$* implementing real applications?’’ Probably not.
} Still, it seems worth sniffing around to see what sorts
getName() { of things besides barking dogs might be interesting to
echo My name is: $name implement with it.
}
setFood() {
5.1. Starting small ...
food=$*
} When I was soliciting suggestions for interest-
getFood() { ing applications to implement, Doug Pintar, of Aztec
echo My favorite food is: $food Engineering, laconically suggested emacs. While an
} emacs implementation might not fit within the page-
$ cat objs/animal/dog limit length imposed by this conference, I can include
# dog: all bark, no bite a more contained, but logically equivalent, applica-
tion. Appendix A shows the code for a Turing
bark() { machine. The text below, sketches the implementa-
echo Unknown Dog Noise tion of each of the classes. The example, taken from
} the nearest automata theory text to hand [Manna78],
$ cat objs/animal/dog/littleDog recognizes strings of the form
# a little dog an bn
bark() { 5.1.1. Turing machine The machine itself is an
echo woof woof object that creates a tape object and five nodes. After
echo woof woof initializing all the objects, loading the tape with an
} input string and the nodes with their transition tables,
it starts up by telling the first node to go, and then
$ cat objs/animal/dog/bigDog awaits an announcement of success or failure from
# a BIG DOG some node down the line. When the announcement
arrives, the machine writes the result as output;
bark() { destroys the nodes it has created; and exits.
for i in 0 1 2 3 4
do
echo WOOF WOOF 5.1.2. Tape
done The tape itself is trivial. Input data are stored
} as a string, and there are a handful of methods to
move along the tape and to read or write at the cur-
Figure 8. Animal Objects rent position. (We’ve tried to avoid mixed-case dis-
ease, which seems endemic to object-oriented pro-
grammers, but Read requires an initial, upper-case
Here, the class animal defines methods for setting ‘R’ because read is reserved by the shell. Write is
and getting an animal’s name and favorite food; the just following suit.)
subclass dog adds a way to make the animal bark, The position is just a numeric index into the
and sub-sub-classes for little and big dogs replace string, maintained using the POSIX shell’s built-in
that method with ones that generate size-appropriate arithmetic facilities.
noises.

5.1.3. Node Nodes, too, are objects. When called

5. Applications on, a node reads the current cell on the tape and looks
Sir, a woman’s preaching is like a dog’s walking up the entry for the character it reads in a dictionary
on his hinder legs. It is not done well; but you of transitions that it creates and maintains (another
are surprised to find it done at all. object, described in the next section). Transitions are
a triple containing a character to write into the current
Boswell’s Life of Johnson, vol 1, p 428, 31 July
1763 cell, a direction to move, and a new node to call. The
current node writes the prescribed character into the
cell, moves either left or right, and then calls on {
another node (possibly itself) to handle the next cell. send $1 "$(typeset -f infect |
If the dictionary reveals that the node has reached a oneline)"
decision to accept or reject the input string, then }
instead of passing control to a new node, the current $ new null Y
node sends the message accept or reject to the origi- $ send X infect Y
nal Turing machine. $ send Y typeset -f infect
The absence of returns and lack of a single, infect ()
centralized transition table lend a palpably unstruc- {
tured aura to the process. send $1 "$(typeset -f infect |
oneline)"
Although this implementation uses a colon- }
separated array to store the three pieces of informa-
tion associated with each possible input character and Figure 9. A Simple Virus
teases them apart with cut, performance could be
improved somewhat by using the shell’s prefix- and
suffix-shaving operators — ${PARAME-
TER%%expression} and friends — to do the parsing The script oneline is a work-around for two
without recourse to subprocesses. implementation problems. First, with the code shown
here any methods learned at runtime must fit on a sin-
gle line. Second, shell quoting conventions make it
5.1.4. Dictionary A dictionary stores its entries annoyingly difficult to fit the tr command inside the
as shell variables whose names are constructed on- function itself.
the-fly from the words being defined. The command
(We confess to having resorted to occasional
$ send $DICTIONARY define and dumb non-standard shell extensions to avoid other lengthy
turns into the assignment circumlocutions, particularly echo -e which interprets
many of the usual shell escape characters like ‘\n’,
def_and=dumb
and typeset, All these shell scripts run under bash, a
In a better world, the shell might have arrays publicly available POSIX-conforming shell, and the
(indeed, the Korn shell does), but POSIX shells aren’t extensions are those provided by bash. Other POSIX
required to have them, and this work-around is good shells provide analogous extensions.)
enough for our example. A more sophisticated infect would go out and
hunt for other objects to infect, A more sophisticated
5.2. ... then getting smaller. create routine would permit multi-line messages.

Exploiting the ability of objects to learn new

methods at run-time, we can also create a simpler but 5.3. Summary Neither of these applications is
more tantalizing application. The code shown in fig- particularly long (or useful), but each illustrates the
ure 9 shows a method that sends itself to another capability and extensibility of this relatively simple
object: a virus. system, and the power and flexibility of the shell as a
programming language.
As a parting note, we observe that, the two
$ cat oneline applications can be used in consort: despite its sim-
# put everything on one line plicity, limitations, and implementation dependen-
cies, the virus shown above can be used to infect the
tr -s ’ \n\t’ ’[ *]’ Turing machine described above to give it a cold in
$ infect() its nodes.
> {
> send $1 \"$(typeset -f infect|oneline)\"
> } 6. send Paper exit
$ new null X This is hardly a complete system. On the other hand,
$ infect X it’s so simple that an average undergraduate who’s
$ send X typeset -f infect already familiar with UNIX at the shell level should
infect () be able to play with objects without first having to
wrap his mind around a conventional OOPS like C++ inheritance in C++,’’ Computing Systems, Vol 4(1),
or Smalltalk. A really good undergraduate should be pp. 69-82 (1991).
able to enhance it in interesting ways without a
course in compiler theory. I’ve suggested several [Johnson94] Steve Johnson, ‘‘Objecting to Objects’’
such enhancements in this paper. USENIX Winter Conference Invited Talks Submitted
What’s more, even though the exercise seems Notes, San Francisco, January 1994, pp. 41-61.
akin to making a sow’s ear out of a silk purse, it illus-
trates that the shell has more power than many people [King89] Roger King, ‘‘My Cat is Object-Oriented,’’
give it credit for. That said, I’ll raise anew a question in Object-Oriented Languages, Applications, and
posed by Steve Johnson at the Winter ’94 USENIX Databases, W. Kim & F. Lochovsky, eds., Addison-
conference: ‘‘Will object-oriented programming Wesley, New York. (1989).
replace the shell?’’ Johnson intended the question to
be rhetorical, but I harbor the suspicion that object- [Manna78] Zohar Manna, Mathematical Theory of
oriented shells, and other shells that break from the Computation, McGraw-Hill, New York. pp. 22-23
conventional-programming-language model, are (1978).
fruitful areas of research [Budd89]. Mashey showed
that creating a shell that was a real programming lan- [Mashey76] J. R. Mashey, ‘‘Using a command lan-
guage was exactly the right idea, and that people guage as a high-level programming language.’’ Pro-
would use a well-designed shell early and often. ceedings of the Second International Conference on
[Mashey76]. Given that, I’m surprised that nearly all Software Engineering, San Francisco, California. pp.
widely available shells today still use C, ALGOL, or 177-181 (October 1976).
pocket-teller machines as their models.
[Sessions93] Roger Sessions, ‘‘An Introduction to
(A notable exception is Doug Gwyn’s ‘‘Adven- Object-Oriented Programming and C++’’ USENIX
ture Shell.’’ Though not a wild success as a program- Summer Conference Invited Talks Submitted Notes,
mer ’s shell, it has spawned, after a trip through a Cincinnati, June 1993, pp. 29-38.
maze of twisty passages, the development of MOOs.)
Personally, I’ve long wanted to run ‘‘the
Biography
spread-shell’’ but I haven’t any idea what such a
thing would do. If you write one, please send it to Jeffrey S. Haemer is an independent consultant in
me. Boulder, Colorado. He works, writes, and speaks on
the interrelated topics of internationalization, POSIX,
open systems, software portability, and porting. Dr.
Acknowledgements Haemer has given UNIX programming tutorials since
My thanks to Dave Taenzer for patient explanations 1988 and is a frequently featured speaker at such
about objects, Jim Oldroyd and Doug Pintar for well-attended industry forums as Expo Kuwait,
humorous discussions about object-oriented applica- USENIX, and the Romanian Open Systems Exposi-
tions, Dick Dunn for working me into a lather about tion. He currently serves as the USENIX organiza-
them, and Rob Pike for an apposite quote. Thanks tional representative to the POSIX effort.
also to Mike Karels for fixing FIFOs in BSDI on the
spot at a POSIX meeting.
Appendix A: A Turing Machine

References
# turing machine
[Budd89] Tim Budd. ‘‘The design of an object- # recognizes aˆn bˆn
oriented command interpreter,’’ Software Practice
and Experience, 19(1), pp. 35-51 (January 1989). MACHINE=$O_NAME
TAPE=${MACHINE}_T
[Brooks75] Fredrick P. Brooks, Jr.. The Mythical export MACHINE TAPE
Man-Month: Essays on Software Engineering, Addi-
son Wesley, Reading, Massachusetts. pp. 93-94 destroy() {
(1975). #debug destroy $*
_destroy $TAPE s1 s2 s3 s4 s5
[Cargill91] T. A. Cargill, ‘‘The Case against multiple exit
} left() {
if test $n -le 1
accept() { then
echo ACCEPT! echo HALT
destroy return 1
} else
let n=n-1
reject() { return 0
echo REJECT! fi
destroy }
}
load() {
new tape $TAPE S=$1
new node s1 s2 s3 s4 s5 let n=1
return 0
send $TAPE load aabb }

# Hard-wire the nodes. print() {

# It’d be nicer to have this echo $S
# load from a file. let j=n
while let j=j-1
send s1 transition a A:right:s2 do
send s1 transition _ X:right:accept echo -n ’ ’
done
send s2 transition B B:right:s2 echo ’ˆ’
send s2 transition a a:right:s2 return 0
send s2 transition b B:left:s3 }

send s3 transition B B:left:s3 Write() {

send s3 transition a a:left:s4 let left_neighbor=n-1
send s3 transition A A:right:s5 let right_neighbor=n+1
left=$(echo $S |
send s4 transition a a:left:s4 cut -c -$left_neighbor)
send s4 transition A A:right:s1 right=$(echo $S |
cut -c $right_neighbor-)
send s5 transition B B:right:s5 S=${left}$1${right}
send s5 transition _ X:right:accept return 0
}
send -d s1 goto
Read() {
Figure A1. Turing Machine if test $n -gt ${#S}
then
echo ’_’ > $O_OUT
# Turing machine tape else
echo $S |
unset S cut -c $n >$O_OUT
typeset -i n fi
typeset -i j return 0
}
right() {
let n=n+1 Figure A2. Turing Machine Tape
return 0
}
# Turing machine node
XITIONS=dict_$O_NAME return 0
new dict $XITIONS }

transition() { define() {
send $XITIONS define $* eval def_$1="$2"
return 0 return 0
} }

destroy() { lookup() {
send -d $XITIONS destroy $* eval echo $"def_$1"
_destroy $* return 0
} }

goto() { Figure A4. Simple Dictionary

SYMBOL=$(send $TAPE Read)
ACTION=$(
send $XITIONS lookup $SYMBOL
)

debug $SYMBOL, $ACTION

if test -z "$ACTION"
then
send -d $MACHINE reject
return 0
fi

OUT_CHAR=$(echo $ACTION |
cut -f 1 -d:)
DIRECTION=$(echo $ACTION |
cut -f 2 -d:)
NEXT_STATE=$(echo $ACTION |
cut -f 3 -d:)

if test $NEXT_STATE = "accept"

then
send -d $MACHINE accept
return 0
fi

send $TAPE Write $OUT_CHAR

send $TAPE $DIRECTION

send -d $NEXT_STATE goto

return 0
}

Figure A3. Turing Machine Node

# Small dictionary

dictionary() {
set | sed -n ’s/ˆdef_//p’