== Classic crontab syntax mistakes

The crontab file format is unfortunately prone to mistakes, since it
requires you to carefully count words and, for bonus fun, requires a
different number of words in different contexts. There are three classic
crontab syntax mistakes that I have seen (and sometimes committed):

* adding a username when it's not necessary

  This generally results in mail from _cron_ complaining that it cannot
  run '~~_username_~~'.

* failing to specify a username when it's necessary

  This results in mail about 'no such user ~~_program_~~', assuming that
  you gave the program arguments. (A good version of _cron_ will complain
  about it even if you didn't give the program arguments, because then it
  is a crontab line without a program to run.)

* putting too many _*_'s in.

  If you are lucky, this produces mysterious email about _cron_ not
  being able to execute the first file in your home directory. If
  you are not lucky, the first file in your home directory is
  executable, and it will get run with the rest of the files in
  your home directory as arguments.

  Alternately, if this is in a situation that needs a username, you
  get email about being unable to find the username '_*_'.

System crontab entries need usernames; on Linux systems this is
_/etc/crontab_ and the _/etc/cron.d/*_ files. Per-user crontab entries,
*including root's*, do not need or accept usernames.

(By 'per-user crontab entry' I mean what you get when you use
'_crontab -e_' and its kin.)

Personally I strongly suggest that you do not give root a per-user
crontab on a machine with system crontabs, because doing so is a great
way to confuse people. In fact, if you have system crontabs I don't
think that any system account should have a per-user crontab; just put
everything into the system crontabs with the right usernames specified.