find Command Generator

Build a Linux find command from dropdowns: path, name, type, size, age and an action, explained live.

A find command generator builds a Linux find command from dropdowns so you can stop digging through the man page. You tell it where to look, what name to match, the type, maybe a size or age cutoff, then what to do with whatever it catches. The command rewrites itself as you go, and every flag gets a one-line gloss so you actually understand what you are about to run. The second you reach for something destructive like -delete, a red warning lights up, because deleting in the wrong directory is a classic way to lose data. Six presets cover the jobs I reach for most, from finding large files to clearing old logs. None of it leaves your browser.

100% in your browser. Nothing you type ever leaves this page.

find command generator

Under pressure I blank on the exact find syntax. Every time. So I built this to skip the man page. You tell it where to look, what name to match, the type, maybe a size or age cutoff. Then what to do with whatever it catches. The command rewrites itself as you fiddle, each flag gets a one-line gloss, and the second you reach for something that bites back like -delete, a red warning lights up. None of it leaves your browser.

$

What this find command generator does

find crawls down a directory tree, checks each entry against the rules you hand it, then does something with whatever matches. I would argue it is the most useful command on the box, at least for tracking down files by name or size or age and acting on each hit. Here is what trips everyone up. It is not flag-based the way most tools are. It is an expression, read left to right, action bolted on the end. So you fill in dropdowns and the tool assembles that expression in the right order.

Take find . -type f -name "*.log" -mtime +30 -delete. Read it out loud. Start in this directory, and for every regular file ending in .log that nobody has touched in over 30 days, delete it. Everything before that last word is a test. -delete is the action. And because one pass can wipe or run a command across thousands of files, you do not get to be sloppy with the expression.

How find criteria combine

  • Path goes first. It says where to start digging. I lean on . for wherever I am standing, or an absolute path like /var/log when I really want to be sure.
  • -maxdepth N caps how far down it recurses. It is a global option, which means it has to sit before the tests or GNU find gets grumpy about it.
  • -name / -iname match the filename against a shell glob. Quote the pattern. Always. Skip the quotes and the shell expands it before find ever sees it, and then you are stuck wondering why nothing matches.
  • -type narrows things to plain files (f), directories (d) or symlinks (l).
  • -size wants a + for bigger or - for smaller, nothing for an exact match, plus a unit (k, M, G, or c for raw bytes).
  • -mtime / -mmin filter by how long ago a file changed, in days or minutes. +7 means older than seven, -1 means within the last one. The signs still trip me up, so the tool spells it back to you.

Actions: print, delete and exec

Left alone, find just prints what it matched. That is how you should start. It is a free preview of what your tests actually select, no harm done. Swap in -ls and you get a detailed ls -l style line per hit. Then there is -delete, which removes matches with no undo, so I am begging you: run the exact same command without it first and read the list. And -exec runs whatever command you want on each match, with the brace pair standing in for the file path. End it with a plus instead of an escaped semicolon and find crams as many files as it can into one call. Way faster than spawning a fresh process per file.

Safety: preview before you delete

One thing from this page, if that is all you keep: preview first. Run the whole command with plain print, actually read the list it spits out, and only then bolt on -delete or -exec rm. I have watched a single typo-d path chew through a lot more than anyone meant to. Bad afternoon. The red warning here fires the second you pick a destructive action, because -delete wandering into the wrong directory is a genuinely classic way to lose data, and I would rather nag you than let it happen.

Privacy and how this tool runs

It is all just JavaScript running in your browser. Your paths and patterns never touch my server, and I am not logging a thing. Once the page has loaded it even works with the wifi off, if you ever want proof.

Frequently asked questions

How do I find files by name in Linux?

find . -type f -name "*.txt" gets you every regular file ending in .txt below where you are sitting. Do not care about case? Swap -name for -iname. And quote that pattern. Skip the quotes and the shell expands the glob first, then hands find something it never expected.

How do I find large files?

Disk fills up, this is my first move: find / -type f -size +100M turns up everything over 100 megabytes, anywhere on the box. Bump the unit to G if you are hunting gigabyte monsters. I usually tack on -exec du -h with a closing plus and pipe to sort so the actual sizes line up somewhere I can read them.

How do I find and delete files older than 30 days?

find /path -type f -mtime +30 -delete does it. But run it once without -delete first, look hard at what comes back, and only then put the flag on. I will not stop repeating that. If this is ongoing log cleanup, let logrotate own it. find is the right tool for the one-off clear this out today jobs.

What is the difference between -exec run-once-per-file and run-once-per-batch?

Both fire a command at your matches, just differently. A trailing semicolon runs it once per file. Dead simple, and painfully slow once you have got a few thousand of them. A trailing plus stuffs as many files as it can into a single invocation, which is dramatically faster and the one I default to whenever the command can swallow multiple arguments at once.

Why must -maxdepth come before other tests?

Because -maxdepth is not a per-file test at all. It changes how the whole walk behaves. Stick it after a test and GNU find will actually warn you, since the position makes it look like it only kicks in from that point on, which it does not. Safe spot is right after the path. That is where the tool drops it for you, no thinking required.