Re: Could we have a flag to tell us which directories were actually removed?

[Jim Meyering]

Reuben Thomas <address@hidden> wrote:
> On Wed, 15 Aug 2007, Jim Meyering wrote:
>
>> Reuben Thomas <address@hidden> wrote:
>>> I just had a situation where this would have been useful. I tried -v
>>> --ignore-fail-on-non-empty, but of course it told me about every
>>> directory it processed, which is fine, but not what I wanted.
>>
>> Why add a new option?
>
> In this case, I don't see a good way of getting the same
> information. The best way I could come up with that was short enough
> for command-line use was use find to find directories with only 2
> symlinks to them, but of course that only works on some filing
> systems.

Bob Proulx presented a couple ways to do what you want.

>> While adding a new rmdir option may look simple, there are larger
>> implications that make it so you'd have to provide significant
>> justification.
>
> What are they in this case? Seems to me that it's just printing a
> diagnostic on an already-existing code path (the one where the
> directory is unlinked), and hence has no major code burden. Of course
> there's the usual overhead of documentation &c...

If the functionality you want is easy enough to obtain through a small
(portable) wrapper script, then there's little point in adding a new option.

Even so, if the functionality is requested often enough, that
may end up being sufficient.

One down-side of adding a new option is that it provides a non-portable
way of solving the problem (i.e., it works only with the GNU version of
the tool), and it's available only if you have the very latest release
of the coreutils.