Re: soliciting opinions about potential new cron/at features.
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
Reply to: