What's the advantage of using a bash script for cron jobs?

Question

From my understanding you can write your crons by editing

crontab -e

I've found several sources that instead refer to a bash script in the cron job, rather than writing a job line for line.

Is the only benefit that you can consolidate many tasks into one cron job using a bash script?

---

Additional question for a newbie: Editing crontab -e refers to one file correct? I've noticed that if I open crontab -e and close without editing, when I open the file again there is a different numerical extension such as:

"/tmp/crontab.XXXXk1DEaM" 0L, 0C

I though the crontab is stored in /var/spool/cron or /etc/crontab ??

Why would it store the cron in the tmp folder?

Answer 1

It depends on what you're doing with the job.

cron does not give you a real scripting environment, so, if you're doing something more complicated than simply calling a couple of commands, you probably want to use cron to call a script. You can also deal with things like variable expansion in a script, which can be difficult if not impossible to do in cron's environment.

The temporary file that you see when you run crontab -e is just that: a temporary file that will be cleaned up after you exit the editor session. The actual crontabs that you edit through this method wind up in /var/spool/cron.

Actually, since these are relatively basic unix-specific questions, there's the unix.stackexchange.com side of things, which may be more helpful.

Answer 2

Ok so, for the first question: there are a few reasons to use a bash script for your cronjob:

As you mentioned, you can consolidate many commands in to one bash script. This is a lot more readable than just clumping together a huge crontab line, especially since the logic flow is more obvious. Compare:

command1 >/tmp/foo && command2 || command3

vs.

if command1 >/tmp/foo
then
  command2
else
  command3
fi

Another reason to call a script in your crontab is so that you can call something besides bash. For example, you can invoke a perl script or even a php script.

Also, suppose you have some logic you want to call outside of cron. Then, it also makes sense to put that logic in a separate script installed on your server. You can run that script as needed on the command line, and you can also call it from the crontab.

Finally, note that quoting in crontabs is really weird. The canonical example is that crontabs eat the percent sign. If you put a '%' in a crontab line, you actually have to double it ('%%') or else cron will eat the bare percent sign and confuse the jebebus out of you.

Basically, wrapping a cronjob in a script is safer (more standard quoting/escaping) and more flexible. Any cronjob longer than one or two commands should probably be moved in to a separate script.

The second question is pretty straightforward: when you edit your crontab, you don't edit the file under /var/spool directly. Instead, the crontab -e command copies your crontab file to a tempfile in /tmp. Part of the tempfile name is a random string designed to lessen the chance of two invocations of crontab -e from trying to edit the same file in /tmp.

It's safer to edit a temporary file for various reasons. One is that if the editing process crashes, the original file is left untouched and usable. Another is that it allows the system to check the new crontab for syntax errors before replacing the old one.

Also I will be amazed if I managed to type this whole entry without saying cornjob once.