Sometimes, I also pipe the stdout and stderr somewhere (like “/usr/local/sbin/backup.sh >>/var/logs/backups.log 2>/var/logs/backups.err“) if I want to avoid getting emails with the output from cron … (although in the example above, which looks like a backup script, I’d probably rather be emailed with a warning that my backups were succeeding or failing).

Thanks Linuxconfig !

Update:

After some FriendFeed discussion, it was noted that the crontab above is a “system crontab”, not the typical “user crontab” you would edit by typing “crontab -e” at the command line. For the “user crontab”, you don’t specify the user (the blue field, “root” in the example above).

I particularly like “Making Linux systems that don’t suck: Part II” (and Part I and Part 0), which puts a critical eye to cron and at, and surveys a few good alternatives (some backward compatible, and some not).

Sure, some Unix purists may balk at the idea of replacing these daemons+tools, but if you were going to make a Unix-ish OS from scratch and are happy to throw convention and tradition out the window in the interest of something better, there are a lot of good ideas in these three articles (Part I and Part 0 deal with logging and event notification). This article on rewriting the boot scripts in Arch Linux from bash to Lua is just damn cool .. I’ve always wanted to do this, but instead going from bash to python … Why ? Because.

I’ll look back at Robertos site (and libelektra) one day when I decide to pollute the Linuxsphere with yet-another-distro of my own