Re: soliciting opinions about potential new cron/at features.

[Juergen Doser <doser@freiburg.linux.de>]

Shaleh <shaleh@livenet.net> writes:

> On 15-Feb-99 Amos Shapira wrote:
> > On Mon, February 15 1999, Shaleh <shaleh@livenet.net> wrote:
> >|Why not attack this from the other direction?  Why not make a .cron.d
> >|director
> >|y
> >|in the users home dir.  It behaves just like the /etc/cron.d except under the
> >|user crontab control.  Seems to solve all need issues for cron and should be
> >|relatively easy to implement.
> > 
> > And force cron to lookup all users's home directories every - well,
> > when?  (not to mention possible automounted NFS home directories,
> > *shiver*....)
> > 
> > What's the advantage of this over the current "crontab -e"?  Cron will
> > be notified as soon as the user's entry changes and keep the file in a
> > safe place.
> > 
> > Also, as far as I understand this, the aim was to avoid forcing users
> > to do anything special about cron, so what's the gain?
> > 
> 
> No, if the user has a crontab, try to run .cron.d/ scripts.  This should be a
> fairly cheap setup.  Or even have a --user-has-crond (like your -e).  The user
> never has to know this exists, GnuCash or whatever can be in complete control. 
> Just like Debian users are not aware of the /etc/cron.d -- until the need to
> know.  Scripts handle everything.
> 
> 

Wouldn't this be a solution: Every program that needs an
user-crontab-entry puts this in '~/.cron.d/<programname>' and calls
the script 'update-cron' (which basically adds all entries in
'~/.cron.d/' to the user crontab in /var/spool/cron/crontab).

The only real problem I see is staying compatible with the old 'crontab 
-e' approach. But I think this can be solved:

 o update-cron remembers all entries it has added to the user crontab

This way update-cron knows which entries are to be removed, when a
package gets uninstalled or deletes its cron.d-entry. It simply
deletes every entry in the crontab that it has remembered (that means
this entry was added by update-cron) and doesn't exist in '~/.cron.d/' 
anymore.

Thus the user can still add and delete crontab-entries via 
'crontab -e'. 

 o put a notice above every crontab-entry that has been generated by
   'update-cron'

Saying something like:
"This entry has been automagically generated by update-cron for
<programname>. Do not edit this entry directly, as it will be
overwritten."

This way the user knows where this entry comes from and that he isn't
supposed to delete it. 
  
 o Put some internal marking above every entry (like an entry-number)

This way 'update-cron' knows which entry this should be, even if a
user has accidently edited it and thus it can be repaired. 

Bye
	Jürgen