LUX 205 - Introduction to LINUX/UNIX

Chapter 7, Advanced Shell Programming, part 2

Objectives:

This lesson continues our discussion of programming concepts in chapter 7. Objectives important to this lesson:

  1. Flowcharts and pseudocode
  2. Saving the results of a command in a variable
  3. Functions in a script, and on the command line
Concepts:

OpenBakermailLinkAs part of the assignment for this chapter, we will be doing more flowcharting, I am repeating images on this page from the previous lesson to remind you how to access the Lucid Chart graphic tools. The image on the right reminds you to start in BakerMail, and the image below indicates the icon to click in your browser to get to Lucid Charts.

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.

Example:

Click Lucid ChartTODAY=`date`
CLEAR=`clear`
export TODAY; export CLEAR

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:

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. 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:

  • Make sure to assign execute permissions to the script
  • Call the shell on the first line of the script
  • 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