Prepare for LPIC-1 exam 1 - topic 103.1: The Linux command line

Overview

This tutorial gives you a brief introduction to some of the major features of the bash shell, and covers the following topics:

• Interacting with shells and commands using the command line
• Using valid commands and command sequences
• Defining, modifying, referencing, and exporting environment variables
• Accessing command history and editing facilities
• Invoking commands in the path and outside the path
• Using man (manual) pages to find out about commands

The bash shell

The bash shell is one of several shells available for Linux. It is also called the Bourne-again shell, after Stephen Bourne, the creator of an earlier shell (/bin/sh). Bash is substantially compatible with sh, but it provides many improvements in both function and programming capability. It incorporates features from the Korn shell (ksh) and C shell (csh), and is intended to be a POSIX-compliant shell.

Unless otherwise noted, the examples in this tutorial use Fedora 22, with a 4.0.4 kernel. Your results on other systems may differ.

This tutorial helps you prepare for Objective 103.1 in Topic 103 of the Linux Server Professional (LPIC-1) exam 101. The objective has a weight of 4.

Prerequisites

To get the most from the tutorials in this series, you should have a basic knowledge of Linux and a working Linux system on which you can practice the commands covered in this tutorial. Sometimes different versions of a program will format output differently, so your results may not always look exactly like the listings and figures shown here.

Before we delve deeper into bash, recall that a shell is a program that accepts and executes commands. It also supports programming constructs, allowing complex commands to be built from smaller parts. These complex commands, or scripts, can be saved as files to become new commands in their own right. Indeed, many commands on a typical Linux system are scripts.

Shells have some builtin commands, such as cd, break, and exec. Other commands are external.

Shells also use three standard I/O streams:

• stdin is the standard input stream, which provides input to commands.
• stdout is the standard output stream, which displays output from commands.
• stderr is the standard error stream, which displays error output from commands.

Input streams provide input to programs, usually from terminal keystrokes. Output streams print text characters, usually to the terminal. The terminal was originally an ASCII typewriter or display terminal, but it is now more often a window on a graphical desktop. More detail on how to redirect these standard I/O streams will be covered in another tutorial in this series.

For the rest of this tutorial, we will assume you know how to get a shell prompt.

If you are using a Linux system without a graphical desktop, or if you open a terminal window on a graphical desktop, you will be greeted by a prompt, perhaps like one of the three shown in Listing 1.

[ian@atticf20 ~]$ 
jenni@atticf20:data
$

Notice that these three prompts are all from my test system atticf20, but for different users. The first two are bash prompts and both show the logged in user, system name and current working directory. The third is the default prompt on my system for a ksh shell. Different distributions and different shells default to different prompts, so don’t panic if your distribution looks different. We'll cover how to change your prompt string in another tutorial in this series.

If you log in as the root user (or superuser), your prompt may look like one of those shown in Listing 2.

[root@atticf20 ~]#
atticf20:~#

