by Ed Treijs

IN THIS CHAPTER

• How Linux Commands Work

• Notational Conventions Used to Describe Linux Commands

• Online Help Available in Linux

• The Linux Man Pages

• Wildcards: * and ?

• Environment Variables

• Processes and How to Terminate Them

• Becoming Someone Else: The su Command

• The grep Command

In this chapter, we will discover the following:

• How to modify the basic function of Linux commands by using command options

• How to run two or more Linux commands in tandem by using input and output redirection

• How to use parameters, such as filenames, with Linux commands

• How to read and understand the notational shorthand used in Linux and UNIX documentation

• How to use Linux online man pages and help facilities

• How to use wildcards that fill in for one or more filenames

• How to check your environment variables

• How to list processes running on the Linux system

• How to kill processes

• How to temporarily become another user

• How to use grep (and understand what grep means!)

Most Linux commands are very flexible. When you enter a Linux command, there are several ways to tailor the basic command to your specific needs. We will look at the two main ways used to modify the effect of a command:

• Specifying or redirecting a command's input and output

• Using command options

A simple way to picture what a Linux command does is to imagine that it's a black box that is part of an assembly line. Items come down a conveyor belt, enter the black box, get processed in some way, come out of the black box, and are taken away on another conveyor belt. Command options let you fine-tune the basic process happening inside the black box. Command redirection lets you specify which conveyor belt will supply the black box with items and which conveyor belt will take away the resulting products.

Once you understand how redirection and command options work, you will be able to (at least in principle) use any Linux or UNIX command. This is because UNIX was based on a few simple design principles. Commands, therefore, should work in consistent ways. Of course, UNIX has grown and changed over the years, and the design principles can sometimes get buried under all the changes. But they still make up the foundation, so that UNIX-based systems such as Linux are quite coherent and consistent in how they work.

You can use command options to fine-tune the actions of a Linux command. Quite often, a Linux command will do almost--but not quite--what you want it to do. Instead of making you learn a second command, Linux lets you modify the basic, or default, actions of the command by using options.

The ls command is an excellent, and useful, example of a command that has a great many options. The ls command lists the files found on the Linux system's hard drive. This sounds simple enough, doesn't it? Try entering the command

darkstar:~$ ls



darkstar:~$

Well, nothing much seemed to happen.

Now try typing ls -a. Type it exactly as listed. The space between ls and -a is necessary, and there must be no space between the - and the a.

darkstar:~$ ls -a

./ ../            .bash_history  .less   .lessrc     

What you have done is modified what ls does by adding a command option--in this case, -a. By default, ls lists only files whose names don't begin with a period. However, -a tells ls to list all files, even ones that begin with a period. (These are usually special files created for you by Linux.) At present, all the files in your directory start with a period, so ls by itself does not list any files; you must add -a to see the files you have at present.

The ls command has many more options. You can use more than one option at a time. For example, try typing ls -al:

darkstar:~$ ls -al

total 10

drwxr-xr-x   2 fido     users        1024 Dec 21 22:11 ./

drwxr-xr-x   4 root     root         1024 Dec 14 01:39 ../

-rw-r--r--   1 fido     users         333 Dec 21 22:11 .bash_history

-rw-r--r--   1 fido     users          34 Nov  23  1993 .less

-rw-r--r--   1 fido     users         114 Nov 23  1993 .lessrc

You now get a listing with many more details about the files. (These will be explained in Chapter 8, "File System.") The l option can be used by itself; ls -l will give detailed descriptions of files that don't begin with a period. Sometimes filenames are so long they don't fit on a single line. Linux simply wraps the remainder to the next line.

By default, ls lists files in alphabetical order. Sometimes you might be more interested in when a file was created or last modified. The t option tells ls to sort files by date instead of alphabetically by filename, showing the newest files first. Therefore, typing ls -alt gives

darkstar:~$ ls -alt

total 10

drwxr-xr-x   3 fido     users        1024 Jan  2 13:48 ./

-rw-r--r--   1 fido     users         333 Dec 21 22:11 .bash_history

drwxr-xr-x   6 root     root         1024 Dec 14 01:39 ../

-rw-r--r--   1 fido     users         114 Nov 23  1993 .lessrc

-rw-r--r--   1 fido     users          34 Nov 23  1993 .less

The r option tells ls to produce a reverse output. This is often used with the t option. The following is an example of what you might get if you entered ls -altr:

darkstar:~$ ls -altr

total 10

-rw-r--r--   1 fido     users          34 Nov 23  1993 .less

