Purchase  Copyright © 2002 Paul Sheer. Click here for copying permissions.  Home 

next up previous contents
Next: 10. Mail Up: rute Previous: 8. Streams and sed   Contents


9. Processes and Environment Variables

From this chapter you will get an idea about what is happening under the hood of your UNIX system, but go have some coffee first.

9.1 Introduction

On UNIX, when you run a program (like any of the shell commands you have been using), the actual computer instructions are read from a file on disk from one of the bin/ directories and placed in RAM. The program is then executed in memory and becomes a process. A process is some command/program/shell-script that is being run (or executed) in memory. When the process has finished running, it is removed from memory. There are usually about 50 processes running simultaneously at any one time on a system with one person logged in. The CPU hops between each of them to give a share of its execution time. [Time given to carry out the instructions of a particular program. Note this is in contrast to Windows or DOS where the program itself has to allow the others a share of the CPU: under UNIX, the process has no say in the matter. ]Each process is given a process number called the PID (process ID). Besides the memory actually occupied by the executable, the process itself seizes additional memory for its operations.

In the same way that a file is owned by a particular user and group, a process also has an owner--usually the person who ran the program. Whenever a process tries to access a file, its ownership is compared to that of the file to decide if the access is permissible. Because all devices are files, the only way a process can do anything is through a file, and hence file permission restrictions are the only kind of restrictions ever needed on UNIX. [There are some exceptions to this.] This is how UNIX access control and security works.

The center of this operation is called the UNIX kernel. The kernel is what actually does the hardware access, execution, allocation of process IDs, sharing of CPU time, and ownership management.

9.2 ps -- List Running Processes

Log in on a terminal and type the command ps. You should get some output like:

5995   2 S    0:00 /bin/login -- myname
5999   2 S    0:00 -bash
6030   2 R    0:00 ps

ps with no options shows three processes to be running. These are the only three processes visible to you as a user, although there are other system processes not belonging to you. The first process was the program that logged you in by displaying the login prompt and requesting a password. It then ran a second process call bash, the Bourne Again shell [The Bourne shell was the original UNIX shell] where you have been typing commands. Finally, you ran ps, which must have found itself when it checked which processes were running, but then exited immediately afterward.

9.3 Controlling Jobs

The shell has many facilities for controlling and executing processes--this is called job control. Create a small script called proc.sh:

echo "proc.sh: is running"
sleep 1000

Run the script with chmod 0755 proc.sh and then ./proc.sh. The shell blocks, waiting for the process to exit. Now press ^Z. This will cause the process to stop (that is, pause but not terminate). Now do a ps again. You will see your script listed. However, it is not presently running because it is in the condition of being stopped. Type bg (for background). The script will now be ``unstopped'' and run in the background. You can now try to run other processes in the meantime. Type fg, and the script returns to the foreground. You can then type ^C to interrupt the process.

9.4 Creating Background Processes

Create a program that does something a little more interesting:

echo "proc.sh: is running"
while true ; do
        echo -e '\a'
        sleep 2

Now perform the ^Z, bg, fg, and ^C operations from before. To put a process immediately into the background, you can use:

./proc.sh &

The JOB CONTROL section of the bash man page ( bash(1)) looks like this(footnote follows) [Thanks to Brian Fox and Chet Ramey for this material.]: (the footnotes are mine)


Job control refers to the ability to selectively stop (suspend) the execution of processes and continue (resume) their execution at a later point. A user typically employs this facility via an interactive interface supplied jointly by the system's terminal driver and bash.

The shell associates a job with each pipeline. [What does this mean? It means that each time you execute something in the background, it gets its own unique number, called the job number.]It keeps a table of currently executing jobs, which may be listed with the jobs command. When bash starts a job asynchronously (in the background), it prints a line that looks like:

     [1] 25647

indicating that this job is job number 1 and that the process ID of the last process in the pipeline associated with this job is 25647. All of the processes in a single pipeline are members of the same job. Bash uses the job abstraction as the basis for job control.

To facilitate the implementation of the user interface to job control, the system maintains the notion of a current terminal process group ID. Members of this process group (processes whose process group ID is equal to the current terminal process group ID) receive keyboard-generated signals such as SIGINT. These processes are said to be in the foreground. Background processes are those whose process group ID differs from the terminal's; such processes are immune to keyboard-generated signals. Only foreground processes are allowed to read from or write to the terminal. Background processes which attempt to read from (write to) the terminal are sent a SIGTTIN (SIGTTOU) signal by the terminal driver, which, unless caught, suspends the process.

