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*
