This chapter looks at the shells in a little more detail. You'll start with
bash (Bourne Again Shell), the default shell used by Linux and the most popular
shell for new users. In this chapter you will learn
You will also look at the most commonly used bash commands and the
environment variables bash uses. By the end of this chapter, you should be able
to work faster and more efficiently with bash.
What is a shell, anyway? It seems to be a word used all the time in Linux,
but the exact meaning is vague for many new users (and some veterans). This
section explains exactly what a shell program is and why it is so important when
using Linux.
The shell is a program used to interface between you (the user) and Linux
(or, more accurately, between you and the Linux kernel). Figure 10.1 illustrates
the relationship between the user, the shell, and the Linux kernel. Every
command you type at a prompt on your screen is interpreted by the shell, then
passed to the Linux kernel.
Figure
10.1. The relationship between the user and the shell.
If you are familiar with MS-DOS, you will recognize this relationship as almost identical to the relationship between a DOS user and the COMMAND.COM program. The only real difference is that in the DOS world, no distinction is made between the COMMAND.COM program and DOS (or to be more accurate, the DOS kernel).
The shell is a command-language interpreter. It has its own set of built-in
shell commands. The shell can also make use of all of the Linux utilities and
application programs that are available on the system.
Whenever you enter a command it is interpreted by the Linux shell. For
example, in earlier chapters when you were introduced to the Linux file- and
directory-manipulation commands, all of the sample commands entered at the
command prompt were interpreted by whichever Linux shell you were using.
Some of the commands, such as the print working directory (pwd) command, are
built into the Linux bash shell. Other commands, such as the copy command (cp)
and the remove command (rm), are separate executable programs that exist in one
of the directories in the filesystem. As the user, you don't know (or probably
care) if the command is built into the shell or is a separate program. Figure
10.2 shows how the shell performs this command interpretation.
Figure
10.2. Command interpretation by the shell.
Figure 10.2 illustrates the steps that the shell takes to figure out what to
do with user commands. It first checks to see if the command is one of its own
built-in commands (like cd or pw. If the command is not one of these, the shell
checks to see if it is an application program. Application programs can be
utility programs that are part of Linux, such as ls and rm, or they can be
application programs that are either purchased commercially, such as xv, or
available as public domain software, such as ghostview.
The shell tries to find these application programs by looking in all of the
directories that are in your search path. The path is a list of directories
where executable programs can be found. If the command that was entered is not
an internal shell command and it is not an executable file in your path, an
error message will be displayed.
As the last step in a successful command, the shell's internal commands and
all of the application programs are eventually broken down into system calls and
passed to the Linux kernel.
Another important aspect of the shell is that it contains a very powerful
interpretive programming language. This language is similar in function to the
MS-DOS interpreted language, but is much more powerful. The shell programming
language supports most of the programming constructs found in high-level
languages, such as looping, functions, variables, and arrays.
The shell programming language is easy to learn, and once known it becomes a
very powerful programming tool. Any command that can be typed at the command
prompt can also be put into a executable shell program. This means that the
shell language can be used to simplify repetitive tasks. See Chapter 13, "Shell
Programming," for more information on shell programming.
Earlier in this chapter you learned that the shell is the main method by
which a user interacts with the Linux kernel. But how does this program get
initialized to do so? The shell is started after you successfully log into the
system, and it continues to be the main method of interaction between the user
and the kernel until you log out.
Each user on your system has a default shell. The default shell for each user
is specified in the system password file, called /etc/passwd. The system
password file contains, among other things, each person's user ID, an encrypted
copy of each user's password, and the name of the program to run immediately
after a user logs into the system. The program specified in the password file
does not have to be one of the Linux shells, but it almost always is.
Several different kinds of shells are available on Linux and UNIX systems.
The most common are the Bourne shell (called sh), the C shell (csh), and the
Korn shell (ksh). Each of these three shells has its own advantages and
disadvantages.
The Bourne shell was written by Steven Bourne. It is the original UNIX shell
and is available on every UNIX system in existence. The Bourne shell is
considered to be very good for UNIX shell programming, but it does not handle
user interaction as well as some of the other shells available.
The C shell, written by Bill Joy, is much more responsive to user
interaction. It supports features such as command-line completion that are not
in the Bourne shell. The C shell's programming interface is thought by many not
to be as good as that of the Bourne shell, but it is used by many C programmers
because the syntax of its programming language is similar to that of the C
language. This is also why it is named the C shell.
The Korn shell (ksh) was written by Dave Korn. He took the best features of
both the C shell and the Bourne shell and combined them into one that is
completely compatible with the Bourne shell. ksh is efficient and has both a
good interactive interface and a good programming interface.
There are many quality reference books about the Bourne, C, and Korn shells. If you want to use these shells instead of the three shells discussed in this and the next two chapters, you may want to find a good reference book on the particular shell you prefer. Because the shells included with Linux are used by most people, we will concentrate on those.
In addition to these shells, many other shell programs took the basic
features from one or more of the existing shells and combined them into a new
version. The three newer shells that will be discussed in this book are tcsh (an
extension of csh), the Bourne Again Shell (bash, an extension of sh), and the
Public Domain Korn Shell (pdksh, an extension of ksh). bash is the default shell
on most Linux systems.
The Bourne Again Shell (bash), as its name implies, is an extension of the
Bourne shell. bash is fully backward-compatible with the Bourne shell, but
contains many enhancements and extra features that are not present in the Bourne
shell. bash also contains many of the best features that exist in the C and Korn
shells. bash has a very flexible and powerful programming interface, as well as
a user-friendly command interface.
Why use bash instead of sh? The biggest drawback of the Bourne shell is the
way that it handles user input. Typing commands into the Bourne shell can often
be very tedious, especially if you are using it on a regular basis and typing in
a large number of commands. bash provides several features that make entering
commands much easier.
Often when you enter commands into bash (or any other shell), the complete
text of the command is not necessary in order for the shell to be able to
determine what you want it to do. For example, assume that the current working
directory contains the following files and subdirectories:
News/ bin/ games/ mail/ samplefile test/
If you want to change directories from the current working directory to the
test subdirectory, you would enter the command
cd test
Although this command will work, bash enables you to accomplish the same
thing in a slightly different way. Since test is the only file in the directory
that begins with the letter t, bash should be able to figure out what you want
to do after you type in the letter t alone:
cd t
After the letter has been typed, the only thing that you could be referring
to is the test subdirectory. To get bash to finish the command for you, press
the Tab key:
cd t<tab>
When you do this, bash finishes the command for you and displays it on the
screen. The command doesn't actually execute until you press the Enter key to
verify that the command bash came up with is the command that you really
intended.
For short commands like this, you might not see very much value in making use
of command-line completion. Using this feature may even slow you down when
typing short commands. After you get used to using command-line completion,
though, and when the commands that you are entering get a little longer, you
will wonder how anyone lived without this feature.
So what happens if more than one file in the directory begins with the letter
t? It would seem that this would cause a problem if you wanted to use
command-line completion. Let's see what happens when you have the following
directory contents:
News/ bin/ mail/ samplefile test/ tools/ working/
Now you have two files in the directory that start with the letter t.
Assuming that you still want to cd into the test subdirectory, how do you do it
using command-line completion? If you type cd t<tab> as you did before,
bash will not know which subdirectory you want to change to because the
information you have given is not unique.
If you try to do this, bash will beep to notify you that it does not have
enough information to complete the command. After beeping, bash will leave the
command on the screen as it was entered. This enables you to enter more
information without retyping what was already typed. In this case, you only need
to enter an e and press the Tab key again. This will give bash enough
information to complete the command on the command line for you to verify:
cd test
If instead you decided that you want to cd into the tools subdirectory, you
could have typed
cd to<tab>
This would also give bash enough information to complete the command.
Whenever you press the Tab key while typing a command, bash will try to
complete the command for you. If it can't complete the command, it will fill in
as much as it can and then beep, notifying you that it needs more information.
You can then enter more characters and press the Tab key again, repeating this
process until bash returns the desired command.
Another way that bash makes typing commands easier is by enabling users to
use wildcards in their commands. The bash shell supports three kinds of
wildcards:
* matches any character and any number of characters.
? matches any single character.
[...] matches any single character contained within the brackets.
The * wildcard can be used in a manner similar to command-line completion.
For example, assume the current directory contains the following files:
News/ bin/ games/ mail/ samplefile test/
If you want to cd into the test directory, you could type cd test, or you
could use command-line completion:
cd t<tab>
This causes bash to complete the command for you. Now there is a third way to
do the same thing. Because only one file begins with the letter t, you could
also change to the directory by using the * wildcard. You could enter the
following command:
cd t*
The * matches any character and any number of characters, so the shell will
replace the t* with test (the only file in the directory that matches the
wildcard pattern).
This will work reliably only if there is one file in the directory that
starts with the letter t. If more than one file in the directory starts with the
letter t, the shell will try to replace t* with the list of filenames in the
directory that match the wildcard pattern and the cd command will cd into the
first directory in this list. This will end up being the file that comes first
alphabetically, and may or may not be the intended file.
A more practical situation in which to use the * wildcard is when you want to
execute the same command on multiple files that have similar filenames. For
example, assume the current directory contains the following files:
ch1.doc ch2.doc ch3.doc chimp config mail/ test/ tools/
If you wanted to print all of the files that have a .doc extension, you could
do so easily by entering the following command:
lpr *.doc
In this case, bash will replace *.doc with the names of all of the files in
the directory that match that wildcard pattern. After bash performed this
substitution, the command that would be processed would be:
lpr ch1.doc ch2.doc ch3.doc
The lpr command would be invoked with the arguments of ch1.doc, ch2.doc, and
ch3.doc.
Given the directory contents used in the previous example, there are several ways to print all of the files that have a .doc extension. All of the following commands would also work:
lpr *doc
lpr *oc
lpr *c
The ? wildcard functions in an identical way to the * wildcard except that
the ? wildcard only matches a single character. Using the same directory
contents shown in the previous example, the ? wildcard could be used to print
all of the files with the .doc extension by entering the following command:
lpr ch?.doc
The [...] wildcard enables you to specify certain characters or ranges of
characters to match. To print all of the files in the example that have the .doc
extension using the [...] wildcard, you would enter one of the following two
commands:
lpr ch[123].doc
Using a command to specify a range of characters, you would enter
lpr ch[1-3].doc
bash also supports command history. This means that bash keeps track of a
certain number of previous commands that have been entered into the shell. The
number of commands is given by a shell variable called HISTSIZE. For more
information on HISTSIZE, see the section "bash Variables" later in this chapter.
bash stores the text of the previous commands in a history list. When you log
into your account, the history list is initialized from a history file. The
filename of the history file can be set using the HISTFILE bash variable. The
default filename for the history file is .bash_history. This file is usually
located in your home directory. (Notice that the file begins with a period. This
means that the file is hidden and will only appear in a directory listing if you
use the -a or -A option of the ls command.).
Just storing previous commands into a history file is not all that useful, so
bash provides several ways of recalling them. The simplest way of using the
history list is with the up- and down-arrow keys, which scroll through the
commands that have been previously entered.
Pressing the up-arrow key will cause the last command that was entered to
appear on the command line. Pressing the up-arrow key again will put the command
previous to that one on the command line, and so on. If you move up in the
command buffer past the command that you wanted, you can also move down the
history list a command at a time by pressing the down-arrow key. (This is the
same process used by the DOS doskey utility.)
The command displayed on the command line through the history list can be
edited, if needed. bash supports a complex set of editing capabilities that are
beyond the scope of this book, but there are simple ways of editing the command
line for small and easy changes. You can use the left and right arrow keys to
move along the command line. You can insert text at any point in the command
line, and can also delete text by using the Backspace or Delete key. Most users
should find these simple editing commands sufficient.
The complex set of editing commands that bash offers are similar to the commands used in the emacs and vi text editors.
Another method of using the history file is to display and edit the list
using the history and fc (fix command) commands built into bash. The history
command can be invoked using two different methods. The first method uses the
command
history [n]
When the history command is used with no options, the entire contents of the
history list are displayed. The list that is displayed on-screen might resemble
the following sample list:
1 mkdir /usr/games/pool 2 cp XpoolTable-1.2.linux.tar.z /usr/games/pool 3 cd /usr/games/pool/ 4 ls 5 gunzip XpoolTable-1.2.linux.tar.z 6 tar -xf XpoolTable-1.2.linux.tar 7 ls 8 cd Xpool 9 ls 10 xinit 11 exit 12 which zip 13 zip 14 more readme 15 vi readme 16 exit
Using the n with the history command causes the only last n lines in the
history list to be shown. So, for example, history 5 shows only the last five
commands.
The second method of invoking the history command is used to modify the
contents of the history file, or the history list. The command has the following
command-line syntax:
history [-r|w|a|n] [filename]
In this form, the -r option tells the history command to read the contents of
the history file and use them as the current history list. The -w option will
cause the history command to write the current history list to the history file
(overwriting what is currently in the file). The -a option appends the current
history list to the end of the history file. The -n option causes the lines that
are in the history file to be read into the current history list.
All of the options for the second form of the history command can use the
filename option as the name of the history file. If no filename is specified,
the history command will use the value of the HISTFILE shell variable.
The fc command can be used in two different ways to edit the command history.
In the first way, the fc command would be entered using the following
command-line syntax:
fc [-e editor_name] [-n] [-l] [-r] [first] [last]
where all options given in braces are optional. The -e editor name option is
used to specify the text editor to be used for editing the commands. The first
and last options are used to select a range of commands to take out of the
history list. first and last can refer either to the number of a command in the
history list or to a string that fc will try to find in the history list.
The -n option is used to suppress command numbers when listing the history
commands. The -r option lists the matched commands in reverse order. The -l
command lists the matched commands to the screen. In all cases except when the
-l command option is used, the matching commands will be loaded into a text
editor.
The text editor used by fc is found by taking the value of editor name if the -e editor name option is used. If this option was not used, fc uses the editor specified by the variable FCEDIT. If this variable does not exist, fc will use the value of the EDITOR variable. Finally, if none of these variables exists, the editor that will be chosen is vi, by default.
Another way that bash makes life easier for you is by supporting command
aliases. Command aliases are commands that the user can specify. Alias commands
are usually abbreviations of other commands, designed to save keystrokes.
For example, if you are entering the following command on a regular basis,
you might be inclined to create an alias for it to save yourself some typing:
cd /usr/X11R6/lib/X11/config
Instead of typing this command every time you wanted to go to the
sample-configs directory, you could create an alias called goconfig that would
cause the longer command to be executed. To set up an alias like this you must
use the bash alias command. To create the goconfig alias, enter the following
command at the bash prompt:
alias goconfig='cd /usr/X11R6/lib/X11/configs
Now, until you exit from bash, the goconfig command will cause the original,
longer command to be executed as if you had just typed it.
If you decide after you have entered an alias that you did not need it, you
can use the bash unalias command to delete the alias:
unalias goconfig
There are a number of useful aliases that most users find helpful. These can
be written in a file that you execute when you log in, to save you from typing
them each time. Some aliases that you might want to define are the following:
If you are a DOS user and are used to using DOS file commands, you can use
the alias command to define the following aliases so that Linux behaves like
DOS:
When defining aliases, you can't include spaces on either side of the equal sign, or the shell can't properly determine what you want to do. Quotation marks are necessary only if the command within them contains spaces or other special characters.
If you enter the alias command without any arguments, it will display all of
the aliases that are already defined on-screen. The following listing
illustrates a sample output from the alias command:
alias dir='ls' alias ll='ls -l' alias ls='ls -F' alias md='mkdir' alias net='term < /dev/modem > /dev/modem 2> /dev/null&' alias rd='rmdir'
Input redirection is used to change the source of input for a command. When a
command is entered in bash, the command is expecting some kind of input in order
to do its job. Some of the simpler commands must get all of the information that
they need passed to them on the command line. For example, the rm command
requires arguments on the command line. You must tell rm the files that you want
it to delete on the command line, or it will issue a prompt telling you to enter
rm -h for help.
Other commands require more elaborate input than a simple directory name. The
input for these commands can be found in a file. For example, the wc (word
count) command counts the number of characters, words, and lines in the input
that was given to it. If you just type wc <enter> at the command line, wc
waits for you to tell it what it should be counting. There will be a prompt on
the command line asking for more information, but because the prompt is
sometimes not easily identifiable, it will not necessarily be obvious to you
what is happening. (It might actually appear as though bash has died, because it
is just sitting there. Everything that you type shows up on-screen, but nothing
else appears to be happening.)
What is actually occurring is that the wc command is collecting input for
itself. If you press Ctrl-D, the results of the wc command will be written to
the screen. If you enter the wc command with a filename as an argument, as shown
in the following example, wc will return the number of characters, words, and
lines that are contained in that file:
wc test 11 2 1
Another way to pass the contents of the test file to wc is to redirect the
input of the wc command from the terminal to the test file. This will result in
the same output. The < symbol is used by bash to mean "redirect the input to
the current command from the specified file." So, redirecting wc's input from
the terminal to the test file can be done by entering the following command:
wc < test 11 2 1
Input redirection is not used all that often because most commands that
require input from a file have the option to specify a filename on the command
line. There are times, however, when you will come across a program that will
not accept a filename as an input parameter, and yet the input that you want to
give exists in a file. Whenever this situation occurs, you can use input
redirection to get around the problem.
Output redirection is more commonly used than input redirection. Output
redirection enables you to redirect the output from a command into a file, as
opposed to having the output displayed on-screen.
There are many situations in which this can be useful. For example, if the
output of a command is quite large and will not fit on the screen, you might
want to redirect it to a file so that you can view it later using a text editor.
There also may be cases where you want to keep the output of a command to show
to someone else, or so you can print the results. Finally, output redirection is
also useful if you want to use the output from one command as input for another.
(There is an easier way to use the output of one command as input to a second
command. This is shown in the "Pipelines" section in this chapter.)
Output redirection is done in much the same way as input redirection. Instead
of using the < symbol, the > symbol is used.
The best way to remember which symbol is input or output redirection is to think of the < as a funnel that is funneling input into the command (because the command receiving the input will be on the left-hand side of the <) and the > as a funnel that is funneling the output from the command into a file.
As an example of output redirection, you can redirect the output of the ls
command into a file named directory.out using the following command:
ls > directory.out
Pipelines are a way to string together a series of commands. This means that
the output from the first command in the pipeline is used as the input to the
second command in the pipeline. The output from the second command in the
pipeline is used as input to the third command in the pipeline, and so on. The
output from the last command in the pipeline is the output that you will
actually see displayed on-screen (or put in a file if output redirection was
specified on the command line).
You can tell bash to create a pipeline by typing two or more commands
separated by the vertical bar or pipe character, |. The following example
illustrates the use of a pipeline:
cat sample.text | grep "High" | wc -l
This pipeline would take the output from the cat command (which lists the
contents of a file) and send it into the grep command. The grep command searches
for each occurrence of the word High in its input. The grep command's output
would then consist of each line in the file that contained the word High. This
output is then sent to the wc command. The wc command with the -l option prints
the number of lines contained in its input.
To show the results on a real file, suppose the contents of sample.text was
Things to do today: Low: Go grocery shopping High: Return movie High: Clear level 3 in Alien vs. Predator Medium: Pick up clothes from dry cleaner
The pipeline would return the result 2, indicating that you had two things of
high importance to complete today:
cat sample.text | grep "High" | wc -l 2
bash has two levels of user prompt. The first level is what you see when bash
is waiting for a command to be typed. (This is what you normally see when you
are working with bash.)
The default first-level prompt is the $ character. If you do not like the $
character as the prompt, or you would prefer to customize your prompt, you can
do so by setting the value of the PS1 bash variable. For example:
PS1="Please enter a command"
sets the bash shell prompt to the specified string.
The second level of prompt is displayed when bash is expecting more input
from you in order to complete a command. The default for the second level prompt
is >. If you want to change the second-level prompt, you can set the value of
the PS2 variable, as in
PS2="I need more information"
In addition to displaying static character strings in the command prompts (as
in the two preced-ing examples), you can also use some predefined special
characters. These special characters place things such as the current time into
the prompt. Table 10.1 lists the most commonly used special-character codes.
| Character | Meaning |
| \! | Displays the history number of this command. |
| \# | Displays the command number of the current command. |
| \$ | Displays a $ in the prompt unless the user is root. When the user is root, it displays a #. |
| \\ | Displays a backslash. |
| \d | Displays the current date. |
| \h | Displays the host name of the computer on which the shell is running. |
| \n | Prints a newline character. This will cause the prompt to span more than one line. |
| \nnn | Displays the character that corresponds to the octal value of the number nnn. |
| \s | The name of the shell that is running. |
| \t | Displays the current time. |
| \u | Displays the username of the current user. |
| \W | Displays the base name of the current working directory. |
| \w | Displays the current working directory. |
These special characters can be combined into several useful prompts to
provide you with information about where you are. (They can be combined in very
grotesque ways, too!) Several examples of setting the PS1 prompt are:
PS1="\t"
This would cause the prompt to have the following appearance (there would not
be a space after the prompt):
02:16:15
The prompt string
PS1=\t
would cause the prompt to have the following appearance:
t
This shows the importance of including the character sequence in quotation
marks. The prompt string
PS1="\t\\ "
will cause the prompt to look like this:
02:16:30\
In this case, there would be a space following the prompt because there was a
space within the quotation marks.
Job control refers to the ability to control the execution behavior of a
currently running process. Specifically, you can suspend a running process and
cause it to resume running at a later time. bash keeps track of all of the
processes that it started (as a result of user input), and you can suspend a
running process or restart a suspended one at any time during the life of that
process.
Pressing Ctrl-Z suspends a running process. The bg command restarts a
suspended process in the background, whereas the fg command restarts a process
in the foreground.
These commands are most often used when a user wants to run a command in the
background but by accident starts it in the foreground. When a command is
started in the foreground, it locks the shell from any further user interaction
until the command completes execution. This is usually no problem because most
commands only take a few seconds to execute. If the command you are running is
going to take a long time, though, you would typically start the command in the
background so that you could continue to use bash to enter other commands in the
foreground.
For example, if you started the command find / -name "test" > find.out
(which will scan the entire filesystem for files named test and store the
results in a file called find.out) in the foreground, your shell may be tied up
for many seconds or even minutes, depending on the size of the filesystem and
the number of users on the system. If you had issued this command and wanted to
continue executing in the background so you could use the system again, you
would enter the following:
control-z bg
This would first suspend the find command, then restart it in the background.
The find command would continue to execute, and you would have bash back again.
Many ways of customizing bash have already been described in this chapter.
Until now, the changes that you made affected only the current bash session. As
soon as you quit, all of the customizations that you made will be lost. You can
make the customizations more permanent by storing them in a bash initialization
file.
You can put any commands that you want to be executed each time bash is
started into this initialization file. Commands that are typically found in this
file are alias commands and variable initializations.
The bash initialization file is named profile. Each user who uses bash has a
.profile file in his home directory. This file is read by bash each time it
starts, and all of the commands contained within it are executed.
The following code shows the default .profile file. This file is located in
the /etc directory and is read when you start bash. If you want to add your own
customizations to bash, you must copy this file into your home directory (if it
is not already there) and call it .profile.
Some setup programs make a copy of the .profile file in your home directory for you automatically when they create your login. However, not all routines do this, so you should check your home directory first. Remember that all files starting with a period are hidden and can only be displayed with the ls -A or ls -a command.
# commands common to all logins export OPENWINHOME=/usr/openwin export MINICOM="-c on" export MANPATH=/usr/local/man:/usr/man/preformat:/usr/man:/X11/man:/usr/openwin/man export HOSTNAME="'cat /etc/HOSTNAME'" PATH="$PATH:/usr/X11/bin:$OPENWINHOME/bin:/usr/games:." LESS=-MM # I had problems using 'eval test' instead of 'TERM=', but you might want to
# try it anyway. I think with the right /etc/termcap it would work great.
# eval 'tset -sQ "$TERM"'if [ "$TERM" = "" -o "$TERM" = "unknown"]; then TERM=linux fi #PS1=''hostname':'pwd'# ' if [ "$SHELL" = "/bin/pdksh" -o "$SHELL" = "/bin/ksh" ]; then PS1="! $" elif [ "$SHELL" = "/bin/zsh" ]; then PS1="%m:%~%# " elif [ "$SHELL" = "/bin/ash" ]; then PS1="$ " else PS1='\h:\w\$ ' fi PS2='> ' ignoreeof=10 export PATH DISPLAY LESS TERM PS1 PS2 ignoreeof umask 022 # set up the color-ls environment variables: if [ "$SHELL" = "/bin/zsh" l; then eval 'dircolors -z' elif [ "$SHELL" = "/bin/ash" l; then eval 'dircolors -s' else eval 'dircolors -b' fi echo fortune echo export TAPE="/dev/nftape"
Here are some of the most useful commands built into the bash shell:
alias: Used to set bash aliases (command nicknames that can be defined by
the user).
bg: Background command. Forces a suspended process to continue to execute
in the background.
cd: Change working directory. This command changes the current working
directory to the directory specified as an argument.
exit: Terminates the shell.
export: Causes the value of a variable to be made visible to all
subprocesses that belong to the current shell.
fc: Fix command. Used to edit the commands in the current history list.
fg: Foreground command. Forces a suspended process to continue to execute
in the foreground.
help: Displays help information for bash built-in commands.
history: Brings up a list of the last n commands that were entered at the
command prompt, where n is a configurable variable specifying the number of
commands to remember.
kill: Used to terminate another process.
pwd: Print working directory. Prints the directory in which the user is
currently working.
unalias: Used to remove aliases that have been defined using the alias
command.
bash has many more commands than are listed here, but these are the most
frequently used ones. To see the other commands bash offers and for more details
of the commands listed, refer to the bash man page (type man bash).
Here are some of the most useful bash variables, including the variable name
and a brief description:
EDITOR, FCEDIT: The default editor for the fc bash command.
HISTFILE: The file used to store the command history.
HISTSIZE: The size of the history list.
HOME: The HOME directory of the current user
OLDPWD: The previous working directory (the one that was current before
the current directory was entered).
PATH: The search path that bash uses when looking for executable files
PS1: The first-level prompt that is displayed on the command line
PS2: The second-level prompt that is displayed when a command is
expecting more input
PWD: The current working directory
SECONDS: The number of seconds that have elapsed since the current bash
session was started
bash has many more variables than are listed here, but the most commonly used
ones are shown. To find out what other variables bash offers, call the man page
with the command man bash.
In this chapter you looked at some of the useful features of the Bourne Again
Shell, bash. You have seen how command completion, aliasing, and job control can
all combine to make you more productive and efficient when working with bash.
In the next chapter you will look at another popular Linux shell, the Public Domain Korn Shell (pdksh). It offers many useful features, too, providing you with a choice of shells.
