This lesson continues our discussion of programming concepts
in chapter 7. Objectives important to this lesson:
Running scripts faster
Passing arguments to a script on the command line
Functions in scripts
Passing arguments to functions in a script
Using grep
Concepts:
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. (Did you start the script before midnight?
Will it run past midnight?) 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.
This may be a good place to review several keys to writing and
running a script. You need to grant permissions to run a script
to the people who will run it. And you can either ask the user
for data, or expect them to offer it as arguments on the command
line. Let's look at this example.
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 (call 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:
function_name
()
{ command
line 1 command
line 2
}
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.
$0 holds the name of the script itself.
The video below shows us a script that uses arguments passed to
a function that is called three times, passing new arguments
each time.
I think the author forgot 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 the author discusses a
function 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:
Make sure to assign execute permissions to the script
Call the shell on the first line of the script with a
shebang
Proof read for typing errors
Don't confuse single, double, and back quotes
Use pairs of quotes, whichever ones you are using
Make sure your loops are entered and exited when
appropriate, and that they run the correct number of times
Before we go, the homework for this week is an exploration of
grep, among other things. Let's remember a few things about
grep.
