From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-150655-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 72C081381F3
for <garchives@archives.gentoo.org>; Sat, 14 Sep 2013 04:04:13 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id EDAD5E0DC6;
Sat, 14 Sep 2013 04:04:04 +0000 (UTC)
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id E69C8E0D8A
for <gentoo-user@lists.gentoo.org>; Sat, 14 Sep 2013 04:04:03 +0000 (UTC)
Received: by mail-ie0-f180.google.com with SMTP id u16so4118897iet.39
for <gentoo-user@lists.gentoo.org>; Fri, 13 Sep 2013 21:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=MHdFqms6t0mRaRSZaQsDz/zIYF2tirM7DSz0//ELyr4=;
b=OgrmARxlcC9AR2ItlpntQxG0q79baS0r/ZFp0K+XZqXSs+kr9a+Ea+GHzUf7OQD6MH
woJSSJYt5sFqs7JkiNCf+1A3nVLclwM3E3HXNvV7CR94iX5wTCtZ8/HPmSzWA4Ojhz/Q
4tTl+msAOCBHwj3otxYjhvwwkOX43GVp2zt21kvha3fn0Z9qhX8Unc8w72T0RCq0y1nn
oEYp+zfxYntlBAUKNJe8xE7oJ7BcdEYY2cmFHqNFXObeOM9fFCKjzdn/jWby0CWMulkE
Tf+h/i2k4NkacGmU+yhlTzuWQCMH6imJRG35l9lgvAuG/ZfbG5izy1g+N2zTofQFkdyP
FnQQ==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.50.7.101 with SMTP id i5mr2611574iga.48.1379131443061; Fri,
13 Sep 2013 21:04:03 -0700 (PDT)
Received: by 10.50.158.163 with HTTP; Fri, 13 Sep 2013 21:04:02 -0700 (PDT)
Received: by 10.50.158.163 with HTTP; Fri, 13 Sep 2013 21:04:02 -0700 (PDT)
In-Reply-To: <52331848.8030603@yandex.ru>
References: <20130913044830.GA4586@syscon7.inet>
<CADPrc80WJ90kqjoaJrBgK5O2dQ7airjAhrYLWSREkUfiivQ06w@mail.gmail.com>
<CADPrc82NSorzJCX7CT6GL4mMNu+ZSsZdxFoD5RtQNAgas8+45g@mail.gmail.com>
<20130913051148.GB4586@syscon7.inet>
<CADPrc8317DW403G1rZviiubQ3HWK343NO5KhFjd0wpq1X0kmpA@mail.gmail.com>
<20130913062401.GK6228@Morgoth>
<523314C2.3040308@yandex.ru>
<CAG2nJkNTTXwEGMrrFepFtf4y-Xm0SE_o0PumrxoK=8_d4rEEsg@mail.gmail.com>
<52331848.8030603@yandex.ru>
Date: Sat, 14 Sep 2013 12:04:02 +0800
Message-ID: <CAG2nJkO0qTWPC4t9G-t+90AjqicsKrMmcMsyQDk-o06pt=XmaQ@mail.gmail.com>
Subject: Re: [gentoo-user] look for a file type + sort
From: Mark David Dumlao <madumlao@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=089e0111d5e4c32b0204e6500f5a
X-Archives-Salt: 0338c2a7-7329-4a91-bf3a-4fb612eb3650
X-Archives-Hash: ec17876682d6006e3b8362a643421709
--089e0111d5e4c32b0204e6500f5a
Content-Type: text/plain; charset=ISO-8859-1
On Sep 13, 2013 9:53 PM, "Yuri K. Shatroff" <yks-uno@yandex.ru> wrote:
>
> On 13.09.2013 17:43, Mark David Dumlao wrote:
>>
>> On Fri, Sep 13, 2013 at 9:36 PM, Yuri K. Shatroff <yks-uno@yandex.ru>
wrote:
>>>
>>> On 13.09.2013 10:24, Jean-Christophe Bach wrote:
>>> [ ... ]
>>>
>>>>
>>>> This one should work:
>>>>
>>>> find /home/joseph/ -iname "*.pdf" -exec ls -l --sort=time {} +
>>>
>>>
>>>
>>> -exec is not suitable here because it spawns a `ls` process per each
found
>>> entry; aside from being slow, this disallows sorting at all.
>>
>>
>> This is incorrect. If you terminate exec with '+' instead of '\;', only
a single
>> instance of the command is run - the command line is built by appending
>> each found file to the end of the {} placeholder.
>
>
> Sorry, I'm ashamed
> I didn't know about this feature. Does it also handle spaces correctly?
>
I'm not sure how the internals work. As best as I can guess, it constructs
the argv directly so spaces shouldn't be an issue. Spaces are an issue when
the output is piped through, since the pipe itself knows no difference
between filename and output spaces, hence the need to force zero delimiters
between filenames. Since find runs the command directly, you shouldn't
encounter this. But Ive yet to test.
>
>> The only reason I see for it to fail is if you have so many files that
>> it can't be
>> passed to the argv of the receiving command.
>
>
> There's always an opportunity to use tempfiles ;)
>
>
>
> --
> Best wishes,
> Yuri K. Shatroff
>
--089e0111d5e4c32b0204e6500f5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p><br>
On Sep 13, 2013 9:53 PM, "Yuri K. Shatroff" <<a href=3D"mailto=
:yks-uno@yandex.ru">yks-uno@yandex.ru</a>> wrote:<br>
><br>
> On 13.09.2013 17:43, Mark David Dumlao wrote:<br>
>><br>
>> On Fri, Sep 13, 2013 at 9:36 PM, Yuri K. Shatroff <<a href=3D"m=
ailto:yks-uno@yandex.ru">yks-uno@yandex.ru</a>> wrote:<br>
>>><br>
>>> On 13.09.2013 10:24, Jean-Christophe Bach wrote:<br>
>>> [ ... ]<br>
>>><br>
>>>><br>
>>>> This one should work:<br>
>>>><br>
>>>> find /home/joseph/ -iname "*.pdf" -exec ls -l --=
sort=3Dtime {} +<br>
>>><br>
>>><br>
>>><br>
>>> -exec is not suitable here because it spawns a `ls` process pe=
r each found<br>
>>> entry; aside from being slow, this disallows sorting at all.<b=
r>
>><br>
>><br>
>> This is incorrect. If you terminate exec with '+' instead =
of '\;', only a single<br>
>> instance of the command is run - the command line is built by appe=
nding<br>
>> each found file to the end of the {} placeholder.<br>
><br>
><br>
> Sorry, I'm ashamed<br>
> I didn't know about this feature. Does it also handle spaces corre=
ctly?<br>
></p>
<p>I'm not sure how the internals work. As best as I can guess, it cons=
tructs the argv directly so spaces shouldn't be an issue. Spaces are an=
issue when the output is piped through, since the pipe itself knows no dif=
ference between filename and output spaces, hence the need to force zero de=
limiters between filenames. Since find runs the command directly, you shoul=
dn't encounter this. But Ive yet to test.</p>
<p>><br>
>> The only reason I see for it to fail is if you have so many files =
that<br>
>> it can't be<br>
>> passed to the argv of the receiving command.<br>
><br>
><br>
> There's always an opportunity to use tempfiles ;)<br>
><br>
><br>
><br>
> -- <br>
> Best wishes,<br>
> Yuri K. Shatroff<br>
><br>
</p>
--089e0111d5e4c32b0204e6500f5a--