Concepts:The chapter begins with a few pages of foreshadowing, letting you know that you will be creating another application that will use variables, operators, and control structures. If this sounds mysterious, it actually is at this point in the chapter. All will be discussed in more detail in the pages that follow. On page 273, the text begins a general discussion of program development. The image on page 264 is a representation of several steps in one version of a program development cycle. The cycle is also frequently called a system development life cycle. There are multiple versions, some having more steps, and most of them are depicted as circles, not vertical flows. Why circles? No matter how good a system is, it should be reexamined from time to time, to determine if it needs updating, changing, improving, or replacing. Take a look at the images behind the link I just gave you. It leads to a Google search for images on the subject. What none of them seem to show is that you should check your results at each stage, and be ready to roll back to a previous stage in the cycle if a current problem requires redoing that earlier stage. In a short list, we might look at the cycle like this:
A shell script works by calling (running) operating system utilities that are already compiled, just as you have been doing from the command line in each of the first four chapters in this text. The commands in the script are not compiled. They are run by a command line interpreter, just as they would have been had you entered each of them at a command prompt. This covers most programs you will ever use: they are either compiled (translated into machine language and stored) or interpreted (translated one line at a time each time they are run). It should be no surprise that interpreted programs take longer to run, since each line must be translated into machine language before it is executed. The text explains on page 275 that, besides writing it and
troubleshooting it, there is another necessary step that makes a script
file a runnable program: setting permissions. The simplest way to make
sure that everyone can run the file is to make sure that all three
entity permissions are set to odd numbers. That guarantees that the
third bit in each "binary number" is turned on. The text offers three
ways to use the chmod command on page 276. Each example above uses a different notation.
The text continues to with a discussion that is a bit unclear.
To understand it, you have to know what the PATH variable does
on a system. PATH holds any number of pathnames to directories that are
likely to hold executable files. In the example below,
However you learn what this variable holds, you will see that it holds paths to folders that it has been told to search for executable files when they are called from the command line. If you save an executable file to one of those folders, then type the file's name at a command prompt, the file should run. The problem here is that you may not have write permissions for any of those folders. This leads to three ways mentioned in the text to execute a script file you have written.
The text suggests that you consider prototyping a program that you are working on. This really means to write a simplified version of the program first, show it to users, get useful feedback, and change the next iteration to include more features as well as corrections for any errors in the last iteration. The author points out that this can be done easily in a script, while doing so in a compiled language might take a lot more time and effort. When this is true, it will pay off by producing fast turnarounds between versions and easier improvements. Note, however, that you would still have to write the code for the program in a high level language, which introduces the risk of producing untested, error laden code. The text returns to the idea of using comments
as internal documentation of a file. This time we see an example on page
277 that shows one method for creating a comment. Placing a # in the
first position on any give line makes that line a comment. Any other
text on that line will not be read by the interpreter. If the
interpreter sees a # in the first position, it ignores everything else
on that line. The text offers suggestions about documentation that may
be useful, but its suggestions may not match your company's point of
view. We are advised, once again, that shell scripts can be written for any of the shells listed on page 278, but our author prefers the programming capacity of the Bash shell, so the examples in this text assume that Bash will be used to run them. The text begins a longer discussion on page 279 about three types of variables. If you are not a programmer, you should still have encountered variables in math classes. A variable can be thought of as a named location in memory that is meant to hold some numeric or alphanumeric value. The three types of variable that the text introduces:
The text suggests two ways to view variables. The printenv command, issued without arguments, will present a list of current configuration and environment variables and their values, as shown in the illustration on page 280. Notice that we can run the command with a list of variable names as arguments, which will then present only the variables we asked for. The second way to see variables is to use the set command. This command will report the configuration and environment variables, as well as any script variable that are loaded in memory. The text presents a list of configuration and environment variables on pages 281 through 283. This list also shows the purpose of the variables and whether they can be changed or set by the user. Page 284 offers ten guidelines about naming and using shell variables. Run through these advisories and discuss any that are unclear to you in the discussion board this week. The remainder of the chapter is a series of lessons to make
you a more capable shell script programmer. On page 285, we learn some
basic operators and operands in shell scripting. First,
the equal sign is used two different ways in shell scripting. The
difference between them is whether you space around the equal sign.
When we assign a value to a
variable, the text says we are defining
it. When using an equal sign to do this, the equal sign is an
assignment operator, and you must not put spaces before or after it.
For example: Look carefully at the third example on page 285. If you are
skimming the chapter, you might mistake the back quotes, also called an accents grave, for single quotes.
They are different and have a different purpose. This is important to know when you consider the information on
page 286. The text calls the $
an evaluating operator,
because when it occurs to the left of a variable's name, it means to
read and use the contents of the variable. Usually. The
examples there show what looks like the same command three ways. One of
them is different. In the first and second cases, the system would echo (print to the screen) the value of the variable called variablename. The value is whatever
is stored in the variable. The
reason the second case is shown to us is that
we need to know that we could have other words echoed to the screen and
that the value of the variable would still appear with them. Of course,
those other words could have been put in a quoted string by themselves,
but whatever... In the third case, the command would put the literal string enclosed in the single quotes on the screen. The system would not report the value of the variable. This allows us to put instructions on a screen that include phrases like $variablename. Farther down page 286, we learn that we have not been told the
whole truth about the equal sign yet. It has another use: a test of equality. When two phrases
(math or otherwise) are meant to be compared, they are put on each side
of an equal sign, but they must each be separated from the equal sign by a
space. Despite the appearance of the table of examples on page 286, do not put spaces around math operators if you want the computer to do math. The screen shot on page 287 is more accurate. let x=6+4*2 is a phrase that would assign the value 14 to the variable x. Spaces are not wanted or needed in a phrase like that, except immediately after the command let. Some of you will ask why it assigns 14 instead of 20. You will ask that if you don't know Aunt Sally. Computers typically follow an order of operations that follows the mnemonic phrase "Please excuse my dear Aunt Sally".
Following Aunt Sally's order of operations, the computer would multiply 4 times 2, then add 6 to the result, then assign the answer to x. 14, right? By the way, let is a command that says to do math in the next phrase. Without the let, the operation might have assigned a string to the variable. Let's move on to page 289, where we are introduced to the export command. The export command overcomes a problem that may not be a problem for you. The "problem" is that variables in a script are local to that script and cannot be seen by other scripts or the shell itself. The export command can promote a variable to global status, making it visible to the next script to run and to the shell. Note the variation of the set command on the previous page that can used to automatically make all variables global. This is a time saver if you need to use export frequently. Page 290 shows us a new wrinkle about the PATH variable.
Remember that it holds a list of paths to folders that contain
executable files? When you write a shell script, want to be able to
test it easily, so you may want to add a path to the current directory
to the PATH variable. This is a quick way to do that: The text reviews material we have seen about wildcard characters on page 291. With about twelve pages to go, the text turns to lessons about programming. There are three classic structures used in any program: sequence, selection, and iteration. There are variations in each type, as you will gather from this material. Sequential logic is a
fancy way of saying that a script runs the first line, then the second,
then the third, and so on until it ends. That is fine for simple
scripts, but sometimes you want the user or the situation to determine
that a particular set of statements
(lines of instructions) does not need to be run, or another set of
statements needs to run in a different order than the sequence that was
originally intended. This creates the need for selection, which our text calls decision logic. Making selections
typically involves a conditional operator like if
in the example on pages 293 and 294. In this example, the decision
structure asks the user for a response, compares the response to a
known value, then takes one action if the comparison is true and
another if it is false. The general structure would be like this: If begins the
structure, and fi ends it. The
test condition is
enclosed in square brackets,
and it is evaluated as being either true
or false.
This structure would only have two results, based on the condition
evaluation only having two possible outcomes. If more possibilities are
needed, a different selection structure might be used, or more if
structures could be nested in this structure. For some reason, the text does not discuss the other structure it presents, the case structure, until page 298. There we learn that a case structure can present a variety of possible values for a variable, an action to take if one of them has occurred, and a default action to take if there was no match. On page 295, the text begins a discussion of looping (iteration).
If you have written looping code before, the examples in the text may
look familiar to you, or they may seem very odd, depending on the
syntax you are used to. The text demonstrates a for loop and a while loop. The major thing that will determine which you want to use is how they run. A for loop will run a specific number of times, based on a known value, a variable's value, or a control string as shown in the first example. A while loop runs until a test condition becomes true, or becomes false, depending on the programmer's choice for a comparison test. In the example on page 297, the user is asked to input a choice, then the loop runs if the choice does not match a control value. Inside the loop, the user is asked for another choice, and the loop continues if the new choice is still incorrect. Before the chapter turns you loose on the projects, it describes a few more tools:
|
The text moves on to consider some
languages commonly used by programmers. COBOL is an old language, one
of the first high level languages, written by 