Parameters

A process may define several parameters that allow specification of options. Some of these are local, they are associated with a program and apply to all execution instances of it. An example of a local parameter is the `-l' parameter defined by the `ls' program. Others are global and are defined for all processes. An example is the Unix home directory. Any process that inputs file names may define this parameter. (We shall, in this discussion, ignore non-local parameters that are non-global. An example of such a parameter may be the `suppress warning' parameter shared by all compilers. We shall treat them as global parameters.)

A process may be associated with a large number of parameters. Therefore it is important that default mechanisms be provided to relieve the user from specifying all the parameters of a process. One popular mechanism is for a process to receive some parameters from an initialization file associated with its program. For instance the C shell program is associated with the `.cshrc' file and the mail program with the `.mailrc' file. Initialization files allow a user to specify parameter values once for each program instead of once for each process. They may be used to specify default settings for both local parameters and global ones. An initialization file may be considered a mechanism for supporting IS-A or type inheritance: it is associated with a program (class) and each instance of that program (i.e. each process that executes that program) reads the file and thus essentially inherits the parameters.

A method for specifying default global parameters involves IS-PART-OF or structure inheritance, wherein a child process inherits the global parameters of its parent, which can later be overriden. These parameters may be stored in the process table entry of a process, and the kernel, when it starts the process, makes a copy of the parent process' parameters. Alternatively, a process, (in particular a command interpreter) when it starts another, may tell the kernel the value of global parameters. These may then be copied in a well known location in the process. Unix supports the second method. In Unix, the set of global parameters and their values are called a process' environment. The exec call can take as an argument the desired environment. Unix also supports automatic copying of global parameters from a well known location in the parent process to a well know location in a child process, when the environment of the child process is not explicitly specified.

How does a process receive its inherited global parameters? In Unix, when a C program of the form:

main (argc, argv, env) 
int argc;
char **argv, **env;
{ ... };

So far we have seen how default parameters of a process are specified. How does a user change these default values? The answer depends on the process. The Unix C shell illustrates one approach. It allows global (environment) parameters to be changed via the setenv call. Thus to change the home directory, a user can execute the command:

setenv HOME /usr/joe

setenv p

setenv

Unix allows local parameters to defined, changed, and examined via the set command. The command:

set q

set q=5

set

What does it mean to let the user define a new parameter (which we said defined an option), if the shell does not know about this parameter and thus cannot use its value? If the parameter is an environment parameter, then even if the shell does not know about it, some other process started by the shell may be able to use its value. Moreover, the local and environment parameters defined by the shell also serve as shell variables, whose values can be used in the command line. A user thus create a new variable and change or use its value later, as shown below:

set d=/usr/joe/242/test.c
cc $d
ls $d
lpr $d

A command interpreter may allow a user to examine previous commands and allow them to be resubmitted with changes. For instance the C shell allows commands of the form:

!v

vi !$

Studies have shown that the working set of a user does not change much over time. Bala Krishnamurthy at Purdue investigated command usage among a variety of users - faculty, industry, research, secretary and student - and found that the average number of commands executed over 85 percent of the time was 15. The most frequently used commands for faculty were ls, vi, cd, set, more, stty, echo, pg, fg, logout, mail, ps, rm, pwd, date, tset, jobs, hostname, dirs. For other classes of users, the set was not very different. This is a strong argument for Mac-style permanent menu bar containing these often used commands.

Control Flow

A command interpreter may provide constructs for control flow. For instance, the Unix C shell allows specification of the kind:

foreach i (*.c)
	cp $i newdir
end

A sequence of commands may be stored permanently in a file called a command script or command procedure, which may later be executed to invoke these commands. For instance the command:

who | grep $1

wg fred

who | grep fred

Notice the similarity between some of the constructs such as the foreach provided by command languages and those provided by programming languages.

Given this similarity, an interesting issue, we will not study here, is whether we can support a unified command/programming language?