This lesson discusses more programming concepts. We will cover a
few of them.Objectives important to this lesson:
Flowcharts and pseudocode
Loading Bash in a script
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 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.
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.)
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:
#!/bin/bash
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:
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 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
AND
-a
OR
-o
NOT
!
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.
Assignment: Complete and submit the discussion board
assignment, and the test for module 7.
Once you are on the mail
page, find the