ITS 2310 - Linux I

Chapter 7, Advanced Shell Programming

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

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.

Flowchart Symbols

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 Lucidchart 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 Lucidcharts.To use Lucidcharts, first sign in to MyBaker, then open BakerMail.

Lucid Chart IconOnce 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.)

Find and click the icon for Lucidchart. It is orange, and is shown in the image on the right.

Once you have Lucidchart 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

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

If you would like a lesson on using Lucidchart, run through this short one that gives you an idea of what you can or should do.

We will move on to page 344. On that page, the text tells us something that should worry you. It's about a script convention that we talked about last week. 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:


This syntax could 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 path name 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 some distros, it would not be needed, since bash is the default shell, but in other versions of Linux it might avoid 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:

test $value -eq 17
echo $?

The first line sets a variable equal to 17. The second line tests whether that variable is actually equal to 17. You may 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:

Boolean Operator
test switch

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

That is enough material from this chapter for the moment. If you would like more material to use in a script, play this one when you have a few minutes. It takes a while, but his lesson is a good one.