From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 3 15:59:34 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A08106564A for ; Thu, 3 Apr 2008 15:59:34 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D7FDE8FC0C for ; Thu, 3 Apr 2008 15:59:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m33FxVmg019154; Thu, 3 Apr 2008 17:59:31 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m33FxKDr019153; Thu, 3 Apr 2008 17:59:20 +0200 (CEST) (envelope-from olli) Date: Thu, 3 Apr 2008 17:59:20 +0200 (CEST) Message-Id: <200804031559.m33FxKDr019153@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, mwm-keyword-freebsdhackers2.e313df@mired.org In-Reply-To: <20080324011708.107ec3cb@bhuda.mired.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 03 Apr 2008 17:59:32 +0200 (CEST) Cc: Subject: Re: Problem with find -prune... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2008 15:59:34 -0000 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