Pathnames are understood to exist in the file system space visible from Inferno. The root of this space when viewed from the host operating system is the Inferno installation directory, sometimes called the Inferno root directory. Unless otherwise enabled, the result of changes made by Inferno programs to files in the file system space is generally restricted to this portion of the host file system.
While this interface is used to provide programs with access to conventional disk-based filestore, it is also used to control devices and user level programs mounted in a process's name space. Once a program or a device has been attached to a process's name space, the program or device interprets any access to the attachment point; it can synthesise on demand the names of new files or directories, create their contents on the fly as the process reads from them, and interpret written data as commands or data as appropriate (See bind(1) and sys-bind(2)).
Each new Inferno process inherits its parent's name space, but it can divorce its own name space from that of its parent (see sys-pctl(2)), giving programs the capability to attach resources to their own name space without making them globally visible. This per-process name space is potent but potentially confusing, so, to help programs that might be confused, namespace(4) gives some conventions that should be adhered to if programs are to work properly. (That page also gives a general overview of the Inferno source tree.)
Superficially, the Inferno shell sh(1) looks and behaves much like its Plan 9 or Unix contemporaries but, at heart, it is quite different. The shell takes advantage of the dynamic module loading services that Inferno provides to allow it to be dynamically extended in appropriate and interesting ways. For example, by loading the sh-tk(1) builtin module, a shell script can provide all the programming logic required to manage a Tk window with full Tk functionality in, surprisingly, few lines of code; by loading the sh-file2chan(1) builtin module, a shell script can create a file in the name space whose properties are completely under the control of the script.
The Inferno window manager wm(1) allows the user to manage the order and position of a dynamic collection of application windows in which to perform various tasks. Acme(1) is targeted at programmers. It is an editor, a shell and window system all rolled into one, which through thoughtful and consistent application of simple principles results in a rich and productive programming environment with a user interface that feels right. Acme requires a three-button mouse and attaches distinct functions to the three mouse buttons and, indeed, to chords of buttons to maximise the productivity of the programmer's mouse. For more details of the Acme user interface see the paper "Acme: A User Interface for Programmers" in Volume 2.
Limbo programs are compiled with limbo(1). This compiles Limbo source into a machine-independent format (Dis) for execution by the Inferno Dis virtual machine. The virtual machine is designed to provide safe execution of programs even on machines without memory protection. Debugging is made straightforward by use of either stack(1) , to display the execution stack of a process or, if a finer inspection is required, deb(1), a novel window based debugger that allows the user to identify the exact location of problems, set break points and walk the data structures of any module loaded by the program. See "Program Development in Inferno" in Volume 2 for details on how to use the development tools that Inferno provides.
Section (1) (this section) for the commonly-used commands. Section (2) for Limbo modules, including Inferno's system calls. Section (3) for kernel devices (accessed by `bind'). Section (4) for file services (accessed by `mount'). Section (5) for the Styx file service protocol. Section (6) for file formats and system conventions. Section (7) for databases and database access modules. Section (8) for administrative modules and system services. Section (9) for the reference for Inferno's Tk variant, Limbo/Tk. Section (10) for the build environment and device driver implementation.
Volume 2 contains papers and other documentation about Inferno.
The back of this volume contains a permuted index.
| INTRO(1 ) | Rev: Tue Mar 31 02:42:38 GMT 2015 |