-rw-r--r--   1 fido     users         114 Nov 23  1993 .lessrc

drwxr-xr-x   6 root     root         1024 Dec 14 01:39 ../

-rw-r--r--   1 fido     users         333 Dec 21 22:11 .bash_history

drwxr-xr-x   3 fido     users        1024 Jan  2 13:48 ./

Many other options can be used with ls, although we have now tried the most commonly used ones. The important thing to remember is that you can usually customize a Linux command by using one or more command options.

Linux commands often use parameters that are not actual command options. These parameters, such as filenames or directories, are not preceded by a dash.

For instance, by default ls lists the files in your current directory. You can, however, tell ls to list the files in any other directory simply by adding the directory to the command line. For instance, ls /bin will list everything in the /bin directory. This can be combined with command options, so that ls -l /bin gives you detailed listings of the files in /bin. Try this. You will be impressed by the number of files in the /bin directory!

You can also specify ls to list information about any particular file by entering its filename. For instance, ls -la .lessrc gives detailed information only about the .lessrc file.

Many Linux commands let you specify which file or directory they are to act upon, as we saw with the example ls -l /bin earlier.

You can also "pipe" the output from a command so that it becomes another command's input. This is done by typing two or more commands separated by the | character. (This character normally is found on the same key as the \ character. You must hold down the Shift key or you will get \ instead of |.) The | character means "Use the output from the previous command as the input for the next command." Therefore, typing command_1|command_2 does both commands, one after the other, before giving you the results.

Using our assembly-line metaphor, we are processing items through two black boxes instead of just one. When we use piping, it's like hooking up the first command's output conveyor belt to become the input conveyor belt for the second command.

You will have noticed that the output of ls -l /bin is many lines long, so that much of the information scrolls off the screen before you can read it. You can pipe this output to a formatting program called more, which displays information in screen-sized chunks. When you enter ls -l /bin | more, you will see the following:

darkstar:~$ ls -l /bin | more

total 1611

-rwxr-xr-x   1 root     bin          1248 Sep 17 04:25 arch*

-rwxr-xr-x   1 root     bin        295940 Sep  5 01:45 bash*

-rwxr-xr-x   1 root     bin          4840 Nov 24  1993 cat*

-rwxr-xr-x   1 root     bin          9220 Jul 20 12:06 chgrp*

-rwxr-xr-x   1 root     bin         13316 Jul 20 12:06 chmod*

-rwxr-xr-x   1 root     bin         13316 Jul 20 12:06 chown*

lrwxrwxrwx   1 root     root           17 Dec  7 13:37 compress -> /usr/bin/comp

ress*

-rwxr-xr-x   1 root     bin         21508 Jul 20 12:06 cp*

-rwxr-xr-x   1 root     bin         41988 May  1  1994 cpio*

lrwxrwxrwx   1 root     root            4 Dec  7 13:40 csh -> tcsh*

-rwxr-xr-x   1 root     bin          5192 Nov 24  1993 cut*

-rwxr-xr-x   1 root     bin         19872 Mar 23  1994 date*

-rwxr-xr-x   1 root     bin         17412 Jul 20 12:06 dd*

-rwxr-xr-x   1 root     bin         13316 Jul 20 12:06 df*

-rwxr-xr-x   1 root     bin         66564 Jun  9  1994 dialog*

-rwxr-xr-x   1 root     bin          1752 Sep 17 04:25 dmesg*

lrwxrwxrwx   1 root     root            8 Dec  7 13:37 dnsdomainname -> hostname*

-rwxr-xr-x   1 root     bin         13316 Jul 20 12:06 du*

-rwxr-xr-x   1 root     bin          3312 Mar 23  1994 echo*

-rwxr-xr-x   1 root     bin         36684 May  4  1994 ed*

-rwxr-xr-x   1 root     bin           326 Mar 23  1994 false*

--More--

The --More-- at the bottom of the screen tells you that there's more text to come. To go to the next screen of text, press the spacebar. Every time you press the spacebar, more displays another screenful of text. When the last screenful of text has been displayed, more returns you to the Linux prompt.

Another thing you can do in Linux is to send output to a file instead of the screen. There are many different reasons why you might want to do this. You might want to save a "snapshot" of a command's output as it was at a certain time, or you might want to save a command's output for further examination. You might also want to save the output from a command that takes a very long time to run, and so on.

To send output to a file, use the > symbol (found above the period on your keyboard). For instance, you can place the output of the ls -l /bin command into a file called test by typing ls -l /bin > test. Again, spaces around > are optional and not strictly necessary, but they do make the command much more readable.

