I have read some time ago (can't find the reference) that using such an alias as alias rm="rm -i" was very bad.
Is there historical evidence or common sense explanation for that fact?
I would imagine that it gives a user a bad habit of relying on the confirmation prompt to check his command, which could lead to disasters if he does so on another profile that doesn't have the alias.
35 Answers
You're right.
It's bad because you get used to it. If you're on a system that doesn't have it, and you rm, it immediately starts deleting and you're wondering what's going on.
Many users are used to SSH'ing into different systems; so using lots of different systems, sometimes without personalized user accounts (including aliases) set up, is rather common.
Instead, use e.g. alias rmi='rm -i' and learn to use that one. If that isn't set up on a different system, you didn't accidentally delete files and can always fall back to typing the full command.
Like @Daniel said, it's not harmful in and of itself, other than training you to expect it to be there. In fact, it's the default set-up on CentOS (and by extension RHEL, I presume - been too long since I've used one) machines, and it's a massive pain in the tuchus. For the rest of my time at that gig, I typed /bin/rm in order to avoid the "Linux for people who shouldn't have root access" setup.
1I think the big danger is that people might rely on something like this to filter a glob. Imagine you want to delete some images from a directory, but not all of them:
rm -i pics/*.jpgYou could use that to filter the glob manually, which would be completely reasonable. But, if you had aliased it and were using rm and happened to land in a shell without that alias and try it... you just deleted all your pictures, oops!
Personally I also find this alias to be harmful to my blood pressure ;). But that's just me.
1In addition to what Daniel Beck said, I found myself using -f to bypass the -i, which is potentially dangerous as it results in using rm -f and rm -rf unnecessarily. Somehow related: a way to prevent rm -rf issues is this is to create file called "-i" as duscissed in answer of this question:How do I prevent accidental rm -rf /*?.
But again, if that alias wasn't there, I wouldn't use -f, and the whole thing won't be an issue.
1This is much less harmful, based on my experience working with hundreds of users in the past:
rm () # must be a function, must require single answer for all targets
{ ls -FCsd "$@" local reply ; echo -n 'remove[ny]? ' ; read reply if [ "_$reply" = "_y" ] ; then /bin/rm -rf "$@" ; else echo '(cancelled)' fi
}- Users are trained to use wildcards correctly, not just '*' and then relying on the y/n prompts to select files
- The conditioning to use correct wildcards often saved the from disaster when they used
rmin some other context that lacked either this function or therm -ialias. - I spent less time restoring files where the user typed 'y' one too many times
- Users only have to respond once - providing a sharp positive feedback to their using it
- Control-c interrupts work and are reports as doing nothing
- Not a script, so the real
rmis untouched, leaving other programs undaunted.
The code style is mostly sh-compatible (except use echo .... | tr -d '\012' for pre-bash shells), feel free to make your own more bash-specific. I'm not posting to share the code itself, but to share the user experience change that comes with it.
