Not really, a lot of novice unix users are of the habit of removing files with -rf switch. I cringe everytime I see it.

The command "rm -rf ~/blue/" is just a single space key from being equivalent to "rm -rf /" with "rm -rf ~/blue /"

On any modern system it's actually "sudo rm -rf / --no-preserve-root" and then entering your password while staring at the command.

"rm -rf ~/blue /" will not come close to deleting / unless you are in the habit of running every command as sudo, even ignoring the presence of --no-preserve-root

Much, much, much the worse is "rm -rf ~ /blue". I don't give a crap about 99% of the stuff outside of $HOME, but of course, the stuff in $HOME is the stuff that's trivial to destroy.

You're missing the point:

    $ cd dir where there are source files and temp files
    $ rm *.tmp # or so you think
    '.tmp not found'
    # too bad

Except when: (these are terrible lessons to learn)

1. You type it into the wrong system (D'oh)

2. You have run `mount --bind / /somewhere/else` then `rm -rf /somewhere` a week later

:(

It boggles my mind that --one-file-system is not the default :/

> Not really, a lot of novice unix users are of the habit of removing files with -rf switch. I cringe everytime I see it.

Every few days I remind myself of this.... then I have to delete another directory with a git repository in it, and end up add the -f in again

I run into this all the time, too. Now my -rf usage is almost always wrapped by this:

    rmgit()
    {
        git status
        read -p "Are you sure? " -n 1 -r
        echo
        if [[ $REPLY =~ ^[Yy]$ ]]
        then
            rm .git -rf
        fi
    }

I think this would be a bit better for interactive cases. Note: written just now, I haven't actually felt the need for this safeguard... yet.

    rmrf()
    {
        (echo "The following files are going to be deleted!!!"
         for FILE in "$@"; do
             echo "<<<" "$FILE" ">>>"
         done) | less
        read -p "Are you sure? " -n 1 -r
        echo
        if [[ $REPLY =~ ^[Yy]$ ]]
        then
            rm -rf "$@"
        fi
    }

Doesn't help against network filesystems mounted in subdirectories. --one-file-system (which really ought to be the default) prevents this.

What would be the "good" alternative ? I often tries "rmdir" or "rm -r" if the directory is not empty and very often there are some "protected files" so I add -f. Thus it happens that I directly lauch "rm -rf".

Watch it fail first, verify that the failure makes sense, check to see if there's a way to delete one file with -f before deleting the rest with -r. Use -rf only as a last resort, and only by appending the f to an already-failed command whose syntax you've validated.

More easily, "rm -rf ~" with a premature "Enter"

do the -rf after the directory to avoid this in future

Premature enter just results in:

[web@server /]$ rm ~

rm: cannot remove `/home/web': Is a directory

Hehe, I did something like that once, except that I typed "rm -rf ~ /blue/". There was no /blue/, but I managed to wipe out my home directory, and I did not have a backup. :-| It was on my personal machine, so at least I did not delete anybody else's files, but I still got burned hard enough to learn a valuable lesson.

The / key was right next to Enter on a lot of old keyboards. It was quite easy to type 'rm -rf /tmp/garbage*' and have a simple fumble turn it into 'rm -rf /'. I mean, there's this guy I know, he did that once.

There's also the chance of it happening when writing a script

Such as this classic:

https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi...

Ten years prior to that, Apple had a similar bug in one of its installer scripts on OS X. I have a hard time finding much about it online now, because it happened at a time when OS X and the Internet were a lot less popular than today, but what I recall is that an unexpectedly customized installation directory (say with spaces or one level closer to "/" than the default) would cause the installer to delete a whole lot of things.

I once installed GGClient in C:/Program Files/ instead of any particular folder

so of course, I said "I'll just uninstall it from there and install it in the correct folder" and it proceeded to delete C:/Program Files/

There's also this one from Pool of Radiance's 2001 release:

http://www.rpgfan.com/news/2001/1416.html

Uninstall wipes out your Windows directory.

I still have nightmares from this buggy mess. To add insult to injury the shop didn't want to take the game back afterwards.

The one that I did only a few months ago was something like

    $ cp -r path/to/some/directory path/to/very/important/directory
    $ (run some commands to verify copy did what I wanted)
    $ rm -r path/to/some/directory path/to/very/important/directory

Of course, all I had meant to do was delete `path/to/some/directory`, but I just pressed 'up' in my history and switched `cp` to `rm`. Of course I hit Ctrl-C in an instant, but my FS was already hosed...

Not really, on my keyboard at least / is directly next to . and you could feasibly be clearing out a directory or something with rm -rf .

It's my habit to never use the -f flag until I get those annoying confirmation messages. I <CTL>-c to cancel that command, then scroll up and add the flag to run again. I think this is a good habit? Anyway, the worst thing I've done along these lines was resetting a dev DB that had seen considerable un-backed-up configuration work. I couldn't blame rm for that.

Eh, "rm -rf $TEMPDIR/$TEMPFILE" in a shell script is just a couple typos away from deleting everything on the network. Yet I've seen people put crap like that in build scripts even after they've previously inadvertently deleted half the network drives.

Fortunately, despite rm's poor choice of options and bash's poor default handling of variable name typos and the obvious PEBKAC, backups saved the day here.

People are human. Policy ought to reflect this.

Be honest, who doesn't have

rm -rf *

in their shell history? Now it's just one accidental twitch away.

I suspect everyone tried to remove all dotfiles and dotfolders with rm -r .* as well...