If the operating system on which bash is running supports job control, bash allows you to use it. Typing the suspend character (typically ^Z, Control-Z) while a process is running causes that process to be stopped and returns you to bash. Typing the delayed suspend character (typically ^Y, Control-Y) causes the process to be stopped when it attempts to read input from the terminal, and control to be returned to bash. You may then manipulate the state of this job, using the bg command to continue it in the background, the fg command to continue it in the foreground, or the kill command to kill it. A ^Z takes effect immediately, and has the additional side effect of causing pending output and typeahead to be discarded.

There are a number of ways to refer to a job in the shell. The character % introduces a job name. Job number n may be referred to as %n. A job may also be referred to using a prefix of the name used to start it, or using a substring that appears in its command line. For example, %ce refers to a stopped ce job. If a prefix matches more than one job, bash reports an error. Using %?ce, on the other hand, refers to any job containing the string ce in its command line. If the substring matches more than one job, bash reports an error. The symbols %% and %+ refer to the shell's notion of the current job, which is the last job stopped while it was in the foreground. The previous job may be referenced using %-. In output pertaining to jobs (e.g., the output of the jobs command), the current job is always flagged with a +, and the previous job with a -.

Simply naming a job can be used to bring it into the foreground: %1 is a synonym for ``fg %1'', bringing job 1 from the background into the foreground. Similarly, ``%1 &'' resumes job 1 in the background, equivalent to ``bg %1''.

The shell learns immediately whenever a job changes state. Normally, bash waits until it is about to print a prompt before reporting changes in a job's status so as to not interrupt any other output. If the -b option to the set builtin command is set, bash reports such changes immediately. (See also the description of notify variable under Shell Variables above.)

If you attempt to exit bash while jobs are stopped, the shell prints a message warning you. You may then use the jobs command to inspect their status. If you do this, or try to exit again immediately, you are not warned again, and the stopped jobs are terminated.

9.5 killing a Process, Sending Signals

To terminate a process, use the kill command:

kill <PID>

The kill command actually sends a termination signal to the process. The sending of a signal simply means that the process is asked to execute one of 30 predefined functions. In some cases, developers would not have bothered to define a function for a particular signal number (called catching the signal); in which case the kernel will substitute the default behavior for that signal. The default behavior for a signal is usually to ignore the signal, to stop the process, or to terminate the process. The default behavior for the termination signal is to terminate the process.

To send a specific signal to a process, you can name the signal on the command-line or use its numerical equivalent:

kill -SIGTERM 12345


kill -15 12345

which is the signal that kill normally sends when none is specified on the command-line.

To unconditionally terminate a process:

kill -SIGKILL 12345


kill -9 12345

which should only be used as a last resort. Processes are prohibited from ever catching the SIGKILL signal.

It is cumbersome to have to constantly look up the PID of a process. Hence the GNU utilities have a command, killall, that sends a signal to all processes of the same name:

killall -<signal> <process_name>

This command is useful when you are sure that there is only one of a process running, either because no one else is logged in on the system or because you are not logged in as superuser. Note that on other UNIX systems, the killall command kills all the processes that you are allowed to kill. If you are root, this action would crash the machine.

9.6 List of Common Signals

The full list of signals can be gotten from signal(7), and in the file /usr/include/asm/signal.h.

Hang up. If the terminal becomes disconnected from a process, this signal is sent automatically to the process. Sending a process this signal often causes it to reread its configuration files, so it is useful instead of restarting the process. Always check the man page to see if a process has this behavior.
Interrupt from keyboard. Issued if you press ^C.
Quit from keyboard. Issued if you press ^D.
Floating point exception. Issued automatically to a program performing some kind of illegal mathematical operation.
Kill signal. This is one of the signals that can never be caught by a process. If a process gets this signal it must quit immediately and will not perform any clean-up operations (like closing files or removing temporary files). You can send a process a SIGKILL signal if there is no other means of destroying it.
SIGUSR1 (10), SIGUSR2 (12)
User signal. These signals are available to developers when they need extra functionality. For example, some processes begin logging debug messages when you send them SIGUSR1.
Segmentation violation. Issued automatically when a process tries to access memory outside of its allowable address space, equivalent to a Fatal Exception or General Protection Fault under Windows. Note that programs with bugs or programs in the process of being developed often get these signals. A program receiving a SIGSEGV, however, can never cause the rest of the system to be compromised. If the kernel itself were to receive such an error, it would cause the system to come down, but such is extremely rare.
Pipe died. A program was writing to a pipe, the other end of which is no longer available.
Terminate. Cause the program to quit gracefully
Child terminate. Sent to a parent process every time one of its spawned processes dies.

