Chapter 5. Flow Control

5.1.1.1. Return

Getting back to our example: we save the exit status in both branches of the if, so that we can use it when we're done:

function pushd {                # push current directory onto stack
    dirname=$1
    if cd ${dirname:?"missing directory name."}   # if cd was successful
    then
        es=$?
        DIRSTACK="$dirname $DIRSTACK"
        print $DIRSTACK
    else
        es=$?
        print still in $PWD.
    fi
    return $es
}

The assignment es=$? saves the exit status of cd in the variable es; the last line returns it as the function's exit status.

5.1.1.2. Advanced example: overriding a built-in command

Using the exit status and the return command, and taking advantage of the shell's command search order, we can write a cd function that overrides the built-in command.

Suppose we want our cd function to print the old and new directories automatically. Here is a version to put in your .profile or environment file:

function cd {
        command cd "$@"
        es=$?
        print "$OLDPWD -> $PWD"
        return $es
}

This function relies on the search order for commands listed in the last chapter. cd is a non-special built-in command, which means that it's found after functions. Thus, we can name our function cd, and the shell will find it first.

But how do we get to the "real" cd command? We need it to do the actual changing of directories. The answer is the built-in command named, oddly enough, command. Its job is to do exactly what we need: skip any functions named by the first argument, instead finding the built-in or external command and running it with the supplied arguments. In the Korn shell, using command followed by one of the special built-in commands keeps errors in that command from aborting the script. (This happens to be mandated by POSIX.)

WARNING: The command built-in is not special. If you define a function named command, there's no way to get to the real one anymore (except by removing the function, of course).

5.1.1.3. Pipeline exit status

The exit status for a single command is just a simple number, whose value, as we've seen, is available in the special variable $?. But what about a pipeline? After all, you can hook an arbitrary number of commands together with pipes. Is the exit status of a pipeline that of the first command, the last command, or some command in between? By default, it is the exit status of the last command in the pipeline. (This is required by POSIX.)

5.1.1.4. Interpreting exit status values

For ksh93, the exit status values for built-in commands and several exceptional cases have been regularized as follows:

Value	Meaning
1-125	Command exited with failure
2	Invalid usage, with usage message (built-in commands)
126	Command found, but file is not executable
127	Command not found
128-255	External command exited with failure
256	Command died with a signal; subtract 256 to get signal number

5.1.4.1. String comparisons

Table 5-1. String comparison operators

