The shell has special access to a directory that is usually the personal name space of some user. User’s are typically programmers. The directory is merely an efficient mutable map from strings to capabilities. The Keykos record collection serves as a directory. The shell is intermittently attached to a terminal via communication and authentication systems. The shell persists with state when no terminal is attached. The shell obeys commands from the terminal effectively giving the person at the terminal all of the authority conveyed by the capabilities in the directory to which the shell has special access.
This is very much like the Unix shell except that a Unix shell conveys the authority associated with user and group IDs that are part of the process in which the shell runs. Access to the Unix user’s directory is part of this authority.
Contrasting the Unix and Keykos directories is instructive:
Personal directories of programmers are born with a RO capability to a directory of infrastructure objects and general programming tools. There may be a capability to a shared mutable directory whereby different users can arrange to pass capabilities among themselves. Some installations may limit such function. Some may provide authenticated connections between users. Some systems may arrange for audited capabilities between users.
As in the Unix shells there are a few commands built into the shell but most functions are achieved by the user by invoking capabilities from his directory. The simple command system required the user to descend to Keykos message level to invoke an object to which he held a key.
The upshot of this design, as in Unix, is that a shell is an avatar of a person, wielding a well defined set of authorities, just those indeed conveyed by the capabilities in his directory. This merely results in a program with the volition of a person. As Keykos does not try to reason about programs from examining them in order to trust them, it need not make a special case of a shell.