tag 25817 needinfo thanks On 02/20/2017 01:41 PM, L A Walsh wrote:
> So... why should 'rm' not be able to start it's deletion > from the inside of a directory? (@ "." )? Please give more details as to what you think is broken. Instead of describing the problem in vague prose, please show a shell transcript that creates a sample directory layout and cd's into the place that you want, then attempts the removal that currently fails, as well as explaining what you hoped to have happen instead of an error message. I will demonstrate below. As written, your report is too vague to definitively state whether coreutils behavior has even changed over time, let alone whether such a change is, as you claim, a violation of GNU Coding Standards. > > FWIW, because of the above change, rm is no longer consistent in its > counting. With "one-file-system", it means "1fs/starting path", > not 1fs /rm command, whereas with "-I", it creates a global > limit of '3' deletions before asking -- not 3 deletions/starting path. I can't make enough sense of this paragraph without actual shell commands being demonstrated to see what you are complaining about. If you are complaining that: $ mkdir tmp $ cd tmp $ touch file $ rm -rf . rm: refusing to remove '.' or '..' directory: skipping '.' $ ls file fails not only to delete the current working directory, but refuses to even attempt to remove 'file' within that directory, please remember that the behavior I demonstrated is compliant with this wording in POSIX 2008 (including amendments by TC2 in 2016): http://pubs.opengroup.org/onlinepubs/9699919799/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) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." At the time of this email, I have not researched whether this wording has changed over time from older versions of POSIX. Are you arguing that older versions of 'rm' (whether GNU or non-GNU) and/or older versions of POSIX had different behavior/requirements? If so, can you please quote chapter-and-verse of those other standards, or call out version numbers (or even commit ids) where it did what you want, or any other thing you can do to make your point stronger that an intentional (or possibly unintentional) change in behavior occurred, and that there is indeed an alternative behavior worth supporting (even if such alternative is not the default, it could still be triggered by a new command-line option). Or are you arguing that contents within the directory should be removed, even though the directory itself cannot be? Again, more details in your complaint would go a long way to making a decision whether there is an actual bug, or just a misunderstanding of current behavior. It helps if you can focus on the facts at hand ("what happens, what did you want to happen") rather than making it a political attack ("you broke things and aren't consistent" or in general any rant against POSIX). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature