LPI Linux Certification in a Nutshell (18 page)

Sometimes you’ll want to run a program and send its output to a
file while at the same time viewing the output on the screen. The
tee
utility is helpful in this
situation.

Sometimes you need to pass a list of items to a command that is
longer than your shell can handle. In these situations, the
xargs
command can be used to break
down the list into smaller sublists.

tee

tee [
options
]
files

Read from standard input and write both to one or more
files
and to standard output (analogous
to a tee junction in a pipe).

Suppose you’re running a pipeline of commands
cmd1
,
cmd2
, and
cmd3
:

$
cmd1 | cmd2 | cmd3 > file1

This sequence puts the ultimate output of the pipeline into
file1
. However, you may also be interested in
the intermediate result of
cmd1
. To create a
new
file_cmd1
containing those results, use
tee
:

$
cmd1 | tee file_cmd1 | cmd2 | cmd3 > file1

The results in
file1
will be the same as
in the original example, and the intermediate results of
cmd1
will be placed in
file_cmd1
.

xargs

xargs [
options
] [
command
] [
initial-arguments
]

Execute
command
followed by its
optional
initial-arguments
and append
additional arguments found on standard input. Typically, the
additional arguments are filenames in quantities too large for a
single command line.
xargs
runs
command
multiple times to exhaust all
arguments on standard input.

Use
grep
to search a long list of files,
one by one, for the word “linux”:

$
find / -type f | xargs -n 1 grep -H linux

find
searches for normal files
(
-type f
) starting at the root directory.
xargs
executes
grep
once
for each of them due to the
-n 1
option.
grep
will print the matching line preceded by
the filename where the match occurred (due to the
-H
option).

Every program, whether it’s a command, application, or
script, that runs on your system is a
process
. Your
shell is a process, and every command you execute from the shell starts
one or more processes of its own (referred to as
child processes
). Attributes and
concepts associated with these processes include:

At any time, there could be tens or even hundreds of
processes running together on your Linux system. Monitoring these
processes is done using three convenient utilities:
ps
,
pstree
, and
top
.

Each process running on your system listens for
signals
, simple messages sent to the process either
by the kernel or by a user. The messages are sent through inter-process
communication. They are single-valued, in that they don’t contain
strings or
command
-
like constructs.
Instead, signals are numeric integer messages, predefined and known by
processes. Most have an implied action for the process to take. When a
process receives a signal, it can (or may be forced to) take
action.

For example, if you are executing a program from the command line
that appears to hang, you may elect to type
Ctrl-C to abort the program. This action actually sends an
SIGINT
(interrupt signal) to the process, telling
it to stop running.

There are more than 32 signals defined for normal process use in
Linux. Each signal has a name and a number (the number is sent to the
process; the name is only for our convenience). Many signals are used by
the kernel, and some are useful for users.
Table 6-7
lists popular signals
for interactive use.

As you can see from
Table 6-7
, some signals are
invoked by pressing well-known key combinations such as Ctrl-C and
Ctrl-Z. You can also use the
kill
command to send any message to a
running process. The
kill
command is implemented
both as a shell built-in command and as a standalone binary command. For
a complete list of signals that processes can be sent, refer to the file
/usr/include/bits/signum.h
on your
Linux install, which normally is installed with the
glibc-headers
package.

Occasionally, you’ll find a system showing symptoms of
high CPU load or one that runs out of memory for no obvious reason. This
often means an application has gone out of control on your system. You
can use
ps
or
top
to identify processes that may be
having a problem. Once you know the PID for the process, you can use the
kill
command to stop the process nicely with
SIGTERM
(
kill
-15
PID
), escalating the signal to
higher strengths if necessary until the process terminates.

Killing a process will also kill all of its child processes. For
example, killing a shell will kill all the processes initiated from that
shell, including other shells.

Linux and most modern Unix systems offer
job
control
, which is the ability of your shell (with support of
the kernel) to stop and restart executing commands, as well as place
them in the
background
where they can be
executed. A program is said to be in the
foreground
when it is attached to
your terminal. When executing in the background, you have no input to
the process other than sending it signals. When a process is put in the
background, you create a
job
. Each job is assigned
a job number, starting at 1 and numbering sequentially.

The basic reason to create a background process is to keep your
shell session free. There are many instances when a long-running program
will never produce a result from standard output or standard error, and
your shell will simply sit idle waiting for the program to finish.
Noninteractive programs can be placed in the
background
by adding a
&
character to the command. For example,
if you start
firefox
from the command
line, you don’t want the shell to sit and wait for it to terminate. The
shell will respond by starting the web browser in the background and
will give you a new command prompt. It will also issue the job number,
denoted in square brackets, along with the PID. For example:

$
/usr/bin/firefox &
[1]  1748

Here,
firefox
is started as a
background process. Firefox is assigned to job 1 (as denoted by
[1]
), and is assigned PID
1748
. If you start a program and forget the
&
character, you can still put it
in the background by first typing Ctrl-Z to stop it:

^Z
[1]+  Stopped      firefox

Then, issue the
bg
command to restart the job
in the background:

$
bg
[1]+ /usr/bin/firefox &

When you exit from a shell with jobs in the background, those
processes may die. The utility
nohup
can be used to protect the
background processes from the hangup signal
(
SIGHUP
) that it might otherwise receive when the
shell dies. This can be used to simulate the detached behavior of a
system daemon.

Putting interactive programs in the background can be quite
useful. Suppose you’re logged into a remote Linux system, running Emacs
in text mode. Rather than exit from the editor when you need to drop
back to the shell, you can simply press
Ctrl-Z
. This stops
Emacs, puts it in the background, and returns you to a command prompt.
When you are finished, you resume your Emacs session with the
fg
command, which puts your stopped job back into
the foreground.

Background jobs and their status can be listed by issuing the
jobs
command. Stopped jobs can be
brought to the foreground with the
fg
command and
optionally placed into the background with the Ctrl-Z and
bg
sequence.