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

[Linda Walsh]

The shell is one of the things I'm trying not to have a dependency on.  It
doesn't pass a reliability test as it does too much.

I want a utility that removes files -- single files or depth recursive
and it can fail on the current dir or target dir -- after
finishes like it is documented to do .. or it can fail at
the beginning, as long as the -f option said to ignore errors
and keep going.

I don't want a wildcard solution.  It's a wildcard. (Doh!)

The issue was changing the default no?

You don't think I'm being reasonable by agreeing and saying
a non default environment var?

Why should cp accept "." as "addressing the contents of
a directory, but "rm" be deliberately crippled?  We've
excluded safety, since no one will get to the option unless
they've enabled it and unless they choose force, since the
they should get a prompt asking if they want to delete the
delete the files in protected directory ".", right?

So far no one has addressed when the change in "-f' went in
NOT to ignore the non-deletable dir "." and continue recursive delete,
as normal behavior would have it do.  Posix claims the rational is to
prevent accidental deletion of all cur-dir when using rm -r ., however
if it is queried in that case, and noting that rm ** is just as dangerous,
but not as clean as it 'only' deletes all files, and leaves the dir skeleton.

So posix's rationals wouldn't seem to be 1) that important, and 2) would be
addressed by sticking with the current behavior or prompting first -- which 
would
make more sense rather than arbitrarily deciding for them and removing
the ability for rm to remove just files -- by itself. with no other utilities 
invoked.

Why shouldn't rm have the ability to only target everything under a specified 
point,
rather than always including the point?