The find program has a -quit cmdline option, which tells it to quit immediately after finding a match and executing previously-specificed commands (like -print). That's very useful, but what if I'm find'ing within several root directories, and want the first match in every one of the roots?

Is there a way of saying something like:

find foo bar baz -print -continue-with-next-root

? Some shell code is ok, but I would like to avoid a separate find invocation for each root folder.

  • I suspect this isn’t what you’re after, but find foo bar baz -print -prune would meet the apparent requirements for your example. It doesn’t work if the tests you’re really interested in involve actually descending inside each directory... (In other words, an example closer to what you really want would ensure you get useful answers.) Commented Dec 10, 2023 at 13:34
  • "I would like to avoid a separate find invocation for each root folder" – Why? IMO the simplicity of this solution is its big advantage. What can we win or substantially improve by inventing an alternative? Commented Dec 10, 2023 at 13:36
  • Prune is close probably, but it stops descending the current hierarchy, and parent directories in the same root would not be pruned. I don't see a way to do this without -quit and a shell loop, and the performance would be the same. i don't see any downsides to using a shell loop.
    – user10489
    Commented Dec 10, 2023 at 13:37
  • If you are using find a lot, you might find using locate to build a database of pathnames an optimal alternative.
    – meuh
    Commented Dec 10, 2023 at 13:47
  • @KamilMaciorowski: I was thinking that, for a large list of root folders, it's more appropriate to avoid a hundred or a thousand invocations of a process.
    – einpoklum
    Commented Dec 10, 2023 at 15:47

1 Answer 1


Bite the bullet and use a separate find invocation for each root folder. The overhead is negligible, and there is no such find option anyway, so you might as well:

for dir in dir1 dir2 dir2 ... dirN; do
   find ... -quit

I really don't think you will find a better solution.

  • 1. Why the ... after find? 2. How negligible?
    – einpoklum
    Commented Dec 10, 2023 at 15:48
  • @einpoklum the is a placeholder (meaning: fill in your options here as used before). A better example can't be given, because you didn't specify any specific find criteria! Commented Dec 10, 2023 at 16:00
  • 1
    @einpoklum why don't you benchmark the overhead? We can't tell you what the limiting factors in spawning processes on your computer are! Generally, when someone says "negligible" it means: can't imagine a case where you can negatively notice the difference; it's not that ambigous a term, even if it's not a precise term. But you're a also not asking a question precise enough to quantify overhead: You're not even telling us what your find criteria actually are, how many files how deep in folders you're searching through, how many starting directories you are considering. Commented Dec 10, 2023 at 16:02
  • @einpoklum And depending on how often you do the task, the optimization you seek may or may not be worth the hassle. Even after finding a faster way, applying it may be uneconomic (example). Commented Dec 10, 2023 at 16:48
  • @einpoklum what the others said. I honestly cannot imagine a situation where launching multiple find commands will be noticeably slower given that the main thing is searching the directories.
    – terdon
    Commented Dec 10, 2023 at 18:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .