Re: crontab and editors (was Re: Editor Priorities)
On 08-May-02, 16:12 (CDT), Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
> Steve Greenland <steveg@moregruel.net> writes:
> > Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
> >> Steve Greenland <steveg@moregruel.net> 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[1].
>
> 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
to exit.
3. if stat.modtime(/tmp/funnyname) hasn't changed, then goto 7.
4. rewind(/tmp/funnyname)
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. :-)
>
> > [1] 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
bugs.
Steve
--
Steve Greenland
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: