Not being a *nix user I spent a while looking the command at the top trying to figure out how it would hose everything

It just clicked – the end bit refers to the beginning, replaces letters with other letters and comes up with rm -rf /

Which I know from teh interwebs is normally not a good thing to do… :)

Yeah never run that command as root – luckily when I made the above mentioned mistake, I wasn’t running as root. Unluckily it hosed my /home/* directory so badly before I could stop it, it was worth restoring.

One time we had a box where users were allowed to create new files in any folder they wanted on the system but not given write privileges to any existing files (all the users were employees–trustworthy and all very capable, I was the only newb).

One guy left the group, and he had been big into adding his own stuff to the box, which was fine. But now he’d left and his crap was all over outside of /home/thisguy and we wanted to clean up after him. We knew the system ran fine without the stuff the guy added, so our sysadmin decided to just run rm -rf / as this user. It worked nicely, cleaned up all the stuff the user had created, left everything else intact.

It seems that Sun took the “may become the default behavior” bit to heart since this is exactly what their version of rm does by default in Solaris 10. :)

Can anyone come up with a legitimate reason to do rm -rf /? I can’t think of a single instance when this would be useful. I mean from purely Unix point of view, if it’s syntactically legal, you should be able to do this. But when would you actually “need” it?

Since there are so few (1) legitimate uses for such a command, GNU `rm’ provides the `–preserve-root’ option to make it so `rm’ declines to operate on any directory that resolves to `/’. The default is still to allow `rm -rf /’ to operate unimpeded. Another new option, `–no-preserve-root’, cancels the effect of any preceding `–preserve-root’ option. Note that the `–preserve-root’ behavior may become the default for `rm’.

— GNU coreutils documentation

Oh wow! I got 7000 GET (look at the number on my comment – round 7000)! Wohoo!

Then again my comment is not very spectacular or meme worthy. Wasted get? :(

Oh, good tip. Next time I’m compiling something I’ll probably stick it in /usr/local which is mostly empty for me.

Actually, most of the things I compiled from source was nice enough to let me fakeroot it and turn it into a deb package which can then be maintained by apt. As long as apt knows where it lives, I don’t have to worry about it. :)

/opt is “optional” software in UNIX. Solaris uses this dir to install SUN branded software that does not come packaged with Solaris. Examples include SunStudio, SunRay Server software. Some other groups use this area as well, like BlastWave (/opt/csw).

I think of it as /usr/local, but for commercial software. Anything I compile from source goes into /usr/local. Makes it much easier when building upgrading systems.

Btw, what does solaris put in /opt? On my Ubuntu box I currently just have bunch of packages that were either compiled from source, or came as generic binaries not from a repository. Here is what I have there right now:

Dit Defender
Eclipse
Firefox
GCalDaemon
Google Desktp
Komodo Edit

In other words my /opt is for shit that is not natively installed via apt, that likes to have it’s own program directory, windows style. And I actually like it this way. It keeps things clean. :)

[quote post=”2091″]Wait… You should still be able to chmod files back to normal as root, no? Then again, setting the right permissions for the right files might be a pain in the ass.[/quote]

Theoretically, yes. The perms should be in the RPM database, but getting access to all the binaries and libs needed would be a pain.

I accidentally did this on Solaris in /opt once. Fortunately, I didn’t require any file access in this directory to restore the perms. It took a long time to get all the perm information out of the package database, but I was successful in restoring it back to normal.

Wait… You should still be able to chmod files back to normal as root, no? Then again, setting the right permissions for the right files might be a pain in the ass.