Re: crontab

[Philip Hands <phil@hands.com>]

> > Try looking at how exim does it---it adds a crontab for the mail user, but
> > does correctly handle the mail user's existing crontab.
> > 
> > To install it does this:
> > 
> >                 # Install in crontab for user mail if not there
> >                 oldcrontab=$(crontab -u mail -l|tail +4)
> 
> This is soooo stupid!  That 4-line header doesn't exist in the actual
> file and shouldn't be dumped out.  I tried to convince the cron
> maintainer to dump the header to stderr and the data to stdout but he
> decided not to.
> 
> Perhaps if others also think the current way is bad (what happens if the
> header changes length?), we can convince the cron maintainer otherwise.

The 3 line header does exist in the actual file in the crontabs area:

  /usr/spool/cron/crontabs/phil

and is in there to discourage people from editing _that_ file directly.

The fact that the three lines added here ever get seen in the output of

 crontab -l

is a bug IMO:

  [phil] palm:~$ crontab /tmp/my_crontab
  [phil] palm:~$ crontab -l | diff /tmp/my_crontab -
  0a1,3
  > # DO NOT EDIT THIS FILE - edit the master and reinstall.
  > # (/tmp/my_crontab installed on Fri Dec  5 10:23:17 1997)
  > # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

The output of that diff should be nil.  It is clearly crontab's job to strip the lines it put in before showing them to the user.  It does it when you run crontab -e, so why is crontab -l different?

Cheers, Phil.