Re: crontab and editors (was Re: Editor Priorities)
On 08-May-02, 16:12 (CDT), Richard Kettlewell <firstname.lastname@example.org> wrote:
> Steve Greenland <email@example.com> writes:
> > Richard Kettlewell <firstname.lastname@example.org> wrote:
> >> Steve Greenland <email@example.com> writes:
> >>> * Edits files in place, rather than moving/copying +20
> >>> See crontab(1) for why.
> >> Why can't crontab be fixed?
> > Crontab isn't broken.
> Well, it certainly sounds like it's broken to me...
Crontab works like this roughly:
0. open /tmp/funnyname
1. copy existing /var/spool/cron/crontabs/whatever to /tmp/funnyname
2. start ($VISUAL|$EDITOR|/usr/bin/editor) on /tmp/funnyname, wait for child
3. if stat.modtime(/tmp/funnyname) hasn't changed, then goto 7.
5. check that /tmp/funnyname parses
6. copy /tmp/funnyname /var/spool/cron/crontabs/whatever
7. rm /tmp/funnyname
(All without closing /tmp/funnyname between 1 and 7).
How is this broken - Other than in the presence of editors that do
backups incorrectly. :-)
> >  Hint: Files in /tmp. Symlinks. Root crontab.
> ...and it sounds from this like the bug is the use of /tmp. Why is it
> impossible to put the temporary crontab somewhere else?
Uh, that's what /tmp is for. But one still has to deal with security
issues. (Crontab used to respect TMPDIR, except that emacs explicitly
switches behaviour when the filename path begins with "/etc"). I suppose
one could dump it in the home directory...but I'm basically tired of
messing with the confusion that is the cron source code except for real
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com