Concepts:
Since we did this part last week. let's use the text space on this page
for some new material that doesn't need a graphic. The topic heading on page 355 only mentions one of several tips that page of advice covers. The point of the discussion there is that you can make some elements of a script run faster if you run a command with useful output once, and save that output in a script variable. This avoids two delays. The delay of running
the command a second time may not be much, but it exists. The time it
takes for the computer to search
for the command in all the folders listed in the PATH variable may be
the longer delay. (It's a computer. It doesn't remember where it found
the command the last time it found it.) The text's tip about saving the
output of the clear command and
the output of the date command
in separate variables will let your script simply echo
the content of those variables as needed, which will avoid each of the
expected delays each time your script subsequently needs those values.
This idea is only valid as long as you are not expecting the date or
the screen size to change while the script continues to run. Before using
a tip, ask yourself if the assumptions it is based on are valid. Note,
also, that in order to capture the output of these commands, you have
to run them at least once. Since that is the case, pick a good spot in
your program to do so. The text also reminds us of a trick that will extend this savings to
other scripts. Remember that script variables are local
to a script. That means that the variable and its contents are forgotten
when the script stops running, unless you export
the variable, making it available to other scripts you may run in the
same Linux session. This will come in handy for projects that use common
variables across several scripts.
Note, that you will have to create, assign values to, and export the variables
in the first script that runs
in the project in order to make use of the efficiency of this idea. The
nature of the script you are writing should dictate what other commands
might be handy to capture in variables for repeated use. Let's move to page 359 to discuss functions.
A function is a named set of commands. You name it so you can invoke
it wherever you need to run it in the course of a script. The example
on page 360 is rather silly. The author has created a function that runs
one command which is shorter than the name he gave it. The format for
this example, and for all functions you may use in a script, looks like
this: In this generic structure, I am showing you that a function must have a name, it must have parentheses that may (or may not) be empty, and it must contain one or more command lines to execute. The formal statement of the structure and commands in a function may be called the function definition. The second half of page 360 shows that you can create a function definition on a command line. In the example, the text shows us that when the operating system sees a function name that it does not know, it provides the opportunity (requires, it really) to enter a left curly brace, some number of command lines, and a right curly brace, which enables the function to be used. If we were defining our function in one of the C languages, we would have to state in the definition how many, and what kind of arguments this function is meant to accept. A shell based function is more open minded. The text explains that we can pass up to nine arguments to a function, then reference their values in the function's code as $1 for the contents of the first argument, $2 for the contents of the second argument, and so on through $9. I think the author has forgotten to revise his program in the discussion at the top of page 361. He is expecting the function to read and use the contents of the function's first argument when he has not told it to do so. The proper code for the function is in Project 7-16 at the end of the chapter. The text should probably have continued the lesson with a discussion
of writing a function in a script. The structure for a function in a script
is no different from the structure of a function entered on the command
line, so he contents himself with discussing it on a command line, which
may be distracting to the reader. The author then lists some functions
that he recommends for use in the phone list project he started earlier.
His general recommendation is to have a script full of useful functions
that runs when he logs in to his system. The author provides a list of troubleshooting techniques on pages 362 and 363. Review this list of advice, common typographical errors, and common logic errors. Among them are:
|
As
part of the assignment for this chapter, we will be doing more 