Volume Number: 21 (2005)
Issue Number: 10
Column Tag: Programming
by Edward Marczak
Carpenters shape wood. Fletchers shape arrows. Programmers shape code. So far, we've been apprentices in the mastery of bash scripting. This month, we'll take another step up that ladder, and learn how to make our code flow. In the ever-blurring distinction between programming and scripting, let's look at some of the bash shell's better programming conventions and statements.
I'm going to make several assumptions this month. Namely:
Not too rough, right? Good. Let's go.
Since bash is built-in to every OS X box, present and ready-to-go, it's a great tool for small, quick and dirty scripts, to more complex and full-featured (dare I say?) applications. While "application" may be a stretch, for any code to approach that, it has to be able to make decisions. The scripting 'techniques' presented thus far have really been pouring the foundation, which is important, but have really been little more than stringing commands together sequentially. Fine for basic automation, but limited in the grand scheme of things.
We need a way to introduce flow control into our code. This is a basic concept in all programming languages. Flow control is the classic, "if some condition exists, then follow these instructions." Or, "perform this set of statements x number of times." Of course, the syntax tends to be a little different between each language, and bash won't let you down. First, here's what bash gives us:
if/else is about as basic as it gets. When you need to decide if your code should, or should not do something, you use if/else. You've probably seen this before - even Excel's VBA has if tests! Here's where bash is different: most languages test for some true Boolean condition. bash's if tests exit codes. That's it. Lodge that in your brain and you'll save yourself grief later on.
Every Unix program returns a code, in the form of an integer in the range 0-255, to its parent process when it quits - the exit code. Here's where your brain may spin: 0 is (typically) the "OK" code, meaning success. So, in an if statement, an exit code of "0" means, "true, run this code." However, this is a de facto standard, and the meanings of exit codes are up to the programmer.
A better way to think of this is that of "exit success." So:
if some command was successful
then
do this bit of code
else
yell and scream
fi
bash uses the variable "?" to store exit status of the most recently run program. To illustrate, follow this example:
$ touch example.txt $ echo $? 0 $ grep asdf example.txt $ echo $? 1
"?" shows the exit codes. "touch example.txt" was successful; it returned a "0" exit code. grep, however, couldn't find the string "asdf" in example.txt, so it was unsuccessful, and handed us back a "1" exit code. Of course, we can use this in a script.
ping, like most utilities, will hand us back a "0" on success, and some value greater than zero if there's a problem. Here's a cheap-o host monitor script:
#!/bin/bash if ping -c 1 4.2.2.2 then logger -i -t pingscript Ping success else mail -s "Can't ping 4.2.2.2" support@example.com < pingerror.txt pagetech.sh fi
We try to ping a host at 4.2.2.2 (and if you're connected to the net, this should work). If the ping succeeds, we simply make a note of it. If the ping fails, we send mail to alert us to that fact, and run another script that pages a tech.
We can also test two conditions at a time with the "&&" (and) and "||" (or) operators. If we needed two pings to different hosts to succeed, we could use "&&". Changing our if line to read:
if ping 130.57.4.27 && ping 4.4.4.2
will run the first statement. Only if it succeeds do we even try the second. Both the first and the second statement must succeed to enter the "then" section of the if statement. You can do something similar outside of a script:
copyfile.sh && alterfile.sh && ftpfile.sh
This example will run three scripts in succession. The next in the series will only run if the previous script exited with a successful exit code.
The "||" operator runs the first statement, if it succeeds, statement 2 never runs, and we enter the then clause. If statement 1 fails, statement 2 does run. If it succeeds, we enter the then clause. Either statement's success will get us into the then clause. Consider revising our example:
if ping 130.57.4.27 || ping 4.2.2.2
Perhaps we're just trying to see if this machine is connected to the Internet. Say host 130.57.4.27 goes down. As long as we can still ping 4.4.4.2, this script doesn't send mail to us, or try to page someone.
if/then may be basic, but just this simple decision scheme alone can create powerful scripts. Let's make it more so. if/then is powerful, but testing exit codes alone can get tedious. The shell provides the test command to test various conditions. To make the command more concise and visually pleasing, [ is aliased to test. So this:
if test -e /bin/bash
is the same as this:
if [ -e /bin/bash ]
Most people use the [...] variant. I will do the same. When I say, "test", I'm referring to test or [. What can test check for us? The man page is of great use here, but I'll give an example or two:
File tests:
-e test for a file's existence, no matter the type.
-d test for a directory
String comparisons:
s1 = s2 string 1 is equal to string 2.
-n string is not null
Integer comparisons:
-lt less than
-eq equal
-ne not equal
Other notes for inside the brackets: you can use "!" to negate a test:
if [ ! -e ~/secretplans.txt ]
"And" and "or" are available within the brackets:
and: if [ -e /bin/bash -a -e /bin/false ]
or: if [ -e /bin/bash -o -e /bin/tcsh ]
...and don't forget that all of this can be combined:
if [ ! -d /Users/Shared/reports -o ! -e /nightly/`date +%Y%m%d`.txt ] && rsync -delete -av -e ssh repuser@host.example.com:reports/* /Users/Shared/reports ; then logger -t repsync Reports are current else logger -t repsync Reports are out of sync/missing fi
Whew! That is:
If the "reports" directory or the nightly file doesn't exist, we try to rsync them. If that goes well, success all around. If the directory or file do exist, we're done. If the rsync fails, we note it in the system log. That packs a lot in a single "if" statement.
If you're an old Pascal or C hand, you'll recognize these two constructs: while and until. For the uninitiated, while repeats a block of statements for the duration of a condition being true. until runs a block of code until a condition is met. One look at them in action, and you'll get it:
while [ -e /run/statusflag.txt ] do copyfiles.sh sleep 300 done
The until block is very similar:
until [ -e thecowscomehome.txt ] do jump_over_moon.sh done
Easy, right? Naturally, you can run all of the tests that the if statement allows.
Sometimes, either you or a variable know how many times a loop should run. (Does that make anyone else think of Tron?). The constructs of for and forelse allow us to do just this. This is where you'll see a lot of difference from traditional languages. While you can pull off those kinds of loops:
#!/bin/bash
for ((i=1;i<=10;i+=1))
do
echo $i
done
...you'll very rarely see that done in practice. What happens to be much cooler than this, though, is the ability to loop through file lists, directories and command line arguments passed to your script. This is truly, as the kids say, da bomb. Look at this simple example:
#!/bin/bash
for i in "*.sh"
do
echo $i
done
This script gives me something like this:
$ ./loopy.sh
backup.sh createdmg.sh fctest.sh it.sh loopy.sh speakdate.sh spread.sh syncsm.sh
Well, gosh, I could have simply used the one-line echo *.sh to achieve the same thing. How about something that gives us info on each file? Line by line output can be achieved in a few different ways, but here's the way I'm choosing, for the moment:
#!/bin/bash
FILES=`ls *.sh`
for i in $FILES
do
echo $i
if [ -O $i ]; then
echo "You own $i."
fi
if [ -G $i ]; then
echo "You are a group owner of $i."
fi
echo
done
Running the above gives me something akin to this:
$ ./loopy2.sh backup.sh You own backup.sh. You are a group owner of backup.sh. createdmg.sh You own createdmg.sh. fctest.sh You own fctest.sh. it.sh You own it.sh. Loopy2.sh You own loopy.sh. You are a group owner of loopy2.sh
As mentioned, for is a fantastic way for dealing with arguments passed into the script. Here's a slightly contrived example that will make a directory and copy the files and/or types (based on extension) into that directory. The new concept here are the parameter variables: @ and #. "$@" contains a list of each positional parameter, $1, $2...$N that is passed into the script. "$#" contains the number of parameters passed in. We can even include a little error correction this way:
#!/bin/bash
thedir=`date +%Y%m%d`
if [ $# -gt 0 ]; then
mkdir $thedir
for list in "$@"; do
cp $list $thedir
done
else
echo "usage: $0 (files)"
fi
Fun and functional! Right?
The last flow control statements we'll cover this month, case and select, bring their own power to bash, much like the previous flow control variants.
case is a neat alternative to a bevy of if/then/else statements. You immediately know the reason for this if you've used "case" in Pascal, or "switch" in C. If you've never seen those, one example and you'll be a pro:
#!/bin/bash
freespace=`df / | tail -1 | awk '{print $5}' | cut -d "%" -f1`
case $freespace in
[1-6]*) report="Plenty of room on /"
;;
[7-8]*) report="You might want to fire up du and take a look at /, it is $freespace percent full."
;;
9[0-9]) report="Can you order a bigger disk and overnight it? / is at $freespace percent!"
;;
*) report="I can't determine the amount of space on /"
;;
esac
echo $report
Of course, the power in the bash version lies in its ability to process patterns and command-line arguments:
#!/bin/bash
for file in $*; do
case $file in
*.txt) echo "$file is a text file."
;;
*.pl) echo "$file is a perl file."
;;
*.sh) echo "$file is a shell script."
;;
*.gif | *.png | *.jpg | *.jpeg | *.tiff) what=`sips -g format $file | tail -1`
echo "$file is a $what"
sizeh=`sips -g pixelHeight $file | tail -1`
sizew=`sips -g pixelWidth $file | tail -1`
echo "It is $sizew x $sizeh"
;;
*.aiff | *.sd2 | *.wav | *.mp3) echo "$file is some kind of audio file."
;;
*) echo "Sorry, I don't know what kind of file $file is!"
esac
done
Save this in a new file, make it executable and pass it some files you want information about. I really think the way you can process multiple options on one line is really elegant.
select is really its own unique construct. It will take the list of items passed to it, create a numbered menu out of those lists and wait for input. Watch it in action (file gives us information about a file, as seen on line 5):
#!/bin/bash
select theItem; do
if [ $theItem ]; then
file $theItem
break
fi
done
With no in clause (select variable in list), select defaults to the list of command-line parameters. So, when we run this example, we need to pass in the list to process:
$ ./st.sh * 1) printaudit.pl 2) BidToJob.dmg 3) cl.txt 4) list.txt 5) loopy.sh #?
Pressing "2", followed by enter, has the program output:
BidToJob.dmg: Macintosh HFS Extended version 4 data last mounted by: '10.0', created:Tue Dec 7 16:58:10 2004, last modified: Wed Jan 5 18:07:44 2005, last checked: Tue Dec 7 16:58:10 2004, block size: 4096, number of blocks: 1024, free blocks: 727
A bit Spartan, perhaps, but certainly functional, and will save you a ton of work. Again, the power here lies in being able to build menus, completely ad-hoc, based on the contents of a directory.
Next month, we'll get a little deeper into why some of the above works, as we probe deeper into the bowels of bash. Also, we'll expand on other loop constructs. Like any programming, there's typically more than one way to achieve the same thing. You can avoid all use of until by negating a while loop. You can split up lists with bash's processing, grep, sed, cut, and other utilities. I can only serve as a guide. Practice, err, correct; then the apprentice becomes the master.
Ed Marczak, owns and operates Radiotope, a technology consulting company that specializes in networking, workflow automation, teaching about technology, and helping out. Tech relief at http://www.radiotope.com