9.7 Niceness of Processes, Scheduling Priority

All processes are allocated execution time by the kernel. If all processes were allocated the same amount of time, performance would obviously get worse as the number of processes increased. The kernel uses heuristics [Sets of rules.] to guess how much time each process should be allocated. The kernel tries to be fair--two users competing for CPU usage should both get the same amount.

Most processes spend their time waiting for either a key press, some network input, some device to send data, or some time to elapse. They hence do not consume CPU.

On the other hand, when more than one process runs flat out, it can be difficult for the kernel to decide if it should be given greater priority than another process. What if a process is doing some operation more important than another process? How does the kernel tell? The answer is the UNIX feature of scheduling priority or niceness. Scheduling priority ranges from +20 to -20. You can set a process's niceness with the renice command.

renice <priority> <pid>
renice <priority> -u <user>
renice <priority> -g <group>

A typical example is the SETI program. [SETI stands for Search for Extraterrestrial Intelligence. SETI is an initiative funded by various obscure sources to scan the skies for radio signals from other civilizations. The data that SETI gathers has to be intensively processed. SETI distributes part of that data to anyone who wants to run a seti program in the background. This puts the idle time of millions of machines to ``good'' use. There is even a SETI screen-saver that has become quite popular. Unfortunately for the colleague in my office, he runs seti at -19 instead of +19 scheduling priority, so nothing on his machine works right. On the other hand, I have inside information that the millions of other civilizations in this galaxy and others are probably not using radio signals to communicate at all :-)] Set its priority to +19 with:

renice +19 <pid>

to make it disrupt your machine as little as possible.

Note that nice values have the reverse meaning that you would expect: +19 means a process that eats little CPU, while -19 is a process that eats lots. Only superuser can set processes to negative nice values.

Mostly, multimedia applications and some device utilities are the only processes that need negative renicing, and most of these will have their own command-line options to set the nice value. See, for example, cdrecord(1) and mikmod(1) -- a negative nice value will prevent skips in your playback. [LINUX will soon have so called real time process scheduling. This is a kernel feature that reduces scheduling latency (the gaps between CPU execution time of a process, as well as the time it takes for a process to wake). There are already some kernel patches that accomplish this goal.]

Also useful are the -u and -g options, which set the priority of all the processes that a user or group owns.

Further, we have the nice command, which starts a program under a defined niceness relative to the current nice value of the present user. For example,

nice +<priority> <pid>
nice -<priority> <pid>

Finally, the snice command can both display and set the current niceness. This command doesn't seem to work on my machine.

snice -v <pid>

9.8 Process CPU/Memory Consumption, top

The top command sorts all processes by their CPU and memory consumption and displays the top twenty or so in a table. Use top whenever you want to see what's hogging your system. top -q -d 2 is useful for scheduling the top command itself to a high priority, so that it is sure to refresh its listing without lag. top -n 1 -b > top.txt lists all processes, and top -n 1 -b -p <pid> prints information on one process.

top has some useful interactive responses to key presses:

Shows a list of displayed fields that you can alter interactively. By default the only fields shown are USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND which is usually what you are most interested in. (The field meanings are given below.)

Renices a process.

Kills a process.

The top man page describes the field meanings. Some of these are confusing and assume knowledge of the internals of C programs. The main question people ask is: How much memory is a process using? The answer is given by the RSS field, which stands for Resident Set Size. RSS means the amount of RAM that a process consumes alone. The following examples show totals for all processes running on my system (which had 65536 kilobytes of RAM at the time). They represent the total of the SIZE, RSS, and SHARE fields, respectively.

echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \
    awk '{print "+" $5}' | sed -e 's/M/\\*1024/'` | bc
echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \
    awk '{print "+" $6}' | sed -e 's/M/\\*1024/'` | bc
echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \
    awk '{print "+" $7}' | sed -e 's/M/\\*1024/'` | bc

The SIZE represents the total memory usage of a process. RSS is the same, but excludes memory not needing actual RAM (this would be memory swapped to the swap partition). SHARE is the amount shared between processes.

Other fields are described by the top man page (quoted verbatim) as follows:

This line displays the time the system has been up, and the three load averages for the system. The load averages are the average number of processes ready to run during the last 1, 5 and 15 minutes. This line is just like the output of uptime(1). The uptime display may be toggled by the interactive l command.

The total number of processes running at the time of the last update. This is also broken down into the number of tasks which are running, sleeping, stopped, or undead. The processes and states display may be toggled by the t interactive command.

CPU states
Shows the percentage of CPU time in user mode, system mode, niced tasks, and idle. (Niced tasks are only those whose nice value is negative.) Time spent in niced tasks will also be counted in system and user time, so the total will be more than 100%. The processes and states display may be toggled by the t interactive command.

Statistics on memory usage, including total available memory, free memory, used memory, shared memory, and memory used for buffers. The display of memory information may be toggled by the m interactive command.

Statistics on swap space, including total swap space, available swap space, and used swap space. This and Mem are just like the output of free(1).

The process ID of each task.

The parent process ID of each task.

The user ID of the task's owner.

The user name of the task's owner.

The priority of the task.

The nice value of the task. Negative nice values are higher priority.

The size of the task's code plus data plus stack space, in kilobytes, is shown here.

The code size of the task. This gives strange values for kernel processes and is broken for ELF processes.

Data + Stack size. This is broken for ELF processes.

Text resident size.

Size of the swapped out part of the task.

Size of pages marked dirty.

Size of use library pages. This does not work for ELF processes.

The total amount of physical memory used by the task, in kilobytes, is shown here. For ELF processes used library pages are counted here, for a.out processes not.

The amount of shared memory used by the task is shown in this column.

The state of the task is shown here. The state is either S for sleeping, D for uninterruptible sleep, R for running, Z for zombies, or T for stopped or traced. These states are modified by a trailing < for a process with negative nice value, N for a process with positive nice value, W for a swapped out process (this does not work correctly for kernel processes).

depending on the availability of either /boot/psdatabase or the kernel link map /boot/System.map this shows the address or the name of the kernel function the task currently is sleeping in.

Total CPU time the task has used since it started. If cumulative mode is on, this also includes the CPU time used by the process's children which have died. You can set cumulative mode with the S command line option or toggle it with the interactive command S. The header line will then be changed to CTIME.

The task's share of the CPU time since the last screen update, expressed as a percentage of total CPU time per processor.

The task's share of the physical memory.

The task's command name, which will be truncated if it is too long to be displayed on one line. Tasks in memory will have a full command line, but swapped-out tasks will only have the name of the program in parentheses (for example, "(getty)").

9.9 Environments of Processes

Each process that runs does so with the knowledge of several var =value text pairs. All this means is that a process can look up the value of some variable that it may have inherited from its parent process. The complete list of these text pairs is called the environment of the process, and each var is called an environment variable. Each process has its own environment, which is copied from the parent process's environment.

After you have logged in and have a shell prompt, the process you are using (the shell itself) is just like any other process with an environment with environment variables. To get a complete list of these variables, just type:


This command is useful for finding the value of an environment variable whose name you are unsure of:

set | grep <regexp>

Try set | grep PATH to see the PATH environment variable discussed previously.

The purpose of an environment is just to have an alternative way of passing parameters to a program (in addition to command-line arguments). The difference is that an environment is inherited from one process to the next: for example, a shell might have a certain variable set and may run a file manager, which may run a word processor. The word processor inherited its environment from file manager which inherited its environment from the shell. If you had set an environment variable PRINTER within the shell, it would have been inherited all the way to the word processor, thus eliminating the need to separately configure which printer the word processor should use.


X="Hi there"
echo $X

You have set a variable. But now run


You have now run a new process which is a child of the process you were just in. Type

echo $X

You will see that X is not set. The reason is that the variable was not exported as an environment variable and hence was not inherited. Now type


which breaks to the parent process. Then

export X
echo $X

You will see that the new bash now knows about X.

Above we are setting an arbitrary variable for our own use. bash (and many other programs) automatically set many of their own environment variables. The bash man page lists these (when it talks about unsetting a variable, it means using the command unset <variable>). You may not understand some of these at the moment, but they are included here as a complete reference for later.

The following is quoted verbatim from the bash man page. You will see that some variables are of the type that provide special information and are read but never never set, whereas other variables configure behavioral features of the shell (or other programs) and can be set at any time(footnote follows) [Thanks to Brian Fox and Chet Ramey for this material.].

Shell Variables

The following variables are set by the shell:

The process ID of the shell's parent.
The current working directory as set by the cd command.
The previous working directory as set by the cd command.
Set to the line of input read by the read builtin command when no arguments are supplied.
Expands to the user ID of the current user, initialized at shell startup.
Expands to the effective user ID of the current user, initialized at shell startup.
Expands to the full pathname used to invoke this instance of bash.
Expands to the version number of this instance of bash.
Incremented by one each time an instance of bash is started.

Each time this parameter is referenced, a random integer is generated. The sequence of random numbers may be initialized by assigning a value to RANDOM. If RANDOM is unset, it loses its special properties, even if it is subsequently reset.

Each time this parameter is referenced, the number of seconds since shell invocation is returned. If a value is assigned to SECONDS. the value returned upon subsequent references is the number of seconds since the assignment plus the value assigned. If SECONDS is unset, it loses its special properties, even if it is subsequently reset.

Each time this parameter is referenced, the shell substitutes a decimal number representing the current sequential line number (starting with 1) within a script or function. When not in a script or function, the value substituted is not guaranteed to be meaningful. When in a function, the value is not the number of the source line that the command appears on (that information has been lost by the time the function is executed), but is an approximation of the number of simple commands executed in the current function. If LINENO is unset, it loses its special properties, even if it is subsequently reset.

The history number, or index in the history list, of the current command. If HISTCMD is unset, it loses its special properties, even if it is subsequently reset.

The value of the last option argument processed by the getopts builtin command (see SHELL BUILTIN COMMANDS below).

The index of the next argument to be processed by the getopts builtin command (see SHELL BUILTIN COMMANDS below).

Automatically set to a string that uniquely describes the type of machine on which bash is executing. The default is system-dependent.

Automatically set to a string that describes the operating system on which bash is executing. The default is system-dependent.

The following variables are used by the shell. In some cases, bash assigns a default value to a variable; these cases are noted below.

The Internal Field Separator that is used for word splitting after expansion and to split lines into words with the read builtin command. The default value is ``<space><tab><newline>''.
The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below). The default path is system-dependent, and is set by the administrator who installs bash. A common value is ``/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:.''.
The home directory of the current user; the default argument for the cd builtin command.
The search path for the cd command. This is a colon-separated list of directories in which the shell looks for destination directories specified by the cd command. A sample value is ``.:~:/usr''.
If this parameter is set when bash is executing a shell script, its value is interpreted as a filename containing commands to initialize the shell, as in .bashrc. The value of ENV is subjected to parameter expansion, command substitution, and arithmetic expansion before being interpreted as a pathname. PATH is not used to search for the resultant pathname.
If this parameter is set to a filename and the MAILPATH variable is not set, bash informs the user of the arrival of mail in the specified file.
Specifies how often (in seconds) bash checks for mail. The default is 60 seconds. When it is time to check for mail, the shell does so before prompting. If this variable is unset, the shell disables mail checking.
A colon-separated list of pathnames to be checked for mail. The message to be printed may be specified by separating the pathname from the message with a `?'. $_ stands for the name of the current mailfile. Example:
MAILPATH='/usr/spool/mail/bfox?"You have mail":~/shell-mail?"$_ has mail!"' Bash supplies a default value for this variable, but the location of the user mail files that it uses is system dependent (e.g., /usr/spool/mail/$USER).
If set, and a file that bash is checking for mail has been accessed since the last time it was checked, the message ``The mail in mailfile has been read'' is printed.
The value of this parameter is expanded (see PROMPTING below) and used as the primary prompt string. The default value is ``bash\$ ''.
The value of this parameter is expanded and used as the secondary prompt string. The default is ``''.
The value of this parameter is used as the prompt for the select command (see SHELL GRAMMAR above).
The value of this parameter is expanded and the value is printed before each command bash displays during an execution trace. The first character of PS4 is replicated multiple times, as necessary, to indicate multiple levels of indirection. The default is ``''.
The number of commands to remember in the command history (see HISTORY below). The default value is 500.
The name of the file in which command history is saved. (See HISTORY below.) The default value is ~/.bash_history. If unset, the command history is not saved when an interactive shell exits.
The maximum number of lines contained in the history file. When this variable is assigned a value, the history file is truncated, if necessary, to contain no more than that number of lines. The default value is 500.
If set to the value 1, bash displays error messages generated by the getopts builtin command (see SHELL BUILTIN COMMANDS below). OPTERR is initialized to 1 each time the shell is invoked or a shell script is executed.
If set, the value is executed as a command prior to issuing each primary prompt.
Controls the action of the shell on receipt of an EOF character as the sole input. If set, the value is the number of consecutive EOF characters typed as the first characters on an input line before bash exits. If the variable exists but does not have a numeric value, or has no value, the default value is 10. If it does not exist, EOF signifies the end of input to the shell. This is only in effect for interactive shells.
If set to a value greater than zero, the value is interpreted as the number of seconds to wait for input after issuing the primary prompt. Bash terminates after waiting for that number of seconds if input does not arrive.
The default editor for the fc builtin command.
A colon-separated list of suffixes to ignore when performing filename completion (see READLINE below). A filename whose suffix matches one of the entries in FIGNORE is excluded from the list of matched filenames. A sample value is ``.o:~''.
The filename for the readline startup file, overriding the default of ~/.inputrc (see READLINE below).
If set, bash reports terminated background jobs immediately, rather than waiting until before printing the next primary prompt (see also the -b option to the set builtin command).
If set to a value of ignorespace, lines which begin with a space character are not entered on the history list. If set to a value of ignoredups, lines matching the last history line are not entered. A value of ignoreboth combines the two options. If unset, or if set to any other value than those above, all lines read by the parser are saved on the history list.
If set, bash attempts to save all lines of a multiple-line command in the same history entry. This allows easy re-editing of multi-line commands.
If set, bash includes filenames beginning with a `.' in the results of pathname expansion.
If set, bash allows pathname patterns which match no files (see Pathname Expansion below) to expand to a null string, rather than themselves.
The two or three characters which control history expansion and tokenization (see HISTORY EXPANSION below). The first character is the history expansion character, that is, the character which signals the start of a history expansion, normally `!'. The second character is the quick substitution character, which is used as shorthand for re-running the previous command entered, substituting one string for another in the command. The default is `^'. The optional third character is the character which signifies that the remainder of the line is a comment, when found as the first character of a word, normally `#'. The history comment character causes history substitution to be skipped for the remaining words on the line. It does not necessarily cause the shell parser to treat the rest of the line as a comment.
If set, the shell does not follow symbolic links when executing commands that change the current working directory. It uses the physical directory structure instead. By default, bash follows the logical chain of directories when performing commands which change the current directory, such as cd. See also the description of the -P option to the set builtin ( SHELL BUILTIN COMMANDS below).
Contains the name of a file in the same format as /etc/hosts that should be read when the shell needs to complete a hostname. The file may be changed interactively; the next time hostname completion is attempted bash adds the contents of the new file to the already existing database.
If set, bash does not overwrite an existing file with the >, >&, and <> redirection operators. This variable may be overridden when creating output files by using the redirection operator >| instead of > (see also the -C option to the set builtin command).
This variable controls how the shell interacts with the user and job control. If this variable is set, single word simple commands without redirections are treated as candidates for resumption of an existing stopped job. There is no ambiguity allowed; if there is more than one job beginning with the string typed, the job most recently accessed is selected. The name of a stopped job, in this context, is the command line used to start it. If set to the value exact, the string supplied must match the name of a stopped job exactly; if set to substring, the string supplied needs to match a substring of the name of a stopped job. The substring value provides functionality analogous to the %? job id (see JOB CONTROL below). If set to any other value, the supplied string must be a prefix of a stopped job's name; this provides functionality analogous to the % job id.
If this variable exists, a non-interactive shell will not exit if it cannot execute the file specified in the exec builtin command. An interactive shell does not exit if exec fails.
If this is set, an argument to the cd builtin command that is not a directory is assumed to be the name of a variable whose value is the directory to change to.

next up previous contents
Next: 10. Mail Up: rute Previous: 8. Streams and sed   Contents