bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

[Linda Walsh]

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.
---

You are right.

This only further cements the worthlessness of the 2003 revision in it's
claim as being a POSIX standard.

The problem is that the initial standard didn't have many of these restrictions.

I don't know about this specific one, but I bet  it wasn't in *THE*
POSIX standard.

The idea of a POSIX standard was to make things compatible and provide
a set of features for portable execution.   Later revisions have mostly
about adding restrictions.


Most recently I observed a discussion on one of the posix lists about
how further screw with people by restricting filename chars from
the current set [^/\000] to [^/\000-\040]:  "No more file names like this".
This showed the braindead nature of the poster who forgot to restrict
non-printing chars further up in the unicode range.

-------------
Voelker, Bernhard wrote:
> Andreas Schwab wrote:
> > [...] read the second paragraph:
> >
> >     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.
>
> Coreutils has already implemented an exception for the root
> directory: --no-preserve-root (whatever this would be useful
> for except investigating what'd happen in a VM ...).
---
And by doing so has violated posix, since it doesn't say that if
a switch is present, you can override the 2nd paragraph.  If we
are going to be stricly posix, it says if the arg is the root
directory -- the util must have nothing more to do with the operand.

Adding special "except if this", options doesn't make it posix
compatible.

It's interesting how people can rationalize that's it's ok to
violate the standard for their special pet case, but when it comes
to one's proposed by someone else, it's all "nope, not sorry -- and
we can't remove _my_ feature for backwards compat reasons.."...

Obviously, the same workaround that was prescribed for working
around . would work for "/", namely:   'find / -delete'.


If you are are going to rigidly adhere to a broken standard that is
becoming more broken and restricted over time,  you can't put in
pet exceptions while using POSIX compat as a justification for
not allowing other, more user friendly, options.

so +1 to Bernhard for point that out, but a -1 to those who
don't cite posix as an excuse, yet allow overrides that are non posix.

More generally, -1 to the bad trend of taking a portable OS Exchange
specification and turning it into a list of "thou shalt not's"...

As if we need another list of those... The first has been a great
excuse for oppression and mass murder...  I wonder how high people
elevate the holy P.O.S.ix.  :-(

---


Hey, I know... lets just add a new util 'r', does the job of
rm and rmdir combined w/o unnecessary posix restrictions.

r -f .
(automatically does what is needed to remove "." -- including files
beneath it).

Interesting fact -- MS's "netsh", allows you to type the minimum
number of chars of a command that are unambiguous to execute it.