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 (called ` ' by C shell) 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)
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.
A method for specifying default global parameters involves 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,
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; ... ;
is executed, env points at an array of strings of the form (parameter name=parameter value).
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
The command: setenv p
defines a new global parameter p, which is inherited by all processes started by the shell (and can be changed like other parameters), and the command setenv
prints all the global parameters and their values.
Unix allows local parameters to defined, changed, and examined via the set command. The command: set q
defines a new local parameter q, the command set q=5
gives it the value 5, and the command set
prints all the current local parameters and their values.
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
History
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
which says repeat the last command starting with a `v', and the command vi !$
which says use the previous operand. This history mechanism uses the principle of locality applied to user activity. In a phase, a user is interested in a small number of commands and operands. The C shell allows the user to specify the size of this ``working set'', that is, the number of previous commands it remembers at one time.
Studies have shown that the working set of a user does not change much over time.
Bala Krishnamurthy at Purdue investigates command usage among a variety of users - faculty,
industry, research, secretary and student -
found that the average number of comamnds executed over 85
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.
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
copies all C source files (ending with the suffix `.c') to directory "newdir".
Command Procedure
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
may be stored in a command script called `wg'. The `$1' stands for the 1st argument of the command script. Later the command script may be invoked as: wg fred
which is equivalent to who | grep fred
Control constructs and command procedures give the user a powerful facility
to program a sequence of actions.