The Command Language Interpreter

A Shell for a Capability System

This is not a particular design but merely some historical notes and design principles that bear on the issue of a command line interpreter, or shell, for a capability system.

Keykos

Keykos has two rudimentary shells called a “command line interpreter” (CLI). I record some of the properties of that system, but do not advocate them all. Here are some older speculations on CLIs.

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. Command line syntax includes simple notation including slashes to navigate thru directories of directories. 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:

The Unix directory entry is for a file, or at least something that has been warped to be accessed as a file. The Keykos directory is always a capability.
A file lasts in Unix as long as there is some file directory entry referring to it. An object in Keykos lasts until it is instructed to destroy itself or until the pages and nodes from which it is built are reclaimed by someone with authority to reclaim the space. There may be directory entries that access departed objects and more importantly there may be objects with no directory entries.
Unix directories form a tree. In Keykos directory trees are common but other shapes are possible too. There is no root!!

There is a widely available capability to which one can pass a directory which conventionally includes a space bank and the meter. The result is a new user account which that can be added to the list of accounts that the receptionist (network responder to new circuits) recognizes by user-name and password. Typically bank and meter are each keys to new resource objects and service keys to these are held by whoever created the user account.

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.

Here I consider languages for casual Keykos programming.