In article ,
Bill Marcum wrote:
>On Sun, 20 Jul 2003 12:19:28 -0700, Julia Bell
> wrote:
>> Using tcsh
>>
>> Is there a way to limit 'find' to stop after finding one file that
>> matches the criteria?
>>
>> I realize I can always pull of the first file found; I just don't want
>> it wasting time looking for additional files once it finds the first one.
>>
>find ... | head -1

That's precisely what the second paragraph said he *doesn't* want to do.

AFAIK find doesn't have a built-in option to do it. Here's a simple
solution:

find ... -print -exec perl -e 'kill "INT", getppid' \;

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

That doesn't address the issue - as I said in the message, I'm looking
for a way to only FIND the first file so it doesn't waste time looking
for additional files - not just pull off the name of the first file it
finds.


Bill Marcum wrote:
> On Sun, 20 Jul 2003 12:19:28 -0700, Julia Bell
> wrote:
>
>>Using tcsh
>>
>>Is there a way to limit 'find' to stop after finding one file that
>>matches the criteria?
>>
>>I realize I can always pull of the first file found; I just don't want
>>it wasting time looking for additional files once it finds the first one.
>>
>
> find ... | head -1
>
>

On 07-21 21:13 CDT, Julia Bell wrote:
> Bill Marcum wrote:
>> On Sun, 20 Jul 2003 12:19:28 -0700, Julia Bell
>> wrote:
>>>Is there a way to limit 'find' to stop after finding one file that
>>>matches the criteria?
>>>
>>>I realize I can always pull of the first file found; I just don't
>>>want it wasting time looking for additional files once it finds the
>>>first one.
>>
>> find ... | head -1
>
> That doesn't address the issue - as I said in the message, I'm
> looking for a way to only FIND the first file so it doesn't waste
> time looking for additional files - not just pull off the name of
> the first file it finds.

I'm not sure if I'm reading these results right, but this example on
my system:

$ time (find /usr)
[...snip...]

real 0m2.26s
user 0m0.45s
sys 0m1.42s

$ time (find /usr/|head -1)
/usr/

real 0m0.02s
user 0m0.01s
sys 0m0.01s

shows that the pipe cuts the processing time down dramatically. Does
anyone know if this mean that the find command is actually terminated
at that point, thus preventing it from searching for more than one
file?

--
GROG! __^__ Ending a sentence in a preposition is something
thks /(o o)\ up with which I will not put! - Yoda's High
--oOO==(_)==OOo-- School English teacher.
(email: grog-at-sixbit-dot-org)

In article ,
GROG! wrote:
>I'm not sure if I'm reading these results right, but this example on
>my system:
>
> $ time (find /usr)
> [...snip...]
>
> real 0m2.26s
> user 0m0.45s
> sys 0m1.42s
>
> $ time (find /usr/|head -1)
> /usr/
>
> real 0m0.02s
> user 0m0.01s
> sys 0m0.01s
>
>shows that the pipe cuts the processing time down dramatically. Does
>anyone know if this mean that the find command is actually terminated
>at that point, thus preventing it from searching for more than one
>file?

It gets killed when it finds the *second* matching file. At that point it
tries to print it, and gets a SIGPIPE signal because the head process has
terminated.

In your example, that happens right away, so you get a big saving. But if
find has to do lots of searching before it gets to the second matching
file, you'll waste lots of time.

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

begin Barry Margolin wrote:
> In article ,
> GROG! wrote:
>>I'm not sure if I'm reading these results right, but this example on
>>my system:
>>
>> $ time (find /usr)
>> [...snip...]
>>
>> real 0m2.26s
>> user 0m0.45s
>> sys 0m1.42s
>>
>> $ time (find /usr/|head -1)
>> /usr/
>>
>> real 0m0.02s
>> user 0m0.01s
>> sys 0m0.01s
>>
>>shows that the pipe cuts the processing time down dramatically. Does
>>anyone know if this mean that the find command is actually terminated
>>at that point, thus preventing it from searching for more than one
>>file?
>
> It gets killed when it finds the *second* matching file. At that point it
> tries to print it, and gets a SIGPIPE signal because the head process has
> terminated.
>
> In your example, that happens right away, so you get a big saving. But if
> find has to do lots of searching before it gets to the second matching
> file, you'll waste lots of time.
>
Then use (find /usr/ -name '*target*'|sed 1q)

sed puts the first line into its buffer, sees the 1q command, prints the
buffer and exits.

--
"As long as they are going to steal it, we want them to steal ours. They'll get
sort of addicted, and then we'll somehow figure out how to collect sometime in
the next decade." -- Bill Gates, explaining how Microsoft views software piracy