My first thought on reading the headline was "what Linux still did that in 2015"? I thought I read somewhere years ago that Sun, BSD and GNU rm all had checks in them to spot the / or /* and refuse to run. According to this SE page[1] GNU even has an option to tell rm "no I really do want to blow away my whole root" by using "--no-preserve-root".
Apparently the "fix" only applies to the root user. The article is about a regular user who recursively lost everything he owned starting at /.
That seemed crazy to me so I spun up a VM, took a snapshot and then ran rm -rf /* as root. Sure enough it started nuking everything it could, skipping over only a few things like most of what's in proc, etc...
Thanks, it's was interesting to see the difference!
The real problem here is that a multi-hundred-line script was written in bash. While bugs can happen in any language, this particular error was due to a bash-specific pitfall, and bash has many such pitfalls. Bash is really only suitable for interactive use, or for bootstrapping the install of another scripting language.
I think this goes too far. There are many robust scripts out there. If you use rm -rf, change into a hardcoded directory first and then remove another explicit directory.
Recursively removing something that starts with a shell variable is stupid.
Apparently the "fix" only applies to the root user. The article is about a regular user who recursively lost everything he owned starting at /.
Ouch!
[1] https://unix.stackexchange.com/questions/19547/how-far-can-y...