If you start your script with "#!/bin/sh -e" or "#!/bin/bash -e" then any time it gets to a command that fails, the script will stop working unless you provide an alternative action. Stopping the script is better than going ahead and copying to a directory instead of a mounted partition, for example.
Consider the following segment and what it would do if mount fails:
Code:
mount -t cifs //serverip/sharedir/ /backup/dir1 -o credentials=/credentialslocation
#this mounts the entire shared drive using a root read only credentials file
sleep 10s
rsync -avz /backup/dir1/ /backup/dir2
#backs up the data from dir1 to dir2
sleep 10s
If mount fails, then rsync will still go ahead and copy 'nothing' to the destination directory. From there the script will continue forward as if everything were ok and you won't get your data backed up, even though the script says it did.
But if the script started sh or bash with the -e option, it would stop after the failed mount and never get to the rsync or anything else. The exit code for the script would be that of an error and could be used to trigger some action like an e-mail or some other notification.
The program true always succeeds and provides an exit code saying it succeeded. The program fail always fails and provides an exit code saying it failed. So consider the following script:
Code:
#!/bin/sh -e
true
date
false
date
true
date
Will it print the date once, twice, or thrice? What happens if you change the false to a true or vice versa?
