Problem with find -prune...

[Oliver Fromme]

Mike Meyer <> wrote:
 > find -prune seems to not quite do what it says. At least, when delete
 > is used. Here's an example tree (on 7.0-RELEASE, amd64 build):

It behaves exactly as documented.  I'll try to explain.

 > bhuda% find /tmp/x -prune
 > /tmp/x
 > 
 > Hmm, it prints the root of the tree. That might be a bug;
 > might not.

It's not a bug:  -prune prevents find(1) from descending
*into* the directory, but the directory itself is still
handled.

 > bhuda% find /tmp/x -prune -o -print
 > bhuda% 
 > 
 > Making the print conditional on not pruning, and we always prune.
 > Ok, now let's look at what looks to me like a bug:
 > 
 > bhuda% find /tmp/x -prune -o -delete
 > find: /tmp/x/y: Permission denied
 > 
 > Why on earth (or off it) is find trying to look at /tmp/x? Am I
 > correct in assuming that this is a bug?

The -delete primary implicitly assumes depth-first
traversal (i.e. the -d option), because that's the
only way you can delete a whole directory tree.

However, when depth-first traversal is in effect,
the -prune primary doesn't have any effect (for
obvious reasons).  It's documented in the manpage.

In other words, the primaries -prune and -delete
are mutual exclusive.  It could be argued whether
find(1) should print a warning in that case.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"IRIX is about as stable as a one-legged drunk with hypothermia
in a four-hundred mile per hour wind, balancing on a banana
peel on a greased cookie sheet -- when someone throws him an
elephant with bad breath and a worse temper."
        -- Ralf Hildebrandt