Actually it simply expands to .., so rm -rf .* happily deletes ../, therefore ./, etc. If you're in /tmp at the time you're making this mistake, it will clobber /. Current GNU rm may be more careful, though, and warn you of unintended consequences.

Actually, that was my point: for me, .* does not expand to .. or .; the special entires "." and ".." appear to not be considered during globbing.

After closer inspection, it turns out that this is because I'm a zsh user:

  % zsh -c 'echo .*'
  zsh:1: no matches found: .*
  % bash -c 'echo .*'
  . ..

Indeed, zsh's manual states:

> No filename generation pattern matches the files `.' or `..'.

… and I've just added another entry to my list of reasons as to why I love zsh.

Same safe behaviour happens when using bash and BSD rm (OS X):

    $ mkdir foo
    $ cd foo
    $ touch 1
    $ touch 2
    $ touch 3
    $ rm *
    $ ls -la .
    total 0
    drwxr-xr-x   2 mike  wheel   68  3 Sep 14:41 .
    drwxrwxrwt  18 root  wheel  612  3 Sep 14:41 ..

I though the spec on rm says it cannot delete the directory you are currently in? http://pubs.opengroup.org/onlinepubs/009604499/utilities/rm....

Plus, it mentions . and .. as no-nos

I think it is not a rm thing but a bash (or sh) thing. The rm command receives the parameter after the wildcards have been expanded.

Unix in the past was for the tough men...

I'm not sure but my persona horror story on OS X was when I typed mkdir ~ then tried to delete my new folder. Needless to say, I'm now paranoid about backups ;-)

Things did used to work this way. As a result of some early trauma I have always written it as 'rm -rf .??*' to avoid matching '.' or '..'.