crontab -r deletes crontab without warning.

[skorokithakis]

Deleting a crontab without any warning at all when a user mistypes the most commonly used command (crontab -e) as the letter next to that is... unwise. Adding a prompt to confirm deletion, or making a backup, would save a few crontabs.

[vixie]

On Friday, July 5, 2024 1:57:51 AM PDT Stavros Korokithakis wrote: Deleting a crontab without any warning at all when a user mistypes the most commonly used command (`crontab -e`) as the letter next to that is... unwise. Adding a prompt to confirm deletion, or making a backup, would save a few crontabs.

thanks. cron's interface follows posix. in the old days it was -d not -r, and i did have a verification prompt. we can't break shell scripts that depend on the posix behaviour. suggestions welcomed.

…

-- P Vixie

[skorokithakis]

Would it be acceptable to create a backup somewhere, to enable the user to undo the deletion?

What's the use case for deleting a crontab? I've always just cleaned the lines by hand, so I'm not sure how people use -r.

[vixie]

On Friday, July 5, 2024 11:22:35 AM PDT Stavros Korokithakis wrote: Would it be acceptable to create a backup somewhere, to enable the user to undo the deletion?

keeping in mind that /var/cron/tabs (or /var/spool/cron on older systems) is usually mode 700 and owned by root:root, we would need to preserve that level of reachability in any change. that is, "ls" by a non-root user can't display a set of user names who have crontabs, or who have backups. this argues for adding /var/cron/tabs/.backups (or /usr/spool/cron/.backups) or similar -- and it would have to be created by the sysadmin not by the crontab command "on demand". would that solve any problems or simply add more confusion?

What's the use case for deleting a crontab? I've always just cleaned the lines by hand, so I'm not sure how people use `-r`.

this version of cron, or derivatives it, are now universal. there's no telemetry by which we could answer your "-r" question but the law of large numbers indicates that some workflows depend on every feature cron has.

…

-- P Vixie

[skorokithakis]

and it would have to be created by the sysadmin not by the crontab command "on
demand". would that solve any problems or simply add more confusion?

Well, given that I've been a Linux user for more than twenty years and I only discovered the -r command today (when it a typo ate my crontab), I'd be very grateful if I even could ask my sysadmin to restore my file.

I agree that crontab is so widely used that it's basically ossified and very few changes are possible, but the footgun of one letter being "edit, the thing you do multiple times a day" and the letter next to it being "say goodbye to your data" means I'll never be comfortable typing crontab -e again. Maybe I should just set an alias that won't let me type crontab -r, or maybe crontab should have a big warning on this, but the current behavior seems a bit problematic.

By the way, which part of POSIX is this behavior defined in? I don't remember offhand any other utility where -r deletes data like this...

[Et7f3]

we can't break shell scripts that depend on the posix behaviour. suggestions welcomed.

Shell scripts doesn't run in tty most of the time. It can if someone want to test a script. In that case the message could be:
"We detected you are running in an interactive session so you seems to be a human. You are about to delete all cron for users X. To avoid this confirmation question you can do cat | cron" the cat | while open a pipe so not tty.

It is the same heuristics used by git, xxd, grep, ... when choosing to emit colors.