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

[Linda Walsh]

Paul Eggert wrote:
> Linda Walsh wrote:
> > find, by itself, has no way to remove all of the items under a
> > tree even if you own them all.
>
> That's not a problem.  Have 'find' call 'rm'.  Something like this, say:
>
> find . ! -name . -prune -exec rm -fr {} +
>
> So there's no need to change 'rm'.
----
Actually, I was thinking about this -- if adding a switch to
provide the original behavior it had for 20+ years is so stressful
to you guys, then really, you should revert the change -- think about
it -- it would *simplify* the code -- which means Bernard should be
happy as it would imply less bloat.

for those who wanted protection, they could have **easily** put a
shell wrapper-function around 'rm' to provide that functionality --
there was no need to change rm -- the code they added breaks the
original behavior and and, Bernhard, has already opened a can of
worms, cornder cases, races and a sizable performance penalty.

All they things that you accuse function restoration of 
have already been done.  I assert that this change make problems
MORE likely to happen as they try the easiest workarounds they
can find.  In my 26 years of unix-related experience, not once
have I heard of anyone accidentally doing rm -fr dir/. by accident.
You say hardly anybody cares for the corner case -- that was because no 
the problem it is solving is one that was hardly ever a problem.

How about this: (not my favorite beverage), BUT switch the code to 
allow the above (dir/.) but not a lone ".".  I'd leave the .. 
restriction in for dir/.. and .., since there is no legitimate
use for it: just delete 'dir'.  But there is a legitimate
use to use "dir/." -- since it let the users avoid the bug
of using '*' and deleting multiple file systems while they thought
that "one-file-system" meant "1 file system[period]", not 1
filesystem per command line argument.  That's just a lame definition
that someone thought up justify the new bug that was being introduced.

So if any of you are serious about making the tools more robust and
less prone accidents -- especially if you only enable "." if it
is preceeded by a directory component (not likely to be typed by
accident, but useful to keep things on 1 device), while using
a lone ".", I could see as being as easily mistyped as the rm -fr /
as the two are right next to each other.

Oh, in addition to that, I *am* asking for compatibility in "-x"
being the short version of "--one-file-system" ('cp', 'rsync',
'find' (though find make it short for --xdev -- it still uses -x
as the short form).

I hope you don't have your eyes shut so tight that you can't
see that the removal of dir/. has brought about needs for 
workarounds with the easiest one using shell expansion.

You realize with bash shell expansion and globstar turned on,
the "one-file-system" switch is useless.  Not allowing
dir/. breaks --onefs" in all cases as rm -fr ** would list
all files on the cmd line (hadn't thought of that till just
now, this is not a corner case, as ** will list all the 
files and directories on the command line.