19

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.

3

5 Answers 5

38

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.

1
  • Similar to Dario, I also disable rm in user shells, to train myself to use an alternative. alias rm='printf "Avoid using rm. Use trash or rmi or \\\\rm instead.\n"' Apr 14, 2020 at 6:17
4

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.

1
  • 3
    RHEL has this by default, you're right, at least the systems I used.
    – Daniel Beck
    Feb 1, 2012 at 15:18
4

I 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/*.jpg

You 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.

1
  • Nice example. Of course if you like danger, or gambling..
    – Dunaril
    Feb 1, 2012 at 15:54
2

In 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.

1
  • 3
    Looks like you found a way to make this bad practice even worse :)
    – Dunaril
    Feb 1, 2012 at 15:51
1

This 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 rm in some other context that lacked either this function or the rm -i alias.
  • 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 rm is 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.

1
  • Kamil: My answer includes that rm -i historically (in my experience with having hundreds of users) results in erroneous file deletion, and that the function included has trained users to use correct wildcards instead, lowering the error rate. So I have addressed key issues plaguing rm -i and provided a solution for convenience's sake, and the mere fact the bullet points are underneath the function doesn't prevent them from being germane. Jun 13, 2018 at 23:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .