LUX 205 - Introduction to LINUX/UNIX

Chapter 7, Advanced Shell Programming

Objectives:

This lesson discusses more programming concepts. We will cover a few of them. Objectives important to this lesson:

1. Flowcharts and pseudocode
   
2. Loading Bash in a script
3. operating system utilities
   

Concepts:

The chapter begins with advice about planning a program with a flow chart and pseudocode. Both are good ideas, and both need a little discussion to set rules about how strictly you are going to adhere to standards. Your text shows an example flowchart on page 341. This is a flowchart for a script we saw in chapter 6.

The "boxes" that represent the commands in the script file are oddly shaped if you have never seen them before, but the meaning of each shape is explained in the graphic on page 342. The text shows twelve separate shapes for various kinds of actions that the script might take, and arrows to show the flow from one object to another. The shapes you use in a flow chart provide meaning that would otherwise have to be explained by the text that you write in those shapes. There are more standard shapes that you might use, some of which are explained on this web page from the Lucid Chart company. To choose the right shape, you need to know what they stand for, and what you want to do in each command in your script.

All of the symbols in the example flowchart on page 341 are available to Baker students in Lucid Charts. To use Lucid Charts, sign in to MyBaker, then open BakerMail, as shown in the image on the right.

Once you are on the mail page, find the Google Apps icon on the right side of the screen. (It looks like nine little squares in three rows of three. I have drawn a dark red ellipse around it in the image on the left.

Click it to open the Apps menu, then find and click the word More. There is another ellipse around it in the image on the on the left. You will see a few more icons. Find and click the one for Lucid Chart. It is orange, and is shown in the image on the right.

Once you have Lucid Chart open, you can start a new document, tell it you want to create a flowchart, and start planning a program or a shell script. Obviously, you can also use this tool to document an existing program or script.

If you did not have a drawing tool, or an understanding of the shapes in a flowchart, you might use pseudocode as your planning/documentation method. Pseudocode is a generic name for describing what a program does, step by step, in terms the end user might understand. Pseudocode can be used to plan the features of a program even if you do not yet know what language will be used to create that program.

In the example on page 343, the text shows us that the features of the example program can be described briefly, in less space than the real script requires, which is typical. Note that the person who wrote the pseudocode assumes that the person reading the pseudocode will understand an if structure and understand that veg_name is a variable. Even though this method is meant to be written plainly enough for end users to grasp, it is really meant to be a planning tool for one or more programmers, so some assumptions like the ones I mentioned are allowed.

We will move on to page 344. On that page, the text tells us something that should worry you. If you want to invoke a particular shell when you run a script, you can use something that is called by several names: hashbang, shebang, sha-bang, and others. Its purpose is to invoke a new shell for your program. Its syntax follows this model:

#!/bin/bash

This syntax should worry you because it appears that a command is embedded in a remark. That is actually true, but we are assured that the command is not for the interpreter, which would skip over that line. The command in this case is for the operating system, telling it to launch a new instance of the programmer's preferred shell. The path to that shell had better be correct, by the way, so make sure the shell you call is referenced by a valid pathname when you use a hashbang. (A # is a hashtag symbol, and some people call an exclamation point a bang, hence hashbang. That's a pretty bad name, but the other variants strike me as just lazy.) The text recommends that you place this (or its equivalent) as the first line in your scripts. You will then be using this as a means to call the needed shell at the beginning of a script, to avoid having to do it separately. In our versions of Fedora, it is not needed, since Bash is the default shell, but in other versions of Linux it might save a problem here and there.

There are several items following this section that don't have a lot of value. Let's move on to page 348, and examine the test command. The text shows us that the command has several switches that can be used to evaluate the existence of files and directories. It can be used to check the permissions on files as well. The next several pages in this chapter demonstrate other switches that can run other kinds of tests. In the example on pages 349 and 350, the text compares a Boolean test of equality in the entry condition of a do loop to the same condition being evaluated with the test command. Note that the syntax for the test command does not require square brackets, or quotation marks around the variable being evaluated.

In the discussion of the test command on page 350, the chapter introduces the idea of an exit status. In a way, it is like a temporary variable that you can access, providing you do it quickly. The example goes like this:

value=17
test $value -eq 17
echo $?
0

The first line sets a variable equal to 17. The second line tests whether that variable is actually equal to 17. You have done things like that before. The third line is the new item: we tell the interpreter to echo the value of ?. In this case, ? stands for the exit value of the last command, which was the result of the test. An exit value of 0 for a test command means the test was true. An exit value of 1 for a test command would mean that the test was false.

The following pages show how to use the test command to compare strings, as well as measuring their length, and how to conduct tests on files and directories. On page 353, the text tells us that we can combine the tests we run with the equivalent of Boolean AND, OR, and NOT operators. If you have never done this, first review the option switches on page 353 that stand for those three concepts:

Now consider the possibilities that the text brings up:

• if we test for the truth of expression1 AND expression2, the test will be true only if both of the expressions are true
• if we test for the truth of expression1 OR expression2, the test will be true if either of the expressions are true, and also true if both are true
• if we test for the truth of NOT expression1, the test will be true only if the expression itself is false