That's perhaps the slightly wrong way of looking at it. "rm" is an executable that parses its command line; the asterisk is a special symbol that gets expanded to a list of all file names (except those starting with a period). So the arguments `rm` receives when you type `rm *`, is a list of all file names. It does not know that, because all arguments are just strings, and therefore it parses those strings the same way as if they had been typed, which makes that a filename like `-rf` can trigger the behavior of the "flag" `-rf`.

Are there any (Unix-likes) where you can’t? Aside from degenerate cases like Windows SFU/SUA (though I’d expect that one to allow it as well).

Globs getting interpreted as switches is a very unfortunate footgun, sure, but I don’t see how you could eliminate it while retaining the same level of smarts in the shell (tokenization but only into dumb strings), and DOS/Windows command line parsing is IMO essentially a reductio ad absurdum for the idea of having less (no tokenization, but the shell still splits commands). Except maybe require the -- between switches and arguments whenever there are arguments? But not only is that an incomplete fix, it also goes contrary to convenience of interactive usage, which is important: much of the tension in shell syntax and Unix utilities is due to balancing it with conventional programming, I feel, and I wouldn’t want to be writing even Perl or Tcl instead, let alone Powershell or the like.

For a similar reason, `touch ~/-i` can protect you from some problematic `rm -rf *`s.

The canonical writeup about this issue is here:

https://www.defensecode.com/public/DefenseCode_Unix_WildCard...

getopt-like libs stop parsing options after “--“, so “rm -- *” should be safe, afair.

What do you mean some OSs? It works fine on Linux and bash. With zsh I have to expand the * to make it work.