`find` Becomes Dangerous Only After You Skip the Preview Step and Jump Straight to `-delete`

The worst find mistakes are usually not syntax mistakes. They are judgment mistakes: running a destructive expression before proving that the selection matches what you think it matches.

Why find still earns its place

Modern codebases create a lot of file noise: cache directories, temporary outputs, screenshots, fixture dumps, debug archives, old logs, generated bundles. At some point you need to ask the filesystem a smarter question than “what files are in here?”

That is exactly what find is for. The GNU manual frames it as a tool for searching directory trees and processing files that match criteria. That sounds humble, but it covers a huge amount of real development work.

The first good habit: print matches before acting

Start with a pure preview:

find . -type f -name '*.log'

This should be the reflex. Do not begin with delete actions. Begin with selection logic.

If the file pattern or scope is wrong, the preview exposes it while the stakes are still low.

Why quotes matter

Patterns should usually be quoted:

find . -name '*.tmp'

Without quotes, your shell may expand the wildcard before find sees it. That can turn a file-search expression into something very different from what you intended.

This is one of those details that feels tiny until it causes a cleanup command to behave strangely.

The commands people actually need

Find directories named node_modules:

find . -type d -name 'node_modules'

Find large files:

find . -type f -size +100M

Find screenshots from automated tests:

find . -type f -name '*.png' -path '*/playwright-report/*'

None of these are dramatic, but they solve the kinds of problems developers hit every week.

Why -delete deserves respect

Once your preview looks right, then deletion becomes reasonable:

find . -type f -name '*.log' -delete

The problem is that developers often skip straight here because they are in cleanup mode. That is exactly when thinking gets sloppy. The selection may be broader than expected, the scope may start too high, or a pattern may catch files you still needed.

find is not reckless. It is obedient. If you give it a bad selection and then add a destructive action, it will execute your mistake very efficiently.

Why -exec is often a better step than immediate deletion

Sometimes you want one intermediate layer of control:

find . -type f -name '*.log' -exec ls -lh '{}' ';'

or:

find . -type f -name '*.log' -exec rm '{}' ';'

This pattern matters because it makes the action explicit and adaptable. Maybe today the right follow-up is rm. Tomorrow it might be gzip, mv, or diff.

A practical cleanup workflow

When dealing with generated clutter:

1. start with a narrow scope
2. preview the matches
3. confirm file type or path logic
4. only then add the action

That sequence is boring, and boring is good. Boring workflows are what prevent filesystem cleanup from turning into recovery work.

Final recommendation

Use find as a selector first and an action runner second. Preview matches before you delete anything, quote your patterns, and keep the search scope honest. The command becomes much safer once you stop treating it like a one-shot cleanup missile.

Sources

• GNU Findutils manual
• Invoking find