Hacker News Reader

Comment by Hurtak | Hacker News Reader

How long ago was this? AFAIK the `rm` command in almost every linux distro these days will NOT let you delete `/` unless you add `--no-preserve-root` parameter.

View on HN

I think the key take away in the parent comment is:

"This was how I knew OSX was a real Un*x"

Will it still start recursing and deleting most of the stuff owned by your user? That's arguably more important than the system files!

No:

    # rm -rf /
    rm: it is dangerous to operate recursively on '/'
    rm: use --no-preserve-root to override this failsafe

There's still lots of ways to screw up a rm, like "rm -rf /*" or deleting your entire home directory, but a space after the initial / was apparently common enough that they eventually put a big failsafe for that in the GNU version.

I don't think OSX uses GNU tools unless you install them through brew.

More serious than users fatfingering the command were scripts with code like

  rm -rf /$MYVAR

If you don't set $MYVAR and don't set bash to error on unset variables you are in for trouble.

I don't recall which one it is (u for unset perhaps?) but I cover this by starting every (bash, E and pipefail are not POSIX) script with `set -eEuo pipefail`. All should be the default IMO, I don't understand - other than back-compat - why you wouldn't want them.

It's -u.

You can also prevent this by never using $VAR, and instead always using ${VAR:?} to exit with error if VAR is unset (or use one of the other options to provide a default).

A lesson I learnt several years ago when I discovered that mktemp behaves differently on macOS versus the GNU version in Linux.

From that day onward I always make sure the first line of my bash scripts contains at least "set -e".

macOS doesn't use the GNU versions, though.

I've done something like this, dunno, may have been around 2000.

Reply on news.ycombinator.com