On 02/21/2017 02:41 AM, L A Walsh wrote: > > Do you really need me to find the older version > of 'rm' in your source tree? It wouldn't hurt to point out which commit id changed behavior, if you indeed want to call that commit a regression. Being able to read the commit itself, as well as mailing list traffic at the time, will help current readers get a more-informed picture of whether such a change was intentional or accidental. > > you know as well as I do, that the verbiage > about disallowing all subpaths under '.' wasn't in earlier > posix versions (say 2001 or before). So I spent 20 more minutes on this, and researched a bit further: here's what POSIX 2001 says: http://pubs.opengroup.org/onlinepubs/009695399/utilities/rm.html "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." I then went back to SUSv2, published in 1997: http://pubs.opengroup.org/onlinepubs/007908799/xcu/rm.html "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 will write a diagnostic message to standard error and do nothing more with such operands." You ARE correct that it was POSIX 2008 that introduced the wording "or if an operand resolves to the root directory" to cover an early exit on an attempt to remove '/', but the discussion here is about an early exit on an attempt to remove '.', which, contrary to your claim, appears to always have been in POSIX as far as I can tell (and even if it has not always been in POSIX, the fact that I can quote a 20-year-old document that describes current behavior means that any change to a default now would be breaking 20 years of what script writers have come to rely on). I'm all ears if you can point to an even-older standards document worded differently, but at this point, I don't think you're going to find one. And I still maintain that a patch that adds a new option to avoid the early exit on '.' may be acceptable, but that it would have to be a new option and not the default behavior. But I'm not bothered enough by the current situation to be the one to write such a patch. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org