On 2/10/2019 1:52 PM, Bob Proulx wrote:
> 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.
----
As near as I can tell the rmdir case derives from
the similar case (assuming -x as shorthand for --onefilesystem),
under 'rm -frx foo/*' or 'cd foo && rm -frx *'
that was suggested as a replacement for the
desired rm -frx foo/. or 'cd foo && rm -frx .'
The first two forms of rm using '*' have no limit on the number
of file systems that can be affected.
Only the form 'foo/.' or '.' when used with --one-filesystem
will be actually limited to one-file-system.
If rmdir ever had a related but (now can have more so with -p),
it could also affect multiple dirs with 'rmdir foo/*'
Now you can't claim '*' is a somehow disallowed as it was
suggested as a workaround for disallowing rm -frx foo/.
But any form with 'rm' or rmdir can unsafely affect multiple
file systems on multiple systems, as users are told to use
shell-wildcards to make up for being unable to specify the
top level inside dir for deletion.
The reason things proably got so chaotic is that when it as
suggested that '*' be used with rm -frx *, one-filesystem was
no longer just 1 file system.
1) pray tell, why would it be called one file system when its
not? Now it's one-filesystem / root arg? Uh huh. That
sounds more than a bit specious to me.
2) if 'rm' really limited its deletes to 1 file system (ensuring
all it's cmd line args were on the same file system, Then the
same feature can be applied to rmdir to prevent it going from
touching different file systems in 1 command. Of couse with -p
as it back tracks, each back track and imply a change of
file system.
I can't find the original posts, but early comments applied to
'rm'. Some people seem to change titles of bugs without really
understanding what the root bug was about, so the fact that
something has rmdir in the title now doesn't really mean the
original was about rmdir.
Might want to examine that policy so things won't get as confusing --
adding on to a title in a separate field (gnu-summary), seems
like it might be less consusing that changing the original title.
That's my best guess at what this is about, but trying to recall
details where my original didn't seem to get posted back to me
(I thought it did, maybe things have chnaged in 6 years?).
-l
Since to delete all files under a directory with something
like (assuming '-x' for '--one-filesystem')
rm -frx * or rmdir * can all delete things on multiple
file systems.
Note, multiple responders, in discussing rm -frx
>
> 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
