bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

[Eric Blake]

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