bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[Linda Walsh]

Paul Eggert wrote:
> On 09/09/2012 08:37 PM, Linda Walsh wrote:
> > I'm using the wildcard option rm **
>
> Then why is this bug report about rmdir?


Because it was rmdir that chased off to network FS's when I
used wildcard syntax with it as I was told to do with rm.

This is why I didn't want to use shell.  I knew something
would go wrong, now I should use find .. how many work-arounds
for the bugs in rm are you going to suggest?

If the workaround for rm to remove all files doesn't work with
--one-file-system, then it's not a workaround.

As for rmdir, I usually do use 'find' when I want to do what I did,
but having been told that doing so wasn't safe, on another list as they'd
had it fail (as I did -- it tried to remove a dir with files in it -- something
I hadn't expected to ever happen, but due to a change in the Samba, and how
it responded to some network request, the OS promptly tried to rename what
it thought was a locked file into .<guidhexname>... It was only because I was 
editing
a file in it at the time that I caught it at all and figured out what happened.

Between that, and being told to use shell wildcards to remove everything
under a mount point, I, naturally, thought to use it with rmdir.  Not realizing
that I needed that --one-file-system to be there for that to work which
rmdir doesn't need as it doesn't expect to be used recursively.

Which points back at at the bad idea it is to use wildcards to get around
broken functionality.

rm ** removes all the files under a dir, and rmdir ** removes all the empty 
directories
under a dir.  It was the natural progression of avoiding a crippled feature in 
rm...