If you now do an ls or ls -l, you will see that you've created a new file called test in your own directory.

To see the contents of a file, you can again use the more command. Just specify the name of the file you want to look at. In this case, you would type more test.

You can specify that you want to add your output to the end of the file, rather than replace the file's contents, by using >>. Type who >> test to add the output of the who command to the end of the text already in the file test.

You can examine the results by using either more or less and paging through to the end of the file, or by using the Linux command tail, which displays the last few lines of the specified file. In this case, you would type tail test to see the last few lines of the file test. Try using tail!

There is a set of accepted notational conventions used to describe, in a concise and consistent way, the correct syntax for any given Linux command. This specifies what options or parameters you must use, what options or parameters you can use or not use, and so on. Sometimes this set of conventions is used to give a complete and exhaustive listing of a command's syntax, showing every possible command and parameter. Sometimes it is used to make a particular example more general and the command's basic usage clearer.

If you remember the following five basic rules, you will be able, in principle, to understand the syntax of any Linux or UNIX command.

1. Any text standing by itself, and not within [], <>, or {}, must be typed exactly as shown.

2. Any text within square brackets ([]) is optional. You can type it or not type it. For instance, the syntax ls [-l] means you must type ls (per the first rule), while adding -l is optional, but not necessary. Do not type the square brackets themselves! In our example, type ls or ls -l. Don't type ls [-l].

3. Angle brackets (<>) and the text within them must be replaced by appropriate text (usually a name or value). The text within the brackets usually indicates the nature of the replacement. For instance, the syntax more <filename> means that you should replace <filename> with the name of the file you wish to examine using more. If you want to look at the file test, you would type more test. Remember, do not use the angle brackets when you actually type the command!

4. Curly braces ({}) indicate that you must choose one of the values given within the braces. The values are separated by | (which in this case means or, not pipe!). For example, the syntax command -{a|b} means you must enter either command -a or command -b.

5. An ellipsis (...) means "and so on." They are normally used with parameters such as filenames, as described later.

6. The sixth basic rule states that the brackets can be combined as necessary. For instance, you don't have to type a filename with the more command. This would be indicated as more [<filename>]. The outer set of square brackets makes the entire parameter optional. If you do decide to use the parameter, replace the inner set of angle brackets with the appropriate value. Because the more command enables one or more filenames to be specified, the syntax becomes more [<filename>...]. The ellipsis means you can have as many <filenames> as you want.

Linux has help facilities available online. If you forget the exact use of a command, or you're looking for the right command to use, the answer might be available straight from Linux. The two help facilities we will try out are the bash shell's help command, and the man command, which is available on almost all UNIX systems, including Linux.

The "man" in "man pages" stands for "manual." (As usual, the creators of UNIX shortened a long but descriptive word to a shorter, cryptic one!) Typing man <command> lets you view the manual pages dealing with a particular command.

Try typing man passwd to see what the Linux manual has to say about the passwd command.

The general layout of a man page is as follows:

Sometimes you know what you want to do, but you don't know which command you should use to do it. You can use the keyword option by typing man -k <keyword>. The man program will return the name of every command whose name entry (which includes a very brief description) contains that keyword.

For instance, you can search on manual:

darkstar:~$ man -k manual

man (1)              - format and display the on-line manual pages .br manpath--

		       determine user's search path for man pages

whereis (1)          - locate binary, spource, and manual page files for a command

xman (1)             - Manual page display program for the X Window System

You have to be careful to specify your keyword well, though! Using directory as your keyword isn't too bad, but using file will give you many more entries than you will want to wade through.

When you type a command at the prompt, the shell program takes what you've written, interprets it as necessary, and passes the result to the Linux operating system. Linux then performs the actions requested of it. Many Linux commands require Linux to find and start up a new program. However, the shell itself can perform a number of functions. These functions can be simple, often-used commands, so that the overhead of starting up separate programs is eliminated, or they can be facilities that make the shell environment friendlier and more useful. One of these facilities is the help command, which provides information on the bash shell's built-in functions.

Type help at the prompt. You will see at least some of the following:

GNU bash, version 1.14.7(1)

Shell commands that are defined internally. Type `help' to see this list.

Type `help name' to find out more about the function `name'.

