-I flags to confirm before every removal. In the past, some distributions have turned them on by default. This is a terrible idea. Give the user too many confirmation dialogs for normal operations and they'll begin to habitually confirm them. This just shifts the requirement to "be careful" (always a red flag) to a new and more annoying dialog. "Yes. Yes. Yes. Yes! YES! God damnit, stupid computer just delete the files YESYESYESYESYES--CRAP I MEANT NO! NOOOOOOO!" This is the "Yes, but I meant no" dialog problem. This answer provides a visual explanation of why confirmation dialogs come at the wrong time.
The sort of mistake you describe is a slip, "the performance of an action which was not what was intended". The user typically immediately recognizes the mistake and knows exactly how to fix it. Unfortunately, Unix does not give the user the opportunity, rm deletes the file immediately. Every other operating system solves this problem by allowing deletions to be undone, at least for a little while, by the use of the Trash.
There are various trash systems for Unix, and this answer is full of suggestions.
The question is to alias rm or not to alias rm. Pros to aliasing rm...
- You can't make the slip of forgetting to use the rm alternative.
Cons to aliasing rm...
- You might come to rely on it on systems which don't have it.
- Might cause problems when the disk is nearly full.
- Need infrastructure to periodically empty the trash.
- Have to be sure not to interfere with the expected behavior of rm in programs.
- Might not fully emulate rm.
If you follow the first argument too far, you wind up using vi (not vim, vi), csh (not tcsh, csh) and other antiquated utilities because they're universally available. Still, there is a danger of overcustomizing your environment. I prefer to take my utilities with me and to make that as easy as possible. YMMV.
Two and three are technical problems. They can be solved with a clever reaper job which checks the size of the trash and periodically cleans things up, similar to a tmpreaper. This can be a cron job, or a more clever version can make use of the various file system event infrastructures available on many desktop Linux distributions. This is not simple, and even harder to do efficiently. Its better to find an existing system than to try to make your own.
The fourth can be dealt with by making your new rm a shell alias,
alias rm='trash', then it will not affect programs.
The fifth is a problem I leave for the reader to solve. rm doesn't have a lot of switches.