Am 14.09.2013 06:04, schrieb Mark David Dumlao: > > On Sep 13, 2013 9:53 PM, "Yuri K. Shatroff" <yks-...@yandex.ru > <mailto:yks-...@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-...@yandex.ru > <mailto:yks-...@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. >
Your assumption is correct. exec cannot be fooled with whitespaces. Regards, Florian Philipp
signature.asc
Description: OpenPGP digital signature
