Shell Programming and Scripting

A common issue with programmers is that they don't test their code in pieces, to verify they know how things are going to behave. To troubleshoot the shell script, break it apart, one component, each command or a line at a time, until you find the problem. If you type it on the command line, it can store in your local shell, you can test the variables, and the output of the commands, one at a time to determine the proper expected output, one command at a time.

Our first issue, why source the script into your current shell? This is additional overhead that doesn't appear to provide any benefit.

Set the execution bit and start testing. Use "set +x" and "set -x", as often as needed, while debugging to see the code as it is presented for execution, see the values as the value tests are performed, etc.

I would ensure your code exits with an error code, if it is not going to run, instead of simply dropping out. This ensures some feedback from cron, or other scheduling tool, the ability to automate proper responses to script failure.

Instead of setting the variable work, when you are done with the first exception, exit 1 (or some other values). This eliminates the need for an "if" test to start your "Main Module" and simplifies your code. Each new reason for exiting may need a different exit code, to determine proper next steps, for the calling program or shell to interpret and respond apporpriately.

grep *tar* ... will likely return more than you expect. Use of wildcards in with grep search strings requires a bit of finesse. You might want to read the O'reilly book on regex sometime. Simply use grep tar, instead.

The use of

Code:

    toBackUp="$toBackUpDir/*" #PATH TO BE BACKED UP

is bad form, if you must gather your list of files, do it later, on the command line, not as part of a variable. Every time you use this variable, it will return a space separated list of files, or may cause additional problems, when the list of files exceeds the command line lor variable length, which is usually under 1024 characters.

I concur with jzacsh tom_cmu, regarding the wrap of the commented code. The second line also needs the leading #. This is the first reason the code stops before executing anything in the "main module". This would looks something like:

Code:

        #OLD WAY: #fileName=`date | sed -n s/ /_/g p | sed -n s/^/Backup_/p | sed -n s/$/\.tgz/p | \
# sed -n s/^/$landingDir/p`  #NAME OF BACKUP FILE

I highly recommend the use of curly braces around each variable reference.
My versions of sed, on Solaris 8, 9 and 10, require quotes around the command to work. We generally use [date | sed "s/ /_/

I concur with TonyFullerMalv's comments about quotes around variables when testing, expecially if you expect an empty string for comparison.

The cause of all of your headaches comes from your sed in

Code:

# MYSQL BACKUP
                   sql_bName=`date | sed -n s/ /_/g p | sed -n s/^/SqlBackup_`

which should be modeled like you do in the previous instance

Code:

# MYSQL BACKUP
                   sql_bName=`date | sed -n s/ /_/g p | sed -n s/^/SqlBackup_/p`

I would use a different construct for ./{dirname}. Some prefix, or fully qualified directory name would be better, or pass the starting directory to the script on the command line.

z is not a common option for tar, usually you'll want more portable code to run in other environments, beyond the one you currently use. to be more portable, you will want to use something like:

Code:

tar cvf - ${list} | gzip > ${filename}