| 1 |
On Sep 13, 2013 9:53 PM, "Yuri K. Shatroff" <yks-uno@××××××.ru> wrote: |
| 2 |
> |
| 3 |
> On 13.09.2013 17:43, Mark David Dumlao wrote: |
| 4 |
>> |
| 5 |
>> On Fri, Sep 13, 2013 at 9:36 PM, Yuri K. Shatroff <yks-uno@××××××.ru> |
| 6 |
wrote: |
| 7 |
>>> |
| 8 |
>>> On 13.09.2013 10:24, Jean-Christophe Bach wrote: |
| 9 |
>>> [ ... ] |
| 10 |
>>> |
| 11 |
>>>> |
| 12 |
>>>> This one should work: |
| 13 |
>>>> |
| 14 |
>>>> find /home/joseph/ -iname "*.pdf" -exec ls -l --sort=time {} + |
| 15 |
>>> |
| 16 |
>>> |
| 17 |
>>> |
| 18 |
>>> -exec is not suitable here because it spawns a `ls` process per each |
| 19 |
found |
| 20 |
>>> entry; aside from being slow, this disallows sorting at all. |
| 21 |
>> |
| 22 |
>> |
| 23 |
>> This is incorrect. If you terminate exec with '+' instead of '\;', only |
| 24 |
a single |
| 25 |
>> instance of the command is run - the command line is built by appending |
| 26 |
>> each found file to the end of the {} placeholder. |
| 27 |
> |
| 28 |
> |
| 29 |
> Sorry, I'm ashamed |
| 30 |
> I didn't know about this feature. Does it also handle spaces correctly? |
| 31 |
> |
| 32 |
|
| 33 |
I'm not sure how the internals work. As best as I can guess, it constructs |
| 34 |
the argv directly so spaces shouldn't be an issue. Spaces are an issue when |
| 35 |
the output is piped through, since the pipe itself knows no difference |
| 36 |
between filename and output spaces, hence the need to force zero delimiters |
| 37 |
between filenames. Since find runs the command directly, you shouldn't |
| 38 |
encounter this. But Ive yet to test. |
| 39 |
|
| 40 |
> |
| 41 |
>> The only reason I see for it to fail is if you have so many files that |
| 42 |
>> it can't be |
| 43 |
>> passed to the argv of the receiving command. |
| 44 |
> |
| 45 |
> |
| 46 |
> There's always an opportunity to use tempfiles ;) |
| 47 |
> |
| 48 |
> |
| 49 |
> |
| 50 |
> -- |
| 51 |
> Best wishes, |
| 52 |
> Yuri K. Shatroff |
| 53 |
> |
Archives