Hacker News Reader

Comment by deathanatos | Hacker News Reader

In the rm section of horror one story hints towards, and another explicitly notes,

> .* expands to ../*

Not on my box it doesn't. Was this true in some (rather cruel) past?

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.

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...

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'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 '..'.

Reply on news.ycombinator.com