bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/.

[Linda Walsh]

Linda Walsh wrote:
> Andreas Schwab wrote:
> > "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."
> ----
>     I'll grant it also says you can't remove "/",
>
>     So a special flag "--use_depth_first_inspection" that says not to 
> look at
> a "basename" until it's children have been processed wouldn't be any 
> more out of place than special flags to handle "/" processing, right?
>
>     The fact that they put the ".", ".." and "/" together, outside of
> the 1-4 processing leads one to the idea that they should be treated 
> similarly,
> no?
---
   Since there is no opposition to this, I presume, all you need now
is a patch?

I.e. - POSIX now demands that "/", "." and ".." all be ignored in a 
basename,
yet the some smart gnu folks decided that leaving in a non-default optional
behavior to override the new dumb-down restrictions would best serve the
community.

So I might reason that they would be equally smart and/or use similar logic
to allow a non-default option to remove the dumb-down on the "." path.

NOTE: I have no issue with NOT _attempting_ a delete on "." after doing
the designed depth-first traversal.  Applying the POSIX restriction
on not attempting to delete "." makes perfect sense to me, since
I know that doing so can give inconsistent and "undefined" behavior
depending on the OS, but using "." as a semantic place holder to allow
one to reference a starting point for some action (imagine
using 'find' if '.' was banned as starting point:

 > find '' -type f
 find: ‘’: No such file or directory

*cheers*