function popd {        # cd to top, pop it off stack
    top=${DIRSTACK%% *}
    DIRSTACK=${DIRSTACK#* }
    cd $top
    print "$PWD"
}

If the stack is empty, $DIRSTACK is the null string, as is the expression ${DIRSTACK%% *}. This means that you will change to your home directory; instead, we want popd to print an error message and do nothing.

To accomplish this, we need to test for an empty stack, i.e., whether $DIRSTACK is null or not. Here is one way to do it:

function popd {                 # pop directory off the stack, cd there
    if [[ -n $DIRSTACK ]]; then
        top=${DIRSTACK%% *}
        DIRSTACK=${DIRSTACK#* }
        cd $top
        print "$PWD"
    else
        print "stack empty, still in $PWD."
        return 1
    fi
}

if [[ $DIRSTACK == "" ]]; then
        ...

[[...]] Versus the Test and [...] Commands We wrote our test [[ $DIRSTACK == "" ]]. This is not the correct usage for the older [...] or test syntax. In this syntax, which the Korn shell still supports, and which is all you have in the Bourne shell, if $DIRSTACK evaluates to the null string, the shell will complain about a missing argument. This leads to the requirement of enclosing both strings in double quotes ([ "$DIRSTACK" = "" ]), which is the most readable way to do it, or to the common hack of adding an extra character in front of the strings, like so: [ x$DIRSTACK = x ]. The latter works, since if $DIRSTACK is null, the [...] command only sees the two x characters, but it's not very obvious what's going on, especially to the novice. Also note that the the Korn shell's preferred operator is ==, while test requires a single = character.

if [[ -z $1 ]]; then
    print 'usage: highest filename [-N]'
    exit 1
fi
filename=$1
howmany=${2:-10}
sort -nr $filename | head -$howmany

5.1.4.2. About C compilers

Before we get to the shell code, it is necessary to understand a few things about C compilers. We already know that they translate C source code into object code. Actually, they are part of compilation systems that also perform several other tasks. The term "compiler" is often used instead of "compilation system," so we'll use it in both senses.

We can express all of these steps in terms of the suffixes of files passed as arguments to the C compiler. Basically, the compiler does the following:

Step 3 allows object code files that have already been compiled (or assembled) to be reused to build other executables. For example, an object code file that implements an interface to a CD-ROM drive could be useful in any program that reads from CD-ROMs.

Figure 5-1. Files produced by a C compiler

Here is how we would begin to implement this behavior in a shell script. Assume that the variable filename holds the argument in question, and that ccom is the name of the program that actually compiles a C source file into object code. Assume further that ccom and as (assembler) take arguments for the names of the source and object files:

if [[ $filename == *.c ]]; then
    objname=${filename%.c}.o
    ccom "$filename" "$objname"
elif [[ $filename == *.s ]]; then
    objname=${filename%.s}.o
    as "$filename" "$objname"
elif [[ $filename != *.o ]]; then
    print "error: $filename is not a source or object file."
    exit 1
fi
further processing ...

Recall from the previous chapter that the expression ${filename%.c}.o deletes .c from filename and appends .o; ${filename%.s}.o does the analogous thing for files ending in .s.

5.1.4.3. File attribute checking

Table 5-2. File attribute operators

function pushd {                # push current directory onto stack
    dirname=$1
    if [[ -d $dirname && -x $dirname ]]; then
        cd "$dirname"
        DIRSTACK="$dirname DIRSTACK"
        print "$DIRSTACK"
    else
        print "still in $PWD."
        return 1
    fi
}

Task 5-1 Write a script that prints essentially the same information as ls -l but in a more user-friendly way.

Although this task requires relatively long-winded code, it is a straightforward application of many of the file operators:

if [[ ! -e $1 ]]; then
    print "file $1 does not exist."
    return 1
fi
if [[ -d $1 ]]; then
    print -n "$1 is a directory that you may "
    if [[ ! -x $1 ]]; then
        print -n "not "
    fi
    print "search."
elif [[ -f $1 ]]; then
    print "$1 is a regular file."
else
    print "$1 is a special type of file."
fi
if [[ -O $1 ]]; then
    print 'you own the file.'
else
    print 'you do not own the file.'
fi
if [[ -r $1 ]]; then
    print 'you have read permission on the file.'
fi
if [[ -w $1 ]]; then
    print 'you have write permission on the file.'
fi
if [[ -x $1 && ! -d $1 ]]; then
    print 'you have execute permission on the file.'
fi

We'll call this script fileinfo. Here's how it works:

-rwxr-xr-x   1 billr    other        594 May 28 09:49 bob
-rw-r-r-     1 billr    other      42715 Apr 21 23:39 custom.tbl
drwxr-xr-x   2 billr    other         64 Jan 12 13:42 exp
-r-r-r-      1 root     other        557 Mar 28 12:41 lpst

custom.tbl and lpst are regular text files, exp is a directory, and bob is a shell script. Typing fileinfo bob produces this output:

bob is a regular file.
you own the file.
you have read permission on the file.
you have write permission on the file.
you have execute permission on the file.

Typing fileinfo custom.tbl results in this:

custom.tbl is a regular file.
you own the file.
you have read permission on the file.
you have write permission on the file.

Typing fileinfo exp results in this:

exp is a directory that you may search.
you own the file.
you have read permission on the file.
you have write permission on the file.

Finally, typing fileinfo lpst produces this:

lpst is a regular file.
you do not own the file.
you have read permission on the file.

5.1.4.4. Arithmetic conditionals

Table 5-3. Arithmetic test operators

You'll find these to be of the most use in the context of the numeric variables we'll see in the next chapter. They're necessary if you want to combine numeric tests with other types of tests within the same conditional expression.