Skip to Content

Bash em Down - part 3

In our last session we expanded our backup script to be a little more robust (with dated backups), yet be kinder to our bandwidth (via rsync). This time around, let's take a look at how we can make managing that script easier on us. We'll do this with the introduction of variables.

Programming is has a number of concepts that can be applied as needed. One such rule of thumb I try to follow is:

If a piece of data might be used multiple times, or in different ways, then that data should be represented by a variable

The idea of this is that data can change. It is much easier to change it once and have everyplace it appears change as well. A variable is nothing more than a name for the data point. The data can be changed, but retain the same name. Remember your high-school algebra? The same concepts apply here.

When choosing a name for your variables, PICK SOMETHING MEANINGFUL. Trying to remember that "pebbles is the width of the screen" and "dino is the height" might be humorous, it makes for a nightmare to maintain - especially with larger scripts. In this case one would be better off with variables called "screenwidth" and "screenheight", or something similar. Variable names should begin with a character (not a number), and can contain characters, numbers or underscores. This is the rule I apply to ALL my variable names, regardless of what language I'm using. I haven't been let down by it yet. And finally, it is common to see variable names in scripts entered in all upper case characters. Though this is not required. However variables are case sensitive, so "HELLO" is not the same as "hello".

So, let's review our current script:

#copy everything in the /home folder to the /backup folder
mkdir /backup/`date '+%a'`
rsync -r /home /backup/`date '+%a'`

What pieces of data appear more than once here? The backup directory for one, and the date trick to find the abbreviated name of the day. There's also another piece of data that we might like to change easily - the source directory to back up. So, let's create variables for these points of data.

Creating a variable is as simple as picking a name, and then setting it equal to something:

myvariable="This is a variable"

Notice there are no spaces on either side of the equals sign. This is important - if spaces were included, the variable would not be set properly.

To later refer to the contents of that variable, you use a dollar sign ($) followed by the variable name.

echo $myvariable

With that in mind, we can then change our script to make it easier to maintain.

#copy everything in the /home folder to the /backup folder

#declare our configuration variables
day=`date '+%a'`

#create the directory (if needed), and then do the backup
mkdir $backupdir/$day
rsync -r $sourcedir $backupdir/$day

Now, this is a relatively simple script, so applying variables may seem overkill. This is always a judgement call - use variables when YOU think you need them. But the more complex your scripts get, the more likely you will want to use variables. In this case, we can now very quickly and clearly change our backup directory, or the source directory. We have removed the variable part of the work from the actual lines that do the work. As our script grows, we'll see more of a need for these variables.

Till next time.