From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ME3JS-0001vc-Ap for garchives@archives.gentoo.org; Tue, 09 Jun 2009 15:32:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CBC51E04D9; Tue, 9 Jun 2009 15:32:32 +0000 (UTC) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by pigeon.gentoo.org (Postfix) with ESMTP id 7767AE04D9 for ; Tue, 9 Jun 2009 15:32:32 +0000 (UTC) Received: by ewy9 with SMTP id 9so47411ewy.34 for ; Tue, 09 Jun 2009 08:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=yJyL14as1pT0t16USHLqy5xVFXjlWMpHzX5o5pTU9OU=; b=ngPZ5lMjBv6grNnIlBHoaxhsOR1pADzvzYFevv74autTJq9+jjszG5yF+Mr+HOWZXR 5qqVZrXq1S+Fe9Z6YPQK4BzGSTaJZF3FBm0XQuy0QwH3Z9e4HZ8lDdTT9P6PEQqu4au4 FdunalhtEGtwOyD0T8JknNvpDVwPYdiuBs+7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=VfvHRvavMMYrAIhgz1dMjwjcRvcGPPRNDtCgHFdlV7hSWSMKGdMQcO5R8mlCj9+hyC neCC6zpkLLyefx8r8tcM9epbn+WERtUcj6OpoNma98hRmJONChlQy1wj9jklbrMzcaKA hgfpHPCf0Acq9TPS1RD77RSBjlpXQr+8gp5bQ= Received: by 10.216.24.206 with SMTP id x56mr92270wex.39.1244561551701; Tue, 09 Jun 2009 08:32:31 -0700 (PDT) Received: from nazgul.localnet (196-210-153-123-rrdg-esr-2.dynamic.isadsl.co.za [196.210.153.123]) by mx.google.com with ESMTPS id 5sm51777eyf.28.2009.06.09.08.32.29 (version=SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 08:32:30 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Finding orphaned libs Date: Tue, 9 Jun 2009 17:30:58 +0200 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; x86_64; ; ) References: <200906082244.18324.alan.mckinnon@gmail.com> <20090609153635.41a07c5b@zaphod.digimed.co.uk> <200906091720.49610.shrdlu@unlimitedmail.org> In-Reply-To: <200906091720.49610.shrdlu@unlimitedmail.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906091730.58440.alan.mckinnon@gmail.com> X-Archives-Salt: f6eb5a7c-dcb9-47ef-b510-31dcbd9623d4 X-Archives-Hash: 85dbda19091b955419bf0c5e476394c2 On Tuesday 09 June 2009 17:20:49 Etaoin Shrdlu wrote: > On Tuesday 9 June 2009, 16:36, Neil Bothwick wrote: > > On Tue, 09 Jun 2009 16:15:21 +0200, Joerg Schilling wrote: > > > > find -H /usr/lib /lib -type f | xargs -d'\n' qfile --orphans > > > > > > No, this is definitely wrong: the right way to handle this is > > > execplus (since 19 years). > > > > If it's been around 19 years, why doesn't Google know anything about > > it? What is it? > > Well, google does not know everything :) > > Basically, using + instead of ; after -exec allows to run the specified > command less times, each time with the highest possible number of > arguments (instead of running it once per file, which is what happens > with ;). And yes, that's been in POSIX for a long time now. Example: > > > $ ls > file1 file2 file3 file4 file5 > > $ find . -type f -exec sh -c 'echo "number of arguments: $#"' sh {} \; > number of arguments: 1 > number of arguments: 1 > number of arguments: 1 > number of arguments: 1 > number of arguments: 1 > > $ find . -type f -exec sh -c 'echo "number of arguments: $#"' sh {} + > number of arguments: 5 > > So when you have to run a command on a very big number of files, say 1000 > or more, with ; you spawn 1000 processes, with + you span just one or > two (well, depending on the maximum command line length on the system > anyway). This is of course much less resource intensive. Some numbers. These are from memory, I ran these commands today while preparing a machine for an installation of a package. The directory tree at the starting point had about 5000 files, more than 80% with a UID not attached to an account: chown -R : * about 2 seconds find . -nouser -o -nogroup -exec chown : {} + about 30 seconds (wild guess) find . -nouser -o -nogroup -exec chown : {} \; I killed this one after 5 minutes and it was nowhere near complete Admittedly, this was on a vmware guest with a rather poor disk configuration, but it does illustrate that the naive "find \;" performs extremely poorly. chown on it's own is foolish as the whole point of the exercise was to find files meeting certain criteria, and there was definitely some that didn't. execplus is a fine middle ground giving the best possible bang for buck. -- alan dot mckinnon at gmail dot com