URL:
<http://savannah.gnu.org/bugs/?20802>
Summary: find -delete anomalies
Project: findutils
Submitted by: ericb
Submitted on: Friday 08/17/2007 at 11:42
Category: find
Severity: 3 - Normal
Item Group: Wrong result
Status: Confirmed
Privacy: Public
Assigned to: None
Originator Name: Eric Blake
Originator Email: [EMAIL PROTECTED]
Open/Closed: Open
Discussion Lock: Any
Release: 4.3.8
Fixed Release: None
_______________________________________________________
Details:
Shouldn't a failed -delete cause a non-zero exit status, because an error
message was printed to stderr?
$ mkdir a
$ cd a
$ mkdir b
$ touch b/c
$ find -type d -empty -delete
find: cannot delete `./b': Directory not empty
$ echo $?
0
Or since the -delete action results in false on failure, is it still
necessary to also print to stderr?
Likewise, shouldn't -delete attempt (and fail) to delete ., if it has not
been filtered out by a prior expression (such as via -empty, -type f,
-mindepth, etc.)? Here, the fact that . is printed without an error means
that find claims to have deleted ., which is inconsistent (note that even on
platforms where you are permitted to remove the current working directory, you
have to do so via the named directory entry in .., rather than via `.').
$ rm b/c
$ rmdir .
rmdir: .: Invalid argument
$ find -type d -delete -print
./b
.
$ echo $?
0
$
It may be worth comparing this bug report to the results of a recent
coreutils thread, asking for a way come up with a list of successfully deleted
leaf directories (including parents that become leaves during the recursion),
while being silent with regards to non-empty directories:
http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00069.html
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?20802>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
