Just worked a bit with crontab to edit some no longer working cron job. But instead of typing crontab -e I had written crontab -r, without any warning or notice my crontab was dropped! What’s the logic behind that behaviour? Isn’t the normal, userfriendly way, that you have to confirm you want to drop something? All Programms I can remember want a confirmation for not saving data or dropping some file, or even for exiting.
I could life with the problem, if it wouldn’t be too likely to do the typo. But the keys are on a normal qwert(y|z) keyboard next to the other one, so a typo isn’t that unlikely. To avoid the problem I need to add the parameter -i to it, to be asked If I’m sure I want drop that crontab. Since when do I need to add additional parameter to have a higher “security” level? Normally you need to add parameters to avoid such behaviour not to initialize it.
But as I just see my crontab version is even the userfriendly one(on Debian 5 amd64), which offers such a parameter -i. The standard BSD(as on Debian 4 x86) one hasn’t this parameter nor does -r ask the user to confirm the operation.
Anyone knows why it behaves that way, I mean a multiliner crontab isn’t too nice to be lost by accident?

Tags: none

Tags: amd64, bsd, crontab, debian, x86
One Response to “crontab -r a logic gap?”
  1. Timmy says:

    I did the same thing just now (typed crontab -r instead of crontab -e) on a RedHat box. I’m mostly in FreeBSD and that gives you a warning when you execute ‘crontab -r’.

    Anyway, if you’re using Bash, you could add an alias to your .bashrc to always include the ‘-i’ option:

    alias crontab='crontab -i'

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

Bad Behavior has blocked 2293 access attempts in the last 7 days.