Why a Shell?

Just as a shell protects its inhabitant from the vicissitudes of the ocean, an operating system shell enables a human user to interact with an otherwise uninviting machine environment. And, just like a sea shell, an operating system shell defines an environment that governs the behavior of things executing inside. With an operating system shell, environment variables permit programs executing from a shell to share common information. A user interacts with the operating system and application software running on it via shell commands. Figure 17.1 illustrates a shell's shared environment and commands.

Figure 17.1. A shell provides a common environment for executing commands and applications.

A shell presents a minimalist user interface: only a command line. All interaction with the shell occurs via commands. When a user submits a command, the shell evaluates the entire line, starting from left to right. Some elements of that command line might refer to a shell's built-in commands, in which case the shell interprets them directly. Or, a command might be the name of an external program, in which case the shell searches for that program and requests the operating system to invoke it. The PATH shell environment variable specifies the location of that search.

Whether built-in or external, shell commands often have well-defined input and output streams. Whereas a Java object, for example, might offer various data input and output mechanisms such as method invocations, sockets, or message interfaces a shell command also has in addition standard input and standard output streams. These are standard in the sense that a shell considers them the primary mechanisms to get data in and out of a shell command. System.out and System.in are similar concepts for Java programs, in that the Java VM defines these as "standard" input and output streams to and from an object. Figure 17.2 illustrates an object executing as a shell command with standard input and standard output streams.

Figure 17.2. Shell command with standard input and output streams.

Because the shell tracks each command's standard input and output streams, it can arrange the input stream of one command to be connected to the output stream of another command. The abstraction for that connection is a pipe. A user requests that a pipe be created with the built-in shell operator |. As an example, consider a pipe between the Unix cat and grep commands. Cat concatenates a list of files and sends that output to its standard output stream. grep is a searching utility it lets you specify a pattern and search for it in a set of files you list. Suppose that you wanted to find the pattern JXTA in the file P2P_article.txt. You would pipe the output of cat to the input of grep:

 cat P2P_article.txt | grep JXTA  

Pipes can assume any length, provided that one program's input stream can process another's output stream. Pipes therefore offer a powerful way to arrange sophisticated interaction between simple programs. At the end of that chain is the shell's standard output stream. By default, that output stream is the command line.

Shells not only let you pipe one command's output into another's input, they also enable you to redirect a command's output and input in any fashion. The operators for that arbitrary input and output redirection are < and >, respectively. For instance, the > operator enables you to redirect the output from the previous command line to a file:

 cat P2P_article.txt | grep JXTA > resultfile.txt  

In his presentation at the O'Reilly conference, Bill Joy suggested that a shell's capability to combine simple commands into complex interactions would be helpful in the P2P world as well: That capability would let P2P applications remain small and simple, and users would be able to compose sophisticated P2P functionality out of those simple components. If each component does one thing, but does it well, that component can be reused as often as necessary, enabling developers to build on each others' work. Chapter 16 gives you an overview of how JXTA abstracts out components common to P2P systems, and offers reusable, programming language-neutral abstractions for those components. The JXTA Shell in this chapter is an application built on the core JXTA components, and it enables you to interact with the JXTA network in the same way a Unix shell enables you to interact with the operating system.