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.
Log in on a terminal and type the command
ps. You should get some output
like:
PID TTY STAT TIME COMMAND 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.
The shell has many facilities for controlling and executing processes--this
is called job control. Create a small script called
proc.sh:
#!/bin/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.
Create a program that does something a little more interesting:
5
#!/bin/sh echo "proc.sh: is running" while true ; do echo -e '\a' sleep 2 done
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
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.
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
or
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
or
kill -9 12345
which should only be used as a last resort. Processes are prohibited from ever catching
the
SIGKILLsignal.
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.
The full list of signals can be gotten from
signal(7), and in the
file
/usr/include/asm/signal.h.
SIGHUP (1)
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.
SIGINT (2)
Interrupt from keyboard. Issued if you press ^C.
SIGQUIT (3)
Quit from keyboard. Issued if you press ^D.
SIGFPE (8)
Floating point exception. Issued automatically to a program performing some kind of illegal mathematical operation.
SIGKILL (9)
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.
SIGSEGV (11)
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.
SIGPIPE (13)
Pipe died. A program was writing to a pipe, the other end of
which is no longer available.
SIGTERM (15)
Terminate. Cause the program to quit gracefully
SIGCHLD (17)
Child terminate. Sent to a parent process every time
one of its spawned processes dies.
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.
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.
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:
f
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.)
r
Renices a process.
k
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.
5 10
echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \ awk '{print "+" $5}' | sed -e 's/M/\\*1024/'` | bc 68016 echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \ awk '{print "+" $6}' | sed -e 's/M/\\*1024/'` | bc 58908 echo `echo '0 ' ; top -q -n 1 -b | sed -e '1,/PID *USER *PRI/D' | \ awk '{print "+" $7}' | sed -e 's/M/\\*1024/'` | bc 30184
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:
uptime
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.
processes
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.
Mem
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.
Swap
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).
PID
The process ID of each task.
PPID
The parent process ID of each task.
UID
The user ID of the task's owner.
USER
The user name of the task's owner.
PRI
The priority of the task.
NI
The nice value of the task. Negative nice values are higher priority.
SIZE
The size of the task's code plus data plus stack
space, in kilobytes, is shown here.
TSIZE
The code size of the task. This gives strange values
for kernel processes and is broken for ELF processes.
DSIZE
Data + Stack size. This is broken for ELF processes.
TRS
Text resident size.
SWAP
Size of the swapped out part of the task.
D
Size of pages marked dirty.
LIB
Size of use library pages. This does not work for ELF
processes.
RSS
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.
SHARE
The amount of shared memory used by the task is shown
in this column.
STAT
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).
WCHAN
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.
TIME
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.
%CPU
The task's share of the CPU time since the last
screen update, expressed as a percentage of total CPU
time per processor.
%MEM
The task's share of the physical memory.
COMMAND
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)").
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:
set
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.
Try
X="Hi there" echo $X
You have set a variable. But now run
bash
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
exit
which breaks to the parent process. Then
export X bash 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:
PPID
The process ID of the shell's parent.
PWD
The current working directory as set by the cd command.
OLDPWD
The previous working directory as set by the cd command.
REPLY
Set to the line of input read by the read builtin command when no arguments are supplied.
UID
Expands to the user ID of the current user, initialized at shell startup.
EUID
Expands to the effective user ID of the current user, initialized at shell startup.
BASH
Expands to the full pathname used to invoke this instance of bash.
BASH_VERSION
Expands to the version number of this instance of bash.
SHLVL
Incremented by one each time an instance of bash is started.
RANDOM
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.
SECONDS
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.
LINENO
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.
HISTCMD
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.
OPTARG
The value of the last option argument processed by
the getopts builtin command (see SHELL BUILTIN
COMMANDS below).
OPTIND
The index of the next argument to be processed by
the getopts builtin command (see SHELL BUILTIN
COMMANDS below).
HOSTTYPE
Automatically set to a string that uniquely
describes the type of machine on which bash is
executing. The default is system-dependent.
OSTYPE
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.
IFS
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>''.
PATH
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:.''.
HOME
The home directory of the current user; the default argument for the
cd builtin command.
CDPATH
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''.
ENV
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.
MAIL
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.
MAILCHECK
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.
MAILPATH
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).
MAIL_WARNING
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.
PS1
The value of this parameter is expanded (see
PROMPTING
below) and used as the primary prompt string. The default value is
``bash\$ ''.
PS2
The value of this parameter is expanded
and used as the secondary prompt string. The default is
``> ''.
PS3
The value of this parameter is used as the prompt for the
select
command (see
SHELL GRAMMAR
above).
PS4
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 ``+ ''.
HISTSIZE
The number of commands to remember in the command history (see
HISTORY
below). The default value is 500.
HISTFILE
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.
HISTFILESIZE
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.
OPTERR
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.
PROMPT_COMMAND
If set, the value is executed as a command prior to issuing each primary
prompt.
IGNOREEOF
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.
TMOUT
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.
FCEDIT
The default editor for the
fc
builtin command.
FIGNORE
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:~''.
INPUTRC
The filename for the readline startup file, overriding the default
of
~/.inputrc
(see
READLINE
below).
notify
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).
history_control
HISTCONTROL
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.
command_oriented_history
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.
glob_dot_filenames
If set,
bash
includes filenames beginning with a `.' in the results of pathname
expansion.
allow_null_glob_expansion
If set,
bash
allows pathname patterns which match no
files (see
Pathname Expansion
below)
to expand to a null string, rather than themselves.
histchars
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.
nolinks
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).
hostname_completion_file
HOSTFILE
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.
noclobber
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).
auto_resume
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.
no_exit_on_failed_exec
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.
cdable_vars
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.