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…

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.

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

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

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.

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.

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.

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.

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.