few answers:

first, the script will continue because it will exit only if you tell it so look at its code (properly indented, as i told you to do) and its structure becomes clear (i have shortened some lines to not overflow the screen:

Code:

#!/bin/bash
cd /to_be_archived/
for DIR in * ; do                V do this for every value of DIR:
     fSaveDir="${DIR##*/}"       |
     tar -cf [...]               |
     rsync -a [...]              |
     if [ $? -ne 0 ] ; then      |  V do this if the previous cmd failed:
          mail -s [...]          |  |
     else                        |    and this, if not:
          rm -f [...]            |  |
          rm -rf [...]           |  |
     fi                          |
done

You see what it does - it will do exactly that, nothing more, i promise! If you don't tell it to exit under cetain circumstances, it won't (should you want that: put an "exit" command in somewhere).

For a beginner you have done very good work. (sorry, if that sounds condescending, it isn't meant that way. Programming is like playing chess: you spend half an hour to learn the rules and then a lifetime to really play the game well.)

Now for some of the finer points: the variable "$?" is set anew after each command. This means that this part:

Code:

tar -cf "${fSaveDir}".tar "${fSaveDir}"
rsync -a "${fSaveDir}".tar /archived_projects/
if [ $? -ne 0 ] ; then
     [....]

might not exactly do what you want: suppose the tar-command encounters a problem. It would exit, set an error code which you do not observe, then the rsync-command will start and eventually do its job and you will never be notified about the problem the tar-command had. Even worse, the rsync-command would overwrite the last good copy you had in the archive with the faulty tar-file you just produced.

A big part of the art of script programming is to foresee what could possibly go wrong and take measures against that. You do not necessarily have to program a solution to a problem, but you want to become aware of it!

If a script has to do a, b, c and d you want to see as outcome that it did a and b, couldn't do c (ideally by giving the reason why) and therefore did not even try d. The last thing you want is the script to not recognize it didn't do c, attempt to do d (which would make no sense at all because it builds on the result of the previously run c), eventually "succeed" doing it (but with a completely unusable result) and telling you "all done successfully".

Look back at my model script from post #2: i looked at the return code of every command and put different error information for each command failing in. You do not have to exit the script as i did, but you should do something about a failing command and most probably stop the processing of the part at hand.

I hope this helps.

bakunin