Fri 17 Aug 2007 05:42:30 PM UTC, original submission:
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
|