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

[Bob Proulx]

L A Walsh wrote:
> >> If you want a recursive option why not use 'rm -rf'?
>
> rmdir already provides a recursive delete that can cross
> file system boundaries

Please provide an example.  Something small.  Something concrete.
Please include the version of rmdir.

Something like:

  mkdir testdir testdir/dir1 testdir/dir2 testdir/dir2/dir3
  rmdir --recursive testdir/dir2
  rmdir --version

Include all input and output verbatim.  For clarity do not use shell
file glob wildcards because that is a dependence upon a specific
command line shell and the shell's configuration.

> dir1->dir2->dir3
> 
> dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.

GNU Coreutils rmdir does not provide a recursive delete option.
Therefore one can only assume that the rmdir you are referring to is a
different rmdir from a different project.

I specifically asked if you were using the rmdir --parents option but
my message was the only mention of --parents in this entire ticket and
in subsequent responses your messages also did not mention it.
Therefore I can only assume that there is no --parents option being
used here.

> >> There is always 'find' with the -delete option.  But regardless there
> >> has been the find -exec option.
>
>     true -- so why should 'rm' protect against crossing boundaries
> deleting '/' or everything under '.' when there is find?
> 
> find is the obvious solution you are saying, so all that checking in
> rm should be removed, as it is inconsistent with rmdir that can
> cross boundaries.

My mention of 'find' was really a simple statement about alternatives
when programmatic needs are desired.  Because 'find' is the swiss army
chainsaw for directory traversal.  I didn't mean to derail the
discussion there.  But if it is to be derailed then 'find' is the best
choice when needing a specific set of programmatic requirements for
directory traversal.  The other utilities that have simpler
capabilities are the distractions.  But in theory this bug ticket was
about 'rmdir'.

> As for closing something not addressed for 6 years while the problem
> has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't
> seem a great way to judge whether or not a bug is valid or not .

GNU Coreutils rmdir does not provide a recursive delete option.

This bug report so far has contained conflicting complaints to the
point that it has not been useful.  It still is not clear if you are
complaining about 'rmdir' or 'rm' even after requests for
clarification.  Or possibly your shell's ** file glob expansion.
Probably some combination of them all that is unique to your
environment.

To be useful a bug report must be descriptive so that the reader can
understand it.  If the reader can't understand it then how can it be
useful?  The report must be as simple as possible.  Because extraneous
complexity is distracting.  Stay focused on the bug being reported and
not about other unrelated things.  Bugs about behavior should be
reproducible with a test case.  Because nothing is as useful as a
concrete example.

I have reviewed the reports in this ticket and there seems to be no
viable bug report to operate upon here.  At some point without a test
case it only makes sense to say enough is enough and move on since
this does not appear to be a bug in any program of the coreutils
project.  However even though a bug is closed discussion may continue
as we are doing here.  The bug state is simply a way to organize
reports for the purposes of triage.  Many thanks to Assaf for putting
in the work to triage these old bug tickets.

If you wish to report a bug in rmdir's recursive delete option then we
must insist on a test case.

Bob