Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to force the find command to stop right after finding the first match?

share|improve this question
TheUnseen: The reason that it quits after five results when piped to head -n 5 is because head exits after five results. When head exits the pipe closes and sends a signal to the program piping into it to terminate as well. Sorry for not responding directly to you, apparently you need 50 reputation to reply. – Ruste May 22 '15 at 17:33
up vote 58 down vote accepted

With GNU find, you can use the -quit predicate:

find . ... -print -quit

If all you do is printing the name, and assuming the filenames don't contain newline characters, you could do:

find . ... -print | head -n 1

That will not stop find after the first match, but possibly, depending on timing and buffering upon the second match or (much) later. Basically, find will be terminated with a SIGPIPE when it tries to output something while head is already gone because it has already read and displayed the first line of input.

If you're doing more than printing the paths of the found files, you could try this approach:

find . ... -exec sh -c 'printf "%s\n" "$1"; kill "$PPID"' sh {} \;

(replace printf with whatever you would be doing with that file).

That has the side effect of find returning an exit status reflecting the fact that it was killed though.

Actually, using the SIGPIPE signal instead of SIGTERM (kill -s PIPE instead of kill) will cause some shells to be more silent about that death (but would still return a non-zero exit status).

share|improve this answer
In case anybody needs to test whether any file matches the predicates, stopping as soon as one is found, in Bash and GNU Find you can do: if [[ $(find ... -print -quit) ]]; then ... It just tests whether find printed anything at all. – Tobia Dec 19 '14 at 18:26

For entertainment purposes, here's a lazy find generator in Bash. This example generates a ring over the files in the current directory. Read however many you want then kill %+ (maybe just 1)

#!/usr/bin/env bash
unset -v files n
trap 'kill "$x_PID"' EXIT

coproc x while :; do
    find . -type f -maxdepth 1 -exec sh -c "$(</dev/fd/3)" _ {} +
done 4<&0 <<\EOF 3<&0 <&4-
for x; do
    read -r _
    printf '%s\0' "$x"

    echo >&${x[1]}
    IFS= read -rd '' -u "$x" 'files[n++]'
    printf '%q ' "${files[@]}"
    sleep .2
share|improve this answer
find . -name something -print -quit

Terminates find after the first match after printing it.

Terminate find after a specific amount of matches and print results:

find . -name something -print | head -n 5

Surprisingly enough - head now terminates string after 5 matches, though I do not know how or why.

It is very easy to test. Just let find search a on root which would result thousands, maybe even more matches while taking at least a minute or more. But when piped into "head" "find" will terminate after the specified amount of lines defined in head (default head shows 10, use "head -n" to specify lines).

Note that this will terminate after "head -n" reaches the specified newline character count and therefore any match that contains multiple newline characters will count accordingly.

share|improve this answer
I have also observed this 'program terminates after head is done with its output' phenomenon, but not consistently across shells. I think this merits its own question - fortunately for bash the answer is already at StackOverflow's Bash: Head & Tail behavior with bash script. That gives enough information for me to conclude that whether the program terminates or continues to execute in the background depends on its response to SIGPIPE - killing is the default. – sage Oct 16 '15 at 16:04
I meant 'across *programs*/shells', but apparently unix.stackexchange.com would prefer that I log this as a second comment rather than letting me edit my first comment (this is a stackexchange, site-specific policy decision). Also, I now see that @Ruste commented to this effect at the top, which did not help me initially since I went straight to answers... – sage Oct 16 '15 at 16:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.