bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it

[Linda Walsh]

Alan Curry wrote:
> Linda Walsh writes:
> > So far no one has addressed when the change in "-f' went in
> > NOT to ignore the non-deletable dir "." and continue recursive delete,
>
> In the historic sources I pointed out earlier (4.3BSD and 4.3BSD-Reno) the -f
> option is not consulted before rejecting removal of "." so I don't think the
> change you're referring to is a change at all. -f never had the effect you
> think it should have.
If I was using BSD, I would agree.
---
But most of my usage has been on SysV compats Solaris, SGI, Linux, a short
while on SunOS back in the late 80's, but that would have been before it
changed anyway.

For all i know it could have been a vendor addin, but that's
not the whole point here.

Do you want to support making "." illegal for all
gnu utils for addressing content?

If not, then we should look at making a decision that it can
be used to address content and ensure the interface is consistent
going forward.

I think you'll find many more people against the idea and wondering
why it's in 'rm' and why "-f" doesn't really mean ignore all the errors
it can and why that one should be specially treated.  Of course they also might
wonder why rm doesn't follow the necessary algorithm for deleting files --
and delete contents before dying issuing an error for being unable to delete
a parent.  Which might also raise why -f shouldn't be usable to silence 
permission
or access errors as it was designed to.

There are plenty of good reasons aside from BSD historic usage why it should
be designed in, especially when it's being tucked away as a non-default behavior
that would need environmental triggering to even be available.