Hello, the "rm" POSIX spec currently says: > If either of the files dot or dot-dot are specified as the > basename portion of an operand (that is, the final pathname > component) [...] rm shall write a diagnostic message to > standard error and do nothing more with such operands.
AFAIK, that's to work around a bug/misfeature (IMO) in some shells, including POSIX compliant sh where the expansion of the ".*" glob includes "." and "..". That was fixed in the Forsyth shell and derivatives (pdksh and some derivatives at least), zsh and fish at least. "rm" seems to be the only command where that safeguard is applied. (find .*, ls -R .*, chmod -R 777 .*, chown -R nobody .* don't have such safeguards). Now what about: rm -rf ./ ../ AFAICT, with the above wording, that doesn't allow rm implementations to apply that safeguard in those cases (even though it's also a problem with rm -rf .*/). Solaris or FreeBSD rm seem to be compliant in that regard, but GNU and busybox rm at least complain: $ rm -rf ./ ../ rm: refusing to remove '.' or '..' directory: skipping './' rm: refusing to remove '.' or '..' directory: skipping '../' Would POSIX consider allowing (if not requiring) shell implementations to not include "." and ".." in their glob expansions to allow for those safer behaviour of zsh or pdksh? In my experience, having "." and ".." included is never desired and one has to go through too much/awkward-an effort to work around it like chmod -R go-rwx .[!.]* ..?* (see https://unix.stackexchange.com/questions/90073/does-rm-ever-delete-the-parent-directory/90075#90075 for some historical research into that). -- Stephane