The root user has considerable power, so use it with caution. When you have root privileges, most prompts include a trailing pound sign (#). Ordinary user privileges are usually delineated by a different character, commonly a dollar sign ($). Your actual prompt may look different than the examples in this tutorial. Your prompt may include your user name, hostname, current directory, date, or time that the prompt was printed, and so on.

Note: Some systems, such as Debian and Debian-based distributions such as Ubuntu, do not allow root login and require all privileged (root) commands to be executed using the sudo command. In this case, your prompt will not change, but you will know that you have to use sudo to execute commands that an ordinary user does not have the power to execute.

These tutorials include code examples that are cut and pasted from real Linux systems using the default prompts for those systems. Our root prompts have a trailing #, so you can distinguish them from ordinary user prompts, which have a trailing $. This convention is consistent with many books on the subject. If something doesn't appear to work for you, check the prompt in the example.

Commands and sequences

So now that you have a prompt, let's look at what you can do with it. The shell's main function is to interpret your commands so you can interact with your Linux system. On Linux (and UNIX®) systems, commands have a command name, and then options and parameters. Some commands have neither options nor parameters, and some have one but not the other.

If a line contains a # character, then all remaining characters on the line are ignored. So a # character may indicate a comment as well as a root prompt. Which it is should be evident from the context.

Echo

The echo command prints (or echos) its arguments to the terminal as shown in Listing 3.

[ian@atticf20 ~]$ echo Word
Word
[ian@atticf20 ~]$ echo A phrase
A phrase
[ian@atticf20 ~]$ echo Where     are   my   spaces?
Where are my spaces?
[ian@atticf20 ~]$ echo "Here     are   my   spaces." #plus comment
Here     are   my   spaces.

In the third example of Listing 3, all the extra spaces were compressed down to single spaces in the output. To avoid this, you need to quote strings, using either double quotes (") or single quotes ('). Bash uses white space, such as blanks, tabs, and new line characters, to separate your input line into tokens, which are then passed to your command. Quoting strings preserves additional white space and makes the whole string a single token. In the example above, each token after the command name is a parameter, so we have respectively 1, 2, 4, and 1 parameters.

The echo command has a couple of options. Normally, echo will append a trailing new line character to the output. Use the -n option to suppress this. Use the -e option to enable certain backslash escaped characters to have special meaning. Some of these are shown in Table 1.

Escapes and line continuation

There is a small problem with using backslashes in bash. When the backslash character () is not quoted, it serves as an escape to signal bash itself to preserve the literal meaning of the following character. This is necessary for special shell metacharacters, which we'll cover in a moment. There is one exception to this rule: a backslash followed by a newline causes bash to swallow both characters and treat the sequence as a line continuation request. This can be handy to break long lines, particularly in shell scripts.

For the sequences described above to be properly handled by the echo command or one of the many other commands that use similarly escaped control characters, you must include the escape sequences in quotes, or as part of a quoted string, unless you use a second backslash to have the shell preserve one for the command. Listing 4 shows some examples of the various uses of .

[ian@atticf20 ~]$ echo ‑e "No new line\c"
No new line[ian@atticf20 ~]$ echo "A line with a typed
> return"
A line with a typed
return
[ian@atticf20 ~]$ echo ‑e "A line with an escaped\nreturn"
A line with an escaped
return
[ian@atticf20 ~]$ echo "A line with an escaped\nreturn but no ‑e option"
A line with an escaped\nreturn but no ‑e option
[ian@atticf20 ~]$ echo ‑e Doubly escaped\n\tmetacharacters
Doubly escaped
 metacharacters
[ian@atticf20 ~]$ echo Backslash 
> followed by newline 
> serves as line continuation.
Backslash followed by newline serves as line continuation.

Note that bash displays a special prompt (>) when you type a line with unmatched quotes. Your input string continues onto a second line and includes the new line character.

Bash shell metacharacters and control operators

Bash has several metacharacters, which when not quoted, also serve to divide input into words. Besides a blank, these are:

• |
  
• &
  
• ;
  
• (
  
• )
  
• <
  
• >

We will discuss some of these in more detail in other parts of this tutorial. For now, note that if you want to include a metacharacter as part of your text, it must be either quoted or escaped using a backslash () as shown in Listing 4.

The new line and certain metacharacters or pairs of metacharacters also serve as control operators. These are:

• ||
  
• &&
  
• &
  
• ;
  
• ;;
  
• |
  
• (
  
• )
  

Some of these control operators allow you to create sequences or lists of commands.

The simplest command sequence is just two commands separated by a semicolon (;). Each command is executed in sequence. In any programmable environment, commands return an indication of success or failure; Linux commands usually return a zero value for success and a non-zero value in the event of failure. You can introduce some conditional processing into your list using the && and || control operators. If you separate two commands with the control operator &&, then the second is executed if, and only if, the first returns an exit value of zero. If you separate the commands with ||, then the second one is executed only if the first one returns a non-zero exit code. Listing 5 shows some command sequences using the echo command. These aren't very exciting since echo returns 0, but you will see more examples later when we have a few more commands to use.

[ian@atticf20 ~]$ echo line 1;echo line 2; echo line 3
line 1
line 2
line 3
[ian@atticf20 ~]$ echo line 1&&echo line 2&&echo line 3
line 1
line 2
line 3
[ian@atticf20 ~]$ echo line 1||echo line 2; echo line 3
line 1
line 3

Exit

You can terminate a shell using the exit command. You may optionally give an exit code as a parameter. If you are running your shell in a terminal window on a graphical desktop, your window will close. Similarly, if you have connected to a remote system using ssh or telnet (for example), your connection will end. In the bash shell, you can also hold the Ctrl key and press the d key to exit.

Let's look at another control operator. If you enclose a command or a command list in parentheses, then the command or sequence is executed in a sub shell, so the exit command exits the sub shell rather than exiting the shell you are working in. Listing 6 shows a simple example in conjunction with && and || and two different exit codes.

[ian@atticf20 ~]$ (echo In subshell; exit 0) && echo OK || echo Bad exit
In subshell
OK
[ian@atticf20 ~]$  (echo In subshell; exit 4) && echo OK || echo Bad exit
In subshell
Bad exit

Stay tuned for more command sequences later in this tutorial.

Environment variables

When you are running in a bash shell, many things constitute your environment, such as the form of your prompt, your home directory, your working directory, the name of your shell, files that you have opened, functions that you have defined, and so on. Your environment includes many variables that may have been set by bash or by you. The bash shell also allows you to have shell variables, which you may export to your environment for use by other processes running in the shell or by other shells that you may spawn from the current shell.

Both environment variables and shell variables have a name. You reference the value of a variable by prefixing its name with '$'. Some of the common bash environment variables that you will encounter are shown in Table 2.

Listing 7 shows what you might see in some of these common bash variables.

[ian@atticf20 ~]$ echo $USER $UID
ian 1000
[ian@atticf20 ~]$ echo $SHELL $HOME $PWD
/bin/bash /home/ian /home/ian
[ian@atticf20 ~]$ (exit 0);echo $?;(exit 4);echo $?
0
4
[ian@atticf20 ~]$ echo $$ $PPID
3175 2457

You may create or set a shell variable by typing a name followed immediately by an equal sign (=). If the variable exists, you will modify it to assign the new value. Variables are case sensitive, so var1 and VAR1 are different variables. By convention, variables, particularly exported variables, are upper case, but this is not a requirement. Technically, $$ and $? are shell parameters rather than variables. They may only be referenced; you cannot assign a value to them.

When you create a shell variable, you will often want to export it to the environment so it will be available to other processes that you start from this shell. Variables that you export are not available to a parent shell. You use the export command to export a variable name. As a shortcut in bash, you can assign a value and export a variable in one step.

To illustrate assignment and exporting, let's run the bash command while in the bash shell and then run the Korn shell (ksh) from the new bash shell. We will use the ps command to display information about the command that is running. We'll learn more about ps in another tutorial in this series.

[ian@atticf20 ~]$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 3175  2457 bash
[ian@atticf20 ~]$ bash
[ian@atticf20 ~]$  ps ‑p $ ‑o "pid ppid cmd"
  PID  PPID CMD
 4325  3175 bash
[ian@atticf20 ~]$ VAR1=var1
[ian@atticf20 ~]$ VAR2=var2
[ian@atticf20 ~]$ export VAR2
[ian@atticf20 ~]$ export VAR3=var3
[ian@atticf20 ~]$ echo $VAR1 $VAR2 $VAR3
var1 var2 var3
[ian@atticf20 ~]$ echo $VAR1 $VAR2 $VAR3 $SHELL
var1 var2 var3 /bin/bash
[ian@atticf20 ~]$ ksh
$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 4427  4325 ksh
$ export VAR4=var4
$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
var2 var3 var4 /bin/bash
$ exit
[ian@atticf20 ~]$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
var1 var2 var3 /bin/bash
[ian@atticf20 ~]$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 4325  3175 bash
[ian@atticf20 ~]$ exit
exit
[ian@atticf20 ~]$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 3175  2457 bash
[ian@atticf20 ~]$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
/bin/bash
                    
                    
[ian@echidna ~]$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 2559  2558 ‑bash
[ian@echidna ~]$ bash
[ian@echidna ~]$ ps ‑p $ ‑o "pid ppid cmd"
  PID  PPID CMD
 2811  2559 bash
[ian@echidna ~]$ VAR1=var1
[ian@echidna ~]$ VAR2=var2
[ian@echidna ~]$ export VAR2
[ian@echidna ~]$ export VAR3=var3
[ian@echidna ~]$ echo $VAR1 $VAR2 $VAR3
var1 var2 var3
[ian@echidna ~]$ echo $VAR1 $VAR2 $VAR3 $SHELL
var1 var2 var3 /bin/bash
[ian@echidna ~]$ ksh
$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 2840  2811 ksh
$ export VAR4=var4
$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
var2 var3 var4 /bin/bash
$ exit
[ian@echidna ~]$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
var1 var2 var3 /bin/bash
[ian@echidna ~]$ ps ‑p $ ‑o "pid ppid cmd"
  PID  PPID CMD
 2811  2559 bash
[ian@echidna ~]$ exit
exit
[ian@echidna ~]$ ps ‑p $$ ‑o "pid ppid cmd"
  PID  PPID CMD
 2559  2558 ‑bash
[ian@echidna ~]$ echo $VAR1 $VAR2 $VAR3 $VAR4 $SHELL
/bin/bash

Notes:

1. At the start of this sequence, the bash shell had PID 3175.
2. The second bash shell has PID 4325, and its parent is PID 3175, the original bash shell.
3. We created VAR1, VAR2, and VAR3 in the second bash shell, but only exported VAR2 and VAR3.
4. In the Korn shell, we created VAR4. The echo command displayed values only for VAR2, VAR3, and VAR4, confirming that VAR1 was not exported. Were you surprised to see that the value of the SHELL variable had not changed, even though the prompt had changed? You cannot always rely on SHELL to tell you what shell you are running under, but the ps command does tell you the actual command. Note that ps puts a hyphen (-) in front of the first bash shell to indicate that this is the login shell.
5. Back in the second bash shell, we can see VAR1, VAR2, and VAR3.
6. And finally, when we return to the original shell, none of our new variables still exist.

The earlier discussion of quoting mentioned that you could use either single or double quotes. There is an important difference between them. The shell expands shell variables that are between double quotes ($quot;), but expansion is not done when single quotes (') are used. In the previous example, we started another shell within our shell and we got a new process id. Using the -c option, you can pass a command to the other shell, which will execute the command and return. If you pass a quoted string as a command, your outer shell will strip the quotes and pass the string. If double quotes are used, variable expansion occurs before the string is passed, so the results may not be as you expect. The shell and command will run in another process so they will have another PID. Listing 9 illustrates these concepts. The PID of the top-level bash shell is highlighted.

[ian@atticf20 ~]$ echo "$SHELL" '$SHELL' "$$" '$$'
/bin/bash $SHELL 3175 $$
[ian@atticf20 ~]$bash ‑c "echo Expand in parent $$ $PPID"
Expand in parent 3175 2457
[ian@atticf20 ~]$ bash ‑c 'echo Expand in child $$ $PPID'
Expand in child 4541 3175

So far, all our variable references have terminated with white space, so it has been clear where the variable name ends. In fact, variable names may be composed only of letters, numbers or the underscore character. The shell knows that a variable name ends where another character is found. Sometimes you need to use variables in expressions where the meaning is ambiguous. In such cases, you can use curly braces to delineate a variable name as shown in Listing 10.

[ian@atticf20 ~]$ echo "‑$HOME/abc‑"
‑/home/ian/abc‑
[ian@atticf20 ~]$ echo "‑$HOME_abc‑"
‑‑
[ian@atticf20 ~]$ echo "‑${HOME}_abc‑"
‑/home/ian_abc‑

Env

The env command without any options or parameters displays the current environment variables. You can also use it to execute a command in a custom environment. The -i (or just -) option clears the current environment before running the command, while the -u option unsets environment variables that you do not wish to pass.

Listing 11 shows partial output of the env command without any parameters and then three examples of invoking different shells without the parent environment. Look carefully at these before we discuss them.

Note: If your system does not have the ksh (Korn) or tcsh shells installed, you will need to install them to do these exercises yourself.

    [ian@atticf20 ~]$ env
XDGVTNR=2
XDG_SESSION_ID=1
HOSTNAME=atticf20
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
SHELL=/bin/bash
TERM=xterm‑256color
XDG_MENU_PREFIX=gnome‑
VTE_VERSION=4002
HISTSIZE=1000
GJS_DEBUG_OUTPUT=stderr
WINDOWID=35651982
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
QT_GRAPHICSSYSTEM_CHECKED=1
USER=ian
...=/usr/bin/env
OLDPWD=/home/ian/Documents
[ian@atticf20 ~]$ env ‑i bash ‑c 'echo $SHELL; env'
/bin/bash
PWD=/home/ian
SHLVL=1
=/usr/bin/env
[ian@atticf20 ~]$ env ‑i ksh ‑c 'echo $SHELL; env'
/bin/sh
=3175/usr/bin/env
PWD=/home/ian
SHLVL=1
_AST_FEATURES=UNIVERSE ‑ ucb
A__z="*SHLVL
[ian@atticf20 ~]$env ‑i tcsh ‑c 'echo $SHELL; env'
SHELL: Undefined variable.

When bash sets the SHELL variable, it exports it to the environment, There are three other variables that the new bash shell has created in the environment. In the ksh example, we have five environment variables, but our attempt to echo the value of the SHELL variable gives /bin/sh. Some earlier versions of ksh simply gave a blank line indicating that the SHELL variable was not set. Finally, tcsh has not created any environment variables and produces an error at our attempt to reference the value of SHELL.

Unset and set

Listing 11 showed different behavior in how shells handle variables and environments. While this tutorial focuses on bash, it is good to know that not all shells behave the same way. Furthermore, shells behave differently according to whether they are a login shell or not. For now, we will just say that a login shell is the shell you get when you log in to a system; you can start other shells to behave as login shells if you wish. The three shells started above using env -i were not login shells. Try passing the -l option to the shell command itself to see what differences you would get with a login shell.

So let's consider our attempt to display the SHELL variable's value in these non-login shells:

1. When bash started, it set the SHELL variable, but it did not automatically export it to the environment.
2. When ksh started, it set its view of the SHELL variable to /bin/sh. Compare this with the earlier example where ksh inherited the exported value of /bin/bash from the calling bash shell.
3. When tcsh started, it did not set the SHELL variable. In this case, the default behavior is different than ksh (and bash) in that an error is reported when we attempt to use a variable that does not exist.

You can use the unset command to unset a variable and remove it from the shell variable list. If the variable was exported to the environment, this will also remove it from the environment. You can use the set command to control many facets of the way bash (or other shells) work. Set is a shell builtin, so the various options are shell specific. In bash, the -u option causes bash to report an error with undefined variables rather than treat them as defined but empty. You can turn on the various options to set with a - and turn them off with a +. You can display currently set options using echo $-.

[ian@atticf20 ~]$ echo $‑
himBH
[ian@atticf20 ~]$ echo $VAR1

[ian@atticf20 ~]$ set ‑u;echo $‑
himuBH
[ian@atticf20 ~]$ echo $VAR1
bash: VAR1: unbound variable
[ian@atticf20 ~]$ VAR1=v1;echo $VAR1
v1
[ian@atticf20 ~]$ unset VAR1;echo $VAR1
bash: VAR1: unbound variable
[ian@atticf20 ~]$ set +u;echo $VAR1;echo $‑

himBH

If you use the set command without any options, it displays all your shell variables and their values (if any). There is also another command, declare, which you can use to create, export, and display values of shell variables. You can explore the many remaining set options and the declare command using the man pages. We will discuss man pages later in this tutorial.

Exec

One final command to cover is exec. You can use the exec command to run another program that replaces the current shell. Listing 13 starts a child bash shell and then uses exec to replace it with a Korn shell. Upon exit from the Korn shell, you are back at the original bash shell (PID 2852, in this example).

[ian@atticf20 ~]$ echo $$
3175
[ian@atticf20 ~]$ bash
[ian@atticf20 ~]$ echo $$
4994
[ian@atticf20 ~]$ exec ksh
$ echo $$
4994
$ exit
[ian@atticf20 ~]$ echo $$
3175

System information with uname

The uname command prints information about your system and its kernel. Listing 14 shows the various options for uname and the resulting information; each option is defined in Table 3.

[ian@atticf20 ~]$ uname
Linux
[ian@atticf20 ~]$ uname ‑s
Linux
[ian@atticf20 ~]$ uname ‑n
atticf20
[ian@atticf20 ~]$ uname ‑r
4.0.4‑303.fc22.x86_64
[ian@atticf20 ~]$ uname ‑v
#1 SMP Thu May 28 12:37:06 UTC 2015
[ian@atticf20 ~]$ uname ‑m
x86_64
[ian@atticf20 ~]$ uname ‑o
GNU/Linux
[ian@atticf20 ~]$ uname ‑a
Linux atticf20 4.0.4‑303.fc22.x86_64 #1 SMP Thu May 28 12:37:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Listing 14 is from a Fedora 22 system running on a 64-bit AMD® CPU. The uname command is available on most UNIX® and UNIX-like systems, as well as Linux. The information printed will vary by Linux distribution and version as well as by the type of machine you are running on. Listing 15 shows the output from an older Intel® 32-bit system running Ubuntu 14.04 in live mode from a DVD.

                    
ian@Z61t‑u14:~$ uname ‑a
Linux Z61t‑u14 3.16.0‑30‑generic #40~14.04.1‑Ubuntu SMP Thu Jan 15 17:45:15 UTC 
2015 i686 i686 i686 GNU/Linux

Command history

If you are typing in commands as you read, you may notice that you often use a command many times, either exactly the same or with slight changes. The good news is that the bash shell can maintain a history of your commands. By default, history is on. You can turn it off using the command set +o history and turn it back on using set -o history. An environment variable called HISTSIZE tells bash how many history lines to keep. A number of other settings control how history works and is managed. See the bash man pages for full details.

Some of the commands that you can use with the history facility are:

history
Displays the entire history.

history N
Displays the last N lines of your history.

history -d N
Deletes line N form your history; you might do this if the line contains a password, for example.

!!
Your most recent command.

!N
The Nth history command.

!-N
The command that is N commands back in the history (!-1 is equivalent to !!).

!#
The current command you are typing.

!string
The most recent command that starts with string.

!?string?
The most recent command that contains string.

You can also use a colon (:) followed by certain values to access or modify part or a command from your history. Listing 16 illustrates some of the history capabilities.

[ian@atticf20 ~]$ echo $$
3175
[ian@atticf20 ~]$ env ‑i bash ‑c 'echo $$'
6737
[ian@atticf20 ~]$ !!
env ‑i bash ‑c 'echo $$'
6744
[ian@atticf20 ~]$ !ec
echo $$
3175
[ian@atticf20 ~]$ !en:s/$$/$PPID/
env ‑i bash ‑c 'echo $PPID'
3175
[ian@atticf20 ~]$ history 6
  263  history ‑d259
  264  echo $$
  265  env ‑i bash ‑c 'echo $$'
  266  echo $$
  267  env ‑i bash ‑c 'echo $PPID'
  268  history 6
[ian@atticf20 ~]$ history ‑d266
[ian@atticf20 ~]$ !‑2
history 6
  264  echo $$
  265  env ‑i bash ‑c 'echo $$'
  266  env ‑i bash ‑c 'echo $PPID'
  267  history 6
  268  history ‑d266
  269  history 6

The commands in Listing 16 do the following:

1. Echo the current shell's PID.
2. Run an echo command in a new shell and echo that shell's PID.
3. Rerun the last command.
4. Rerun the last command starting with 'ec'; this reruns the first command in this example.
5. Rerun the last command starting with 'en', but substitute '$PPID' for '$$', so the parent PID is displayed instead.
6. Put a comment on the terminal output.
7. Display the last 6 commands of the history.
8. Delete history entry 266, the last echo command.
9. Redisplay the latest 6 commands of the history.

You can also edit the history interactively. The bash shell uses the readline library to manage command editing and history. By default, the keys and key combinations used to move through the history or edit lines are similar to those used in the GNU Emacs editor. Emacs keystroke combinations are usually expressed as C-x or M-x, where x is a regular key and C and M are the Control and Meta keys, respectively. On a typical PC system, the Ctrl key serves as the Emacs Control key, and the Alt key serves as the Meta key. Table 4 summarizes some of the history editing functions available. Besides the key combinations shown in Table 4, cursor movement keys such as the right, left, up, and down arrows, and the Home and End keys are usually set to work in a logical way. Additional functions, as well as how to customize these options using a readline init file (usually inputrc in your home directory), can be found in the man pages.

If you prefer to manipulate the history using a vi-like editing mode, use the command set -o vi to switch to vi mode. Switch back to emacs mode using set -o emacs. When you retrieve a command in vi mode, you are initially in vi's insert mode. The vi editor is covered in another tutorial in this series. (See resources on the right for the series roadmap).

When you close a shell session or logoff bash saves the last $HISTSIZE history lines in your home directory in a file called .bash_history (~/.bash_history). When you login again your history is loaded from this file. If you have multiple sessions open, then the history file is rewritten as each one closes. There is no merging of data from each session.

Paths - where's my command?

Some bash commands are builtin, while others are external. Let's now look at external commands and how to run them, and how to tell if a command is internal.

Where does the shell find commands?

External commands are just files in your file system. Basic file management is covered in another tutorial in this series. (See resources on the right for the series roadmap). On Linux and UNIX systems, all files are accessed as part of a single large tree that is rooted at /. In our examples so far, our current directory has been the user's home directory. Non-root users usually have a home directory within the /home directory, such as /home/ian, in my case. Root's home is usually /root. If you type a command name, then bash looks for that command on your path, which is a colon-separated list of directories in the PATH environment variable.

If you want to know what command will be executed if you type a particular string, use the which or type command. Listing 17 shows my default path along with the locations of several commands.

[ian@atticf20 ~]$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/ian/.local/bin:/home/ian/bin
[ian@atticf20 ~]$ which bash env zip xclock echo set ls
alias ls='ls ‑‑color=auto'
 /usr/bin/ls
/usr/bin/bash
/usr/bin/env
/usr/bin/zip
/usr/bin/xclock
/usr/bin/echo
/usr/bin/which: no set in (/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:
/home/ian/.local/bin:/home/ian/bin)
[ian@atticf20 ~]$ type bash env zip xclock echo set ls
bash is hashed (/usr/bin/bash)
env is hashed (/usr/bin/env)
zip is /usr/bin/zip
xclock is /usr/bin/xclock
echo is a shell builtin
set is a shell builtin
ls is aliased to `ls ‑‑color=auto'

Note that the directories in the path mostly end in /bin. This is a common convention, but not a requirement. The which command reported that the ls command is an alias and that the set command could not be found. In this case, we interpret that to mean that it does not exist or that it is a builtin. The type command reports that the ls command is an alias, but it identifies the set command as a shell builtin. It also reports that there is a builtin echo command as well as the one in /bin that was found by which. The commands also produce output in different orders.

We saw that the ls command, used for listing directory contents, is an alias. Aliases are a handy way to configure some commands to use different sets of defaults or to provide an alternate name for a command. In our example, the --color=tty option causes directory listings to be color coded according to the type of file or directory. Try running dircolors --print-database to see how the color coding is controlled and which colors are used for what kind of file.

Each of these commands has additional options. Depending on your need, you may use either command. I tend to use which when I am reasonably sure I'll find an executable and I just need its full path specification. I find that type gives me more precise information, which I sometimes need in a shell script.

Running other commands

We saw in Listing 17 that executable files have a full path starting with /, the root directory. For example, the xclock program is really /usr/bin/xclock, a file located in the /usr/bin directory. On older systems you might find this in the /usr/X11R6/bin directory instead. If a command is not in your PATH specification, you may still run it by specifying a path as well as a command name. There are two types of paths that you can use:

• Absolute paths are those starting with /, such as those we saw in Listing 17 (/bin/bash, /bin/env, etc).
• Relative paths are relative to your current working directory, as reported by the pwd command. These commands do not start with /, but do contain at least one /.

You may use absolute paths regardless of your current working directory, but you will probably use relative paths only when a command is close to your current directory. Suppose you are developing a new version of the classic "Hello World!" program in a subdirectory of your home directory called mytestbin. You might use the relative path to run your command as mytestbin/hello. There are two special names you can use in a path; a single dot (.) refers to the current directory, and a pair of dots (..) refers to the parent of the current directory. Because your home directory is usually not on your PATH (and generally should not be), you will need to explicitly provide a path for any executable that you want to run from your home directory. For example, if you had a copy of your hello program in your home directory, you could run it using the command ./hello. You can use both . and .. as part of an absolute path, although a single . is not very useful in such a case. You can also use a tilde (~) to mean your own home directory and ~username to mean the home directory of the user named username. Some examples are shown in Listing 18.

[ian@atticf20 ~]$ /bin/echo Use echo command rather than builtin
Use echo command rather than builtin
[ian@atticf20 ~]$ /usr/../bin/echo Include parent dir in path
Include parent dir in path
[ian@atticf20 ~]$ /bin/././echo Add a couple of useless path components
Add a couple of useless path components
[ian@atticf20 ~]$ pwd #See where we are
/home/ian
[ian@atticf20 ~]$ ../../bin/echo Use a relative path to echo
Use a relative path to echo
[ian@atticf20 ~]$ myprogs/hello #Use a relative path with no dots
bash: myprogs/hello: No such file or directory
[ian@atticf20 ~]$ mytestbin/hello #Use a relative path with no dots
Hello World! 
[ian@atticf20 ~]$ cp mytestbin/hello . #Copy hello program to home
[ian@atticf20 ~]$ ./hello 
Hello World! 
[ian@atticf20 ~]$ ~/mytestbin/hello #run hello using ~
Hello World! 
[ian@atticf20 ~]$ ../hello #Try running hello from parent
bash: ../hello: No such file or directory

Changing your working directory

Just as you can execute programs from various directories in the system, so too can you change your current working directory using the cd command. The argument to cd must be the absolute or relative path to a directory. As for commands, you can use ., .., ~, and ~username in paths. If you use cd with no parameters, the change will be to your home directory. A single hyphen (-) as a parameter means to change to the previous working directory. Your home directory is stored in the HOME environment variable, and the previous directory is stored in the OLDPWD variable, so cd alone is equivalent to cd $HOME and cd - is equivalent to cd $OLDPWD. Usually we say change directory instead of the full change current working directory.

As for commands, there is also an environment variable, CDPATH, which contains a colon-separated set of directories that should be searched (in addition to the current working directory) when resolving relative paths. If resolution used a path from CDPATH, then cd will print the full path of the resulting directory as output. Normally, a successful directory change results in no output other than a new, and possibly changed, prompt. Some examples are shown in Listing 19.

[ian@atticf20 ~]$ cd /;pwd
/
[ian@atticf20 /]$ cd /usr/local;pwd
/usr/local
[ian@atticf20 local]$ cd ;pwd
/home/ian
[ian@atticf20 ~]$ cd ‑;pwd
/usr/local
/usr/local
[ian@atticf20 local]$ cd ~ian/..;pwd
/home
[ian@atticf20 home]$ cd ~;pwd
/home/ian
[ian@atticf20 ~]$ export CDPATH=~
[ian@atticf20 ~]$ cd /;pwd
/
[ian@atticf20 /]$ cd mytestbin
/home/ian/mytestbin

Manual (man) pages

Our final topic in this tutorial tells you how to get documentation for Linux commands through manual pages and other sources of documentation.

Manual pages and sections

The primary (and traditional) source of documentation is the manual pages, which you can access using the man command. Figure 1 shows the grep command in action. Use the command man grep to display this information.

Figure 1. Man page for the grep command

• A heading with the name of the command followed by its section number in parentheses.
• The name of the command and any related commands that are described on the same man page.
• A synopsis of the options and parameters applicable to the command.
• A short description of the command.
• Detailed information on each of the options.

You might find other sections on usage, how to report bugs, author information, and a list of related commands. Related commands and their section are usually found under SEE ALSO. For example, the man page for man lists the related commands shown in Listing 20.

SEE ALSO
       apropos(1),  groff(1),  less(1),  manpath(1),  nroff(1),
       troff(1),  whatis(1),  zsoelim(1),  setlocale(3),   man‐
       path(5),   ascii(7),   latin1(7),   man(7),   catman(8),
       mandb(8), the man‑db package manual, FSSTND

There are eight common manual page sections. Manual pages are usually installed when you install a package, so if you do not have a package installed, you probably won't have a manual page for it. Similarly, some of your manual sections may be empty or nearly empty. The common manual sections, with some example contents are:

1. User commands (env, ls, echo, mkdir, tty)
2. System calls or kernel functions (link, sethostname, mkdir)
3. Library routines (acosh, asctime, btree, locale, XML::Parser)
4. Device related information (isdn_audio, mouse, tty, zero)
5. File format descriptions (keymaps, motd, wvdial.conf)
6. Games (note that many games are now graphical and have graphical help outside the man page system)
7. Miscellaneous (arp, boot, regex, unix utf8)
8. System administration (debugfs, fdisk, fsck, mount, renice, rpm)

Other sections that you might find include 9 for Linux kernel documentation, n for new documentation, o for old documentation, and l for local documentation.

Some entries appear in multiple sections. Our examples in Listing 21 below show mkdir in sections 1 and 2, and tty in sections 1 and 4. You can specify a particular section, for example, man 4 tty or man 2 mkdir, or you can specify the -a option to list all applicable manual sections.

The man command has many options and related command for you to explore on your own. For now, let's take a quick look at some of the "See also" commands related to man.

See also

Two important commands related to man are whatis and apropos. The whatis command searches man pages for the name you give and displays the name information from the appropriate manual pages. The apropos command does a keyword search of manual pages and lists ones containing your keyword.

[ian@atticf20 ~]$ whatis man
man (7)              ‑ macros to format man pages
man (1p)             ‑ display system documentation
man (1)              ‑ an interface to the on‑line reference m...
[ian@atticf20 ~]$ whatis mkdir
mkdir (3p)           ‑ make a directory relative to directory ...
mkdir (1p)           ‑ make directories
mkdir (2)            ‑ create a directory
mkdir (1)            ‑ make directories
[ian@atticf20 ~]$ apropos mkdir
gvfs‑mkdir (1)       ‑ Create directories
mkdir (1)            ‑ make directories
mkdir (1p)           ‑ make directories
mkdir (2)            ‑ create a directory
mkdir (3p)           ‑ make a directory relative to directory ...
mkdirat (2)          ‑ create a directory

The man command pages output onto your display using a paging program. On most Linux systems, this is likely to be the less program. Another choice might be the older more program. If you wish to print the page, specify the -t option to format the page for printing using the groff or troff program.

The less pager has several commands that help you search for strings within the displayed output. Use man less to find out more about / (search forwards), ? (search backwards), and n (repeat last search), among many other commands.

Bash help

The man page for bash is very long and it can take some time to search through it, even using the less pager. Fortunately, if you just want some quick help on a bash builtin you can use the help builtin as shown in Listing 22. Use help with no arguments to get a list of available help and use help helphelphelp to find out how to use help.

[ian@atticf20 ~]$ type help #See that help is a builtin
help is a shell builtin
[ian@atticf20 ~]$ help cd
cd: cd [‑L|[‑P [‑e]] [‑@]] dir    Change the shell working directory.
    
    Change the current directory to DIR.  The default DIR is the value of the
    HOME shell variable.

    The variable CDPATH defines the search path for the directory containing
    DIR. Alternative directory names in CDPATH are separated by a colon (:).
    A null directory name is the same as the current directory.  If DIR begins
    with a slash (/), then CDPATH is not used.
    
    If the directory is not found, and the shell option cdable_vars' is set,
    the word is assumed to be  a variable name.  If that variable has a value,
    its value is used for DIR.
    
 Options:
        ‑L    force symbolic links to be followed: resolve symbolic links in
      DIR after processing instances of..'
 ‑P    use the physical directory structure without following symbolic
     links: resolve symbolic links in DIR before processing instances
         of ..'
        ‑e    if the ‑P option is supplied, and the current working directory
    cannot be determined successfully, exit with a non‑zero status
        ‑@  on systems that support it, present a file with extended attributes
            as a directory containing the file attributes
    
    The default is to follow symbolic links, as if ‑L' were specified.
    `..' is processed by removing the immediately previous pathname component
    back to a slash or the beginning of DIR.
    
    Exit Status:
    Returns 0 if the directory is changed, and if $PWD is set successfully when
    ‑P is used; non‑zero otherwise.

Other documentation sources

In addition to manual pages accessible from a command line, the Free Software Foundation has created a number of info files that are processed with the info program. These provide extensive navigation facilities including the ability to jump to other sections. Try man info or info info for more information. Not all commands are documented with info, so you will find yourself using both man and info if you become an info user.

There are also some graphical interfaces to man pages, such as xman (from the XFree86 Project) and yelp (the Gnome 2.0 help browser).

If you can't find help for a command, try running the command with the --help option. This may provide the command's help, or it may tell you how to get the help you need.