Page 441
of the work is handed off to other commands; the shell just "glues" together results. This is typical, and a correct style you should adopt for your own scripting.
Certainly it was pleasant when the filenames changed and I realized I could rework one word of the script, rather than retyping the two hundred entries. As satisfying as this was, the total benefit of automation is still more profound. Even greater than saving my time are the improvements in quality, traceability, and reusability this affords. With the script, I control the data entering the database at a higher level and eliminate whole categories of error: mistyping, accidentally pushing a wrong button in a graphical user interface, and so on. Also, the script in Listing 22.1 records my procedure, in case it's later useful to audit the data. Suppose, for example, that next year it's decided I shouldn't have inserted any of these references to the database's Picture attribute. How many will have to be backed out? Useful answers—at most, the count of $DIR/*.jpg—can be read directly from the script; there's no need to rely on memory or speculate.
You're in charge of your career in automation. Along with everything else this chapter advises, you'll go farthest if you do the following:
These tips have specific meaning in the rest of this chapter. Look for ways to apply them in all that follows.
There are three important ways to improve your skill with these techniques, which apply equally well whether you're using Perl, cron, Expect, or another mechanism:
Documentation has the reputation of being dry and even unreadable. It's very important
you learn how to employ it. All the tools presented here have man pages, which you need to
be comfortable using. Read these documents and reread them. Authors of the tools faced many
of the challenges you do. Often, reading through the lists of options or keywords, you'll
realize that particular capabilities apply exactly to your situation. Study the
documentation with this in mind; look for the ideas that you can use. Give particular attention to commands you
don't recognize. If some of them—cu, perhaps, or
od—are largely superannuated, you'll realize
in reading about others—such as tput, ulimit,
bc, nice, or wait—that earlier users were
confronted with just the situations that confound your own work. Stand on their shoulders and see
farther.
Page 442
It's important to read good programming. Aspiring literary authors find inspiration in Pushkin and Pynchon, not grammar primers; similarly, you'll go farthest when you read the best work of the best programmers. Look in the columns of computer magazines and, most importantly, the archives of software with freely available source. Good examples of coding occasionally turn up in Usenet discussions. Prize these; read them and learn from the masters.
All the examples in this chapter are written to be easy to use. They typically do one small task completely; this is one of the best ways to demonstrate a new concept. Although exception handling, and argument validation in particular, is important, it is beyond the scope of this chapter.
Crystallize your learning by writing your own scripts. All the documents you read will make more sense after you put the knowledge in place with your own experience.
The other advice for those pursuing automation is to practice good engineering. This always starts with a clear, well-defined goal. Automation isn't an absolute good; it's only a method for achieving human goals. Part of what you'll learn in working through this chapter is how much, and how little, to automate.
When your goal is set, move as close to it as you can with components that are already written. "Glue" existing programs together with small, understandable scripting modules. Choose meaningful variable names. Define interfaces carefully. Write comments.
You already learned many of the elements of automation in Part IV, "System Administration and Management," particularly in Chapter 14, "Getting Started with Red Hat Linux"; and Appendix B supplements it. Let's look at a few additional examples of scripts that are often useful in day-to-day operation.
Users who maintain source code, client lists, and other records often want to launch a find-and-replace operation from the command line. It's useful to have a variant of chstr on UNIX hosts. Listing 22.2 gives one example.
Listing 22.2. chstr—a simple find-and-replace operation.
######## # # See usage() definition, below, for more details. # # This implementation doesn't do well with complicated escape # sequences. That has been no more than a minor problem in
Page 443
# the real world.
#
########
usage() {
echo \
"chstr BEFORE AFTER <filenames>
changes the first instance of BEFORE to AFTER in each line of <filenames>,
and reports on the differences.
Examples:
chstr TX Texas */addresses.*
chstr ii counter2 *.c"
exit 0
}
case $1 in
-h|-help) usage;;
esac
if test $# -lt 3
then
usage
fi
TMPDIR=/tmp
# It's OK if more than one instance of chstr is run simultaneously.
# The TMPFILE names are specific to each invocation, so there's
# no conflict.
TMPFILE=$TMPDIR/chstr.$$
BEFORE=$1
AFTER=$2
# Toss the BEFORE and AFTER arguments out of the argument list.
shift;shift
for FILE in $*
do
sed -e "s/$BEFORE/$AFTER/" $FILE >$TMPFILE
echo "$FILE:"
diff $FILE $TMPFILE
echo ""
mv $TMPFILE $FILE
done
Most interactive editors permit a form of global search-and-replace, and some even make it easy to operate on more than one file. Perhaps that's a superior automation for your needs. If not, chstr is a minimal command-line alternative that is maximally simple to use.
A question that arises frequently is how to automate retrieval of pages from the World Wide Web. This section shows the simplest of many techniques.