This section describes another of the more unusual commands in the shell: eval. Its format is as follows:

eval command-line

where command-line is a normal command line that you would type at the terminal. When you put eval in front of it, however, the net effect is that the shell scans the command line twice before executing it.^[1] For the simple case, this really has no effect:

$ eval echo hello
hello
$

But consider the following example without the use of eval:

$ pipe="|"
$ ls $pipe wc -l
|: No such file or directory
wc: No such file or directory
-l: No such file or directory
$

Those errors come from ls. The shell takes care of pipes and I/O redirection before variable substitution, so it never recognizes the pipe symbol inside pipe. The result is that the three arguments |, wc, and -l are passed to ls as arguments.

Putting eval in front of the command sequence gives the desired results:

$ eval ls $pipe wc –l
     16
$

The first time the shell scans the command line, it substitutes | as the value of pipe. Then eval causes it to rescan the line, at which point the | is recognized by the shell as the pipe symbol.

The eval command is frequently used in shell programs that build up command lines inside one or more variables. If the variables contain any characters that must be seen by the shell directly on the command line (that is, not as the result of substitution), eval can be useful. Command terminator (;, |, &), I/O redirection (<, >), and quote characters are among the characters that must appear directly on the command line to have any special meaning to the shell.

For the next example, consider writing a program last whose sole purpose is to display the last argument passed to it. You needed to get at the last argument in the mycp program in Chapter 10, “Reading and Printing Data.” There you did so by shifting all the arguments until the last one was left. You can also use eval to get at it as shown:

$ cat last
eval echo $$#
$ last one two three four
four
$ last *                        Get the last file
zoo_report
$

The first time the shell scans

echo $$#

the backslash tells it to ignore the $ that immediately follows. After that, it encounters the special parameter $#, so it substitutes its value on the command line. The command now looks like this:

echo $4

(the backslash is removed by the shell after the first scan). When the shell rescans this line, it substitutes the value of $4 and then executes echo.

This same technique could be used if you had a variable called arg that contained a digit, for example, and you wanted to display the positional parameter referenced by arg. You could simply write

eval echo $$arg

The only problem is that just the first nine positional parameters can be accessed this way; to access positional parameters 10 and greater, you must use the ${n} construct:

eval echo ${$arg}

Here's how the eval command can be used to effectively create “pointers” to variables:

$ x=100
$ ptrx=x
$ eval echo $$ptrx               Dereference ptrx
100
$ eval $ptrx=50                  Store 50 in var that ptrx points to
$ echo $x                        See what happened
50
$

If you submit a command line to the background for execution, that command line runs in a subshell independent of your current shell (the job is said to run asynchronously). At times, you may want to wait for the background process (also known as a child process because it's spawned from your current shell—the parent) to finish execution before proceeding. For example, you may have sent a large sort into the background and now want to wait for the sort to finish because you need to use the sorted data.

The wait command is for such a purpose. Its general format is

wait process-id

where process-id is the process id number of the process you want to wait for. If omitted, the shell waits for all child processes to complete execution. Execution of your current shell will be suspended until the process or processes finish execution. You can try the wait command at your terminal:

$ sort big-data > sorted_data &           Send it to the background
[1] 3423                                  Job number & process id from the shell
$ date                                    Do some other work
Wed Oct  2 15:05:42 EDT 2002
$ wait 3423                               Now wait for the sort to finish
$                                         When sort finishes, prompt is returned

wait $!

prog1 &
pid1=$!
...
prog2 &
pid2=$!
...
wait $pid1          # wait for prog1 to finish
...
wait $pid2          # wait for prog2 to finish

When you press the Delete^[2] or Break key at your terminal during execution of a shell program, normally that program is immediately terminated, and your command prompt returned. This may not always be desirable. For instance, you may end up leaving a bunch of temporary files that won't get cleaned up.

The pressing of the Delete key at the terminal sends what's known as a signal to the executing program. The program can specify the action that should be taken on receipt of the signal. This is done with the trap command, whose general format is

trap commands signals

where commands is one or more commands that will be executed whenever any of the signals specified by signals is received.

Numbers are assigned to the different types of signals, and the more commonly used ones are summarized in Table 13.1. A more complete list is given under the trap command in Appendix A, “Shell Summary.”

As an example of the trap command, the following shows how you can remove some files and then exit if someone tries to abort the program from the terminal:

trap "rm $WORKDIR/work1$$ $WORKDIR/dataout$$; exit" 2

From the point in the shell program that this trap is executed, the two files work1$$ and dataout$$ will be automatically removed if signal number 2 is received by the program. So if the user interrupts execution of the program after this trap is executed, you can be assured that these two files will be cleaned up. The exit that follows the rm is necessary because without it execution would continue in the program at the point that it left off when the signal was received.

Signal number 1 is generated for hangup: Either someone intentionally hangs up the line or the line gets accidentally disconnected. You can modify the preceding trap to also remove the two specified files in this case by adding signal number 1 to the list of signals:

trap "rm $WORKDIR/work1$$ $WORKDIR/dataout$$; exit"  1 2

Now these files will be removed if the line gets hung up or if the Delete key gets pressed.

The commands specified to trap must be enclosed in quotes if they contain more than one command. Also note that the shell scans the command line at the time that the trap command gets executed and also again when one of the listed signals is received. So in the preceding example, the value of WORKDIR and $$ will be substituted at the time that the trap command is executed. If you wanted this substitution to occur at the time that either signal 1 or 2 was received (for example, WORKDIR may not have been defined yet), you can put the commands inside single quotes:

trap 'rm $WORKDIR/work1$$ $WORKDIR/dataout$$; exit'  1 2

The trap command can be used to make your programs more user friendly. In the next chapter, when we revisit the rolo program, the signal generated by the Delete key is caught by the program and brings the user back to the main menu. In this way, this key can be used to abort the current operation without exiting from the program.

$ trap 'echo logged off at $(date) >>$HOME/logoffs' 0
$ trap                            List changed traps
trap – 'echo logged off at $(date) >>$HOME/logoffs' EXIT
$ Ctrl+d                           Log off
login: steve                      Log back in
Password:
$ cat $HOME/logoffs               See what happened
logged off at Wed Oct  2 15:11:58 EDT 2002
$

trap "" 2

trap 2

trap "" 2

trap : 2

trap 1 2

You know about the standard constructs <, >, and >> for input redirection, output redirection, and output redirection with append, respectively. You also know that you can redirect standard error from any command simply by writing

command 2> file

Sometimes you may want to explicitly write to standard error in your program. You can redirect the standard output for a command to standard error by writing

command >&  2

The notation >& specifies output redirection to a file associated with the file descriptor that follows. File descriptor 0 is standard input, descriptor 1 is standard output, and descriptor 2 is standard error. Note that no space is permitted between the > and the &.

So to write an error message to standard error, you write

echo "Invalid number of arguments" >&  2

Frequently, you may want to collect the standard output and the standard error output from a program into the same file. If you know the name of the file, this is straightforward enough:

command >foo 2>>foo

Here, both the standard output and the standard error output from command will be written to foo.

You can also write

command >foo 2>&1

to achieve the same effect; standard output is redirected to foo, and standard error is redirected to standard output (which has already been redirected to foo). Note that because the shell evaluates redirection from left to right on the command line, the last example cannot be written

command 2>&1 > foo

because this would first redirect standard error to standard output (your terminal by default) and then standard output to foo.

You recall that you can also dynamically redirect standard input or output in a program using the exec command:

exec < datafile

redirects standard input from the file datafile. Subsequent commands executed that read from standard input will read from datafile instead. The command

exec > /tmp/output

does the same thing with standard output: All commands that subsequently write to standard output will write to /tmp/output (unless explicitly redirected elsewhere). Naturally, standard error can be reassigned this way as well:

exec 2> /tmp/errors

Here, all output to standard error will go to /tmp/errors.

ls >&-

$ wc <&-
      0   0   0
$

command <<word

$ wc -l <<ENDOFDATA            Use lines up to ENDOFDATA as standard input
> here's a line
> and another
> and yet another
> ENDOFDATA
      3
$

$ cat mailmsg
mail $* <<END-OF-DATA

Attention:

Our monthly computer users group meeting
will take place on Friday, October 4, 2002 at
8am in Room 1A-308. Please try to attend.

END-OF-DATA
$

mailmsg $(cat users_list)

$ cat <<FOOBAR
> $HOME
> *****
>     $foobar
> `date`
> FOOBAR                     Terminates the input
/users/steve
*****
    $foobar
Wed Oct  2 15:23:15 EDT 2002
$

$ cat <<FOOBAR
> \\
> `date`
> $HOME
> FOOBAR
\\
`date`
$HOME
$

$ cat <<-END
>           Indented lines
>           So there you have it
> END
Indented lines
So there you have it
$

$ cat rolosubs
#
# Archived programs used by rolo.
#

echo Extracting lu
cat >lu <<THE-END-OF-DATA
#
# Look someone up in the phone book
#

if [ "$#" -ne 1 ]
then
        echo "Incorrect number of arguments"
        echo "Usage: lu name"
        exit 1
fi

name=$1
grep "$name" $PHONEBOOK

if [ $? -ne 0 ]
then
        echo "I couldn't find $name in the phone book"
fi
THE-END-OF-DATA

echo Extracting add
cat >add <<THE-END-OF-DATA
#
# Program to add someone to the phonebook file
#

if [ "$#" -ne 2 ]
then
        echo "Incorrect number of arguments"
        echo "Usage: add name number"
        exit 1
fi

echo "$1    $2" >> $PHONEBOOK
sort -o $PHONEBOOK $PHONEBOOK
THE-END-OF-DATA

echo Extracting rem
cat >rem <<THE-END-OF-DATA
#
# Remove someone from the phone book
#

if [ "$#" -ne 1 ]
then
        echo "Incorrect number of arguments"
        echo "Usage: rem name"
        exit 1
fi

name=$1

#
# Find number of matching entries
#

matches=$(grep "$name" $PHONEBOOK | wc –l)

#
# If more than one match, issue message, else remove it
#

if [ "$matches" -gt 1 ]
then
        echo "More than one match; please qualify further"
elif [ "$matches" -eq 1 ]
then
        grep -v "$name" $PHONEBOOK > /tmp/phonebook
        mv /tmp/phonebook $PHONEBOOK
else
        echo "I couldn't find $name in the phone book"
fi
THE-END-OF-DATA
$

$ mail [email protected] < rolosubs             Mail the archive
$ mail [email protected]                        Mail tony a message
Tony,
     I mailed you a shell archive containing the programs
     lu, add, and rem. rolo itself will be sent along shortly.
Pat
Ctrl+d
$

$ sh rolosubs
Extracting lu
Extracting add
Extracting rem
$ ls lu add rem
add
lu
rem
$

$ cat shar
#
# Program to create a shell archive
# from a set of files
#

echo "#"
echo "# To restore, type sh archive"
echo "#"

for file
do
   echo
   echo "echo Extracting $file"
   echo "cat >$file <<THE-END-OF-DATA
   cat $file
   echo "THE-END-OF-DATA"
done

The POSIX standard shell supports the concept of functions; note that older shells may not support this feature.

To define a function, you use the general format:

name () { command; ... command; }

where name is the name of the function, the parentheses denote to the shell that a function is being defined, and the commands enclosed between the curly braces define the body of the function. These commands will be executed whenever the function is executed. Note that at least one whitespace character must separate the { from the first command, and that a semicolon must separate the last command from the closing brace if they occur on the same line.

The following defines a function called nu that displays the number of logged-in users:

nu () { who | wc -l; }

You execute a function the same way you execute an ordinary command: simply by typing its name to the shell:

$ nu
     22
$

Arguments listed after the function on the command line are assigned to the positional parameters $1, $2, ..., just as with any other command. Here's a function called nrrun that runs tbl, nroff, and lp on the file given as its argument:

$ nrrun () { tbl $1 | nroff -mm -Tlp | lp; }
$ nrrun memo1                     Run it on memo1
request id is laser1-33 (standard input)
$

Functions exist only in the shell in which they're defined; that is, they can't be passed down to subshells. Further, because the function is executed in the current shell, changes made to the current directory or to variables remain after the function has completed execution:

$ db () {
>       PATH=$PATH:/uxn2/data
>       PS1=DB:
>       cd /uxn2/data
>       }
$ db                               Execute it
DB:

As you see, a function definition can continue over as many lines as necessary. The shell displays your secondary command prompt until you close the definition with the }.

You can put definitions for commonly used functions inside your .profile so that they'll be available whenever you log in. Alternatively, you can group the definitions in a file, say myfuncs, and then execute the file in the current shell by typing

. myfuncs

This has the effect of causing any functions defined inside myfuncs to be read in and defined to the current shell.

The following function, called mycd, takes advantage of the fact that functions are run in the current environment. It mimics the operation of the Korn shell's cd command, which has the capability to substitute portions of the current directory's path with something else (see the discussion of cd in Chapter 15, “Interactive and Nonstandard Shell Features,” for more details).

$ cat myfuncs                      See what's inside
#
# new cd function:
#      mycd dir Switches dir
#      mycd old new  Substitute new for old in current directory's path
#
mycd ()
{
        if [ $# -le 1 ]
        then
                # normal case -- 0 or 1 argument
                cd $1
        elif [ $# -eq 2 ]
        then
                # special case -- substitute $2 for $1
                cd $(echo $PWD | sed "s|$1|$2|")
        else
                # cd can't have more than two arguments
                echo mycd: bad argument count
                exit 1
        fi
}

$ . myfuncs                   Read in definition
$ pwd
/users/steve
$ mycd /users/pat             Change directory
$ pwd                         Did it work?
/users/pat
$ mycd pat tony               Substitute tony for pat
$ pwd
/users/tony
$

After a function has been defined, its execution will be faster than an equivalent shell program file. That's because the shell won't have to search the disk for the program, open the file, and read its contents into memory.

Another advantage of functions is the capability to group all your related shell programs in a single file if desired. For example, the add, lu, and rem programs from Chapter 11, “Your Environment,” can be defined as functions inside rolo. The template for such an approach is shown:

$ cat rolo
#
# rolo program written in function form
#

#
# Function to add someone to the phonebook file
#

add () {
        # put commands from add program here
}

#
# Function to look someone up in the phone book
#

lu () {
        # put commands from lu program here
}

#
# Function to remove someone from the phone book
#

rem () {
        # put commands from rem program here
}

#
# rolo - rolodex program to look up, add, and
#        remove people from the phone book
#

# put commands from rolo here
$

None of the commands inside the original add, lu, rem, or rolo programs would have to be changed. These first three programs are turned into functions by including them inside rolo, sandwiched between the function header and the closing curly brace. Note that defining them as functions this way now makes them inaccessible as standalone commands.

$ unset –f nu
$ nu
sh: nu: not found
$

return n

When you type in the name of a command to execute, it's frequently useful to know where that command is coming from. In other words, is the command actually defined as a function? Is it a shell program? Is it a shell built-in? Is it a standard Unix command? This is where the type command comes in handy. The type command takes one or more command names as its argument and tells you what it knows about it. Here are some examples:

$ nu () { who | wc -l; }
$ type pwd
pwd is a shell builtin
$ type troff
troff is /usr/bin/troff
$ type cat
cat is /bin/cat
$ type nu
nu is a function
$