Use `info bash' to find out more about the shell in general.



A star (*) next to a name means that the command is disabled.



%[DIGITS | WORD] [&]               . [filename]

:                                  [ arg... ]

alias [ name[=value] ... ]         bg [job_spec]

bind [-lvd] [-m keymap] [-f filena break [n]

builtin [shell-builtin [arg ...]]  case WORD in [PATTERN [| PATTERN].

cd [dir]                           command [-pVv] [command [arg ...]]

continue [n]                       declare [-[frxi]] name[=value] ...

dirs [-l]                          echo [-neE] [arg ...]

enable [-n] [name ...]             eval [arg ...]

exec [ [-] file [redirection ...]] exit [n]

export [-n] [-f] [name ...] or exp fc [-e name] [-nlr] [first] [last

fg [job_spec]                      for NAME [in WORDS ... ;] do COMMA

function NAME { COMMANDS ; } or NA getopts optstring name [arg]

hash [-r] [name ...]               help [pattern ...]

history [n] [ [-awrn] [filename]]  if COMMANDS; then COMMANDS; [elif

jobs [-lnp] [jobspec ...] | jobs - kill [-s sigspec | -sigspec] [pid

let arg [arg ...]                  local name[=value] ...

logout                             popd [+n | -n]

pushd [dir | +n | -n]              pwd

read [-r] [name ...]               readonly [-n] [-f] [name ...] or r

return [n]                         select NAME [in WORDS ... ;] do CO

set [--abefhknotuvxldHCP] [-o opti shift [n]

source filename                    suspend [-f]

test [expr]                        times

trap [arg] [signal_spec]           type [-all] [-type | -path] [name

typeset [-[frxi]] name[=value] ... ulimit [-SHacdmstfpnuv [limit]]

umask [-S] [mode]                  unalias [-a] [name ...]

unset [-f] [-v] [name ...]         until COMMANDS; do COMMANDS; done

variables - Some variable names an wait [n]

while COMMANDS; do COMMANDS; done  { COMMANDS }

You will have to pipe the output of help to more (help | more) to keep the first part from scrolling off your screen.

In many a late-night card game, jokers are shuffled into the deck. The jokers are wildcards that can become any card of your choice. This is obviously very useful! Linux has wildcards also. They are, if anything, more useful than jokers in a card game.

Linux has several wildcards. Wildcards are used as a convenient and powerful shortcut when specifying files (or directories) that a command is to operate on. We will briefly look at the two most popular wildcards: * and ?.

The most commonly used wildcard is *, which stands in for any combination of one or more characters. For example, c* will match all filenames that begin with c. You can see this for yourself by typing ls /bin/c*.

What happens if you type ls /bin/c*t? How about ls /bin/*t?

The ? wildcard is more restrictive than *. It only stands in for any one character. You can see this by comparing ls/bin/d* with ls/bin/d?.

When you log in, Linux keeps a number of useful data items in the background ready for the system to use. The actual data is held in something called an environment variable, whose name is often descriptive or mnemonic. In fact, this is no different from the way you and I remember things. We know that there always is a piece of information called "day of the week" (the environment variable); however, we change the data in this variable, from Monday to Tuesday to Wednesday, and so on, as days go by.

To see the list of exported environment variables, type env. The environment variable's name is on the left, and the value held by the variable is on the right.

The most important variable to note is the PATH, whose value is your search path. As we will see in the next chapter, when you type a command, Linux will search every place listed in your search path for that command.

A longer list of environment variables, consisting of several new variables in addition to the ones you saw earlier, is displayed by the command set. The new variables are local: they have not been marked for export. For more information on exporting variables, see Chapter 10. You can think of local variables as items of information you need for only a certain time or location. For instance, remembering the variable "what-floor-am-I-on" becomes an unnecessary piece of information once you leave the building!

In the previous chapter, we learned about the who command, which shows you the usernames of everyone who is logged into the system. The who program actually gets its information from the Linux system, which maintains and updates the list of the system's current users.

In fact, Linux keeps much more detailed records about what is happening on the system than just who is logged in. Because Linux is a multitasking system, in which many programs or program threads may be running simultaneously, Linux keeps track of individual tasks or processes.

Although these processes are usually well behaved and well managed by Linux, sometimes they might go out of control. This can happen if a program hits a bug or a flaw in its internal code or supplied data, or if you accidentally enter the wrong command or command option.

Being able to identify these misbehaving processes, and then being able to terminate or kill them, is an essential piece of knowledge for all Linux/UNIX users. (Obviously the world was a less kind and gentle place when the kill command was developed and named.) When you are your own system administrator, as in our case, it's doubly important!

To find out what processes are running, we use the ps command. ps stands for "process status," not the "post script" you would write at the end of a letter.

Typing ps by itself gives you a concise listing of your own processes:

darkstar:~$ ps

  PID TTY STAT  TIME COMMAND

   41 v01 S     0:00 -bash

  134 v01 R     0:00 ps

The information in the first column, headed PID, is important. This is the Process ID number, which is unique, and which Linux uses to identify that particular process. You must know a process's PID to be able to kill it.

The TTY column shows you which terminal the process was started from.

The STAT column gives the status of the process. The two most common entries in the status column are S for sleeping and R for running. A sleeping process is one that isn't currently active. However, don't be misled. A sleeping process might just be taking a very brief catnap! In fact, a process might switch between sleeping and running many times every second.

The TIME column shows the amount of system time used by the process. Clearly, neither of our processes are taking up any appreciable system time!

Finally, the NAME column contains the name of the program you're running. This will usually be the command you typed at the command line. However, sometimes the command you type starts one or more child processes, and in this case, you would see these additional processes show up as well, without ever having typed them yourself. Your login shell will have a - before it, as in -bash in the previous example. This helps to distinguish this primary shell from any shells you might enter from it. These will not have the - in front.

One useful option with ps is u. Although it stands for "user," as in "List the username as well," it actually adds quite a few more columns of information in addition to just the username:

darkstar:~$ ps -u

USER   PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND

fido    41  0.1  6.8  364  472 v01 S    23:19   0:01 -bash

fido   138  0.0  3.3   72  228 v01 R    23:34   0:00 ps -u

In addition to the username in the USER column, other interesting new items include %CPU, which shows you what percentage of your computer's processing power is being used by the process, and %MEM, which shows you what percentage of your computer's memory is being used by the process.

If you want to see all processes running on the system, and not just the processes started by your own username, you can use the a command option. (The root login sees everyone's processes automatically and does not have to use a, so root can get the following output by simply typing ps.)

darkstar:~$ ps -a

 PID  TTY STAT  TIME COMMAND

  62  v03 S     0:00 /sbin/agetty 38400 tty3

  63  v04 S     0:00 /sbin/agetty 38400 tty4

  64  v05 S     0:00 /sbin/agetty 38400 tty5

  65  v06 S     0:00 /sbin/agetty 38400 tty6

 330  v02 S     0:00 -bash

 217  v01 S     0:00 -bash

 217  v01 S     0:00 ps -a

As you can see, quite a few "other" processes are happening on the system! In fact, most of the processes we see here will be running whether or not anyone is actually logged into the Linux system. All the processes listed as running on tty psf are actually system processes, and are started every time you boot up the Linux system. Processes of the form /sbin/agetty 38400 tty6 are login processes running on a particular terminal waiting for your login.

It can be useful to combine the a and u options (if you're not root).

darkstar:~$ ps -au

USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND

root        72  0.0  3.6  390  532 v01 S    17:55   0:01 -bash

root        74  0.0  1.5   41  224 v03 S    17:55   0:00 /sbin/agetty 38400 tty3

root        75  0.0  1.5   41  224 v04 S    17:55   0:00 /sbin/agetty 38400 tty4

root        76  0.0  1.5   41  224 v05 S    17:55   0:00 /sbin/agetty 38400 tty5

root        77  0.0  1.5   41  224 v06 S    17:55   0:00 /sbin/agetty 38400 tty6

root        78  0.0  1.5   56  228 s00 S    17:55   0:00 gpm -t mman

root        98  0.0  1.5   41  224 v02 S    18:02   0:00 /sbin/agetty 38400 tty2

root       108 18.8  3.6  384  528 pp0 S    18:27   0:01 -bash

A more technical l option can sometimes be useful:

darkstar:~$ ps -l

 F    UID   PID  PPID PRI NI SIZE  RSS WCHAN      STAT TTY   TIME COMMAND

  0   501    41     1  15  0  364  472 114d9c     S    v01   0:00 -bash

  0   501   121    41  29  0   64  208 0          R    v01   0:00 ps -l

The interesting information is in the PPID column. PPID stands for "Parent Process ID"--in other words, the process that started the particular process. Notice that the ps -l command was started by -bash, the login shell. In other words, ps -l was started from the command line. Notice also that the PPID for the login shell is PID 1. If you check the output from ps -au above, you will see that the process with PID of 1 is init. The init process is the one that spawns, or starts, all other processes. If init dies, the system crashes!

The kill command is used to terminate processes that can't be stopped by other means.

1. Switch to another virtual console and log in as root.

2. Run ps -u and identify the offending process. You will use its PID in the next step.

3. Use the kill program by typing kill <PID>, where PID is the Process ID you want to kill. Make sure that you have correctly identified the offending process! As root, you can kill any user process, including the wrong one if you misread or mistype the PID.

4. Verify that the process has been killed by using ps -u again. You can type ps -u <PID>, which shows you the status of only the specified PID. If there's a null result and you're just given the Linux prompt again, the PID is dead, so go to step 8. However, it's best to look at the complete ps -u list if it's not too long. Sometimes the offending process reappears with a new PID! If that is the case, go to step 6.

5. If the process is still alive and has the same PID, use kill's 9 option. Type kill -9 <PID>. Check it as in step 4. If this does not kill the process, go to step 7. If the process is
now dead, go to step 8.

6. If the offending process has reappeared with a new PID, that means that it's being created automatically by some other process. The only thing to do now is to kill the parent process, which is the true offender! You might also have to kill the parent process when kill -9 does not work.

7. Use ps -l to identify the troublesome process's PPID. This is the PID of the parent process. You should check the parent's identity more closely by typing ps -u <Parent PID> before going ahead and killing it as described in step 3, using the PID of the parent in the kill command. You should follow through with step 4 and, if necessary, step 5, making sure the parent process has been killed.

8. The process is killed. Remember to log off. You should not leave root logged in on virtual consoles, because you will forget that the root logins are there!

Linux keeps ordinary users (as opposed to root) from killing other users' processes (maliciously or otherwise). For instance, if you are an ordinary user and you try to kill the init process, which always has PID=1, you will see

darkstar:~$ kill 1

kill:  (1) - Not owner

Actually, not even root can kill the init process, although there is no error message. The init process is one of those "unkillable" processes discussed earlier, because it's such a key process. That's all for the best!

Usually, when you want to temporarily become a different user, you will simply switch to an- other virtual terminal, log in as the other user, log out when you're done, and return to your "home" virtual terminal. However, there are times when this is impractical or inconvenient. Perhaps all your virtual terminals are already busy, or perhaps you're in a situation (such as logged on via a telephone and modem) in which you don't have virtual terminals available.

In these cases, you can use the su command. "su" stands for "super user." If you type su by itself, you will be prompted for the root password. If you successfully enter the root password, you will see the root # prompt, and you will have all of root's privileges.

You can also become any other user by typing su <username>. If you are root when you type su <username>, you are not asked for that user's password since in principle you could change the user's password or examine all the user's files from the root login anyway. If you are an "ordinary" user trying to change to another ordinary user, you will be asked to enter the password of the user you are trying to become.

"What on earth does grep mean?" you ask.

This is a fair question. grep must be the quintessential UNIX acronym, because it's impossible to understand even when it's spelled out in full!

grep stands for Global Regular Expression Parser. You will understand the use of this command right away, but when "Global Regular Expression Parser" becomes a comfortable phrase in itself, you should probably consider taking a vacation.

What grep does, essentially, is find and display lines that contain a pattern that you specify. There are two basic ways to use grep.

The first use of grep is to filter the output of other commands. The general syntax is <command> | grep <pattern>. For instance, if we wanted to see every actively running process on the system, we would type ps -a | grep R. In this application, grep passes on only those lines that contain the pattern (in this case, the single letter) R. Note that if someone were running a program called Resting, it would show up even if its status were S for sleeping, because grep would match the R in Resting. An easy way around this problem is to type grep " R ", which explicitly tells grep to search for an R with a space on each side. You must use quotes whenever you search for a pattern that contains one or more blank spaces.

The second use of grep is to search for lines that contain a specified pattern in a specified file. The syntax here is grep <pattern> <filename>. Be careful. It's easy to specify the filename first and the pattern second by mistake! Again, you should be as specific as you can with the pattern to be matched, in order to avoid "false" matches.

By this point you should have tried enough different Linux commands to start getting familiar (if not yet entirely comfortable) with typical Linux usage conventions.

It is important that you be able to use the man pages provided online by Linux. A very good exercise at this point is to pull up man pages for all the commands we have looked at in the past two chapters: login, passwd, who, adduser, and so on. If some of the commands listed under "See also:" look interesting, by all means take a look at their man pages too!

In Chapter 8, we head out from "home" and poke around in the Linux file system. As system administrators, we should know what our hard drives contain! For instance, there are special "administrator-only" directories crammed with goodies.