Linux Commands & Shell Skills
find: The Linux Search That Does Everything
find is the most dangerous command on a production server, and that is exactly why it deserves mastery. It enumerates, filters, and executes in one expression, and every classic '/var here be dragons' incident traces back to a preview someone skipped. The habits are mechanical: walk with -print or -ls first, batch with -exec ... +, pipe through -print0 into xargs -0, and treat -delete as a second-pass decision, never a first draft.
Key points
- Filter on metadata, not name alone: -type f, -mtime +30, -size +100M, and -perm -o+w locate the odd files that naming conventions and age reports both miss.
- Preview every destructive query: find /var/www/uploads -name 'core.*' -ls first, swap -ls for -delete only after you actually read the list; the preview is the safety check, not a suggestion.
- -exec cmd {} + batches files into few invocations and beats the \; form on large trees; the same syntax powers 'rm every matching file in one process' without an argument-list-too-long error.
- Null-safe output by default: find . -name '*.old' -print0 | xargs -0 rm -v; plain pipes into xargs are a known data-loss pattern the day a filename contains a space.
- -xdev and -maxdepth keep the walk honest: they stop find from following into mounts and snapshots, which rescues both runtime and your assumptions about 'this directory'.
- Time windows are precise if asked precisely: -mmin -1440 for the last 24 hours, -newermt '2026-01-01' for since a date, and remember -xtime means 'n full 24-hour periods ago' before quoting it in a ticket.
- Prune deliberately: find . -path '*/node_modules' -prune -o -name '*.js' -print skips the one directory that otherwise outweighs the rest of the tree in size and time.
- Expect nonzero exits on unreadable directories; stderr lines like 'Permission denied' are skipped files, not data, so scripts either tolerate find's exit status or check it explicitly instead of assuming clean walks.
Field note
Our worst find -delete story started with an unquoted -name pattern that the second shell expanded into three words upstream of find. The rule since is simple: -print first, quote always, and -delete never rides in a command the first time it runs.
Frequently asked questions
My find found files but the downstream command did nothing. Why?
Almost always quoting or empty input: the pattern was expanded by the shell before find saw it, or xargs received nothing. Quote patterns, and pair -print0 with xargs -0 every single time.
-delete or rm after find?
-delete is direct, fast, and unforgiving; it cannot be mixed with -exec in the same expression. Run the matching -print first and read it; that is the whole discipline.
Why does find print permission errors on system directories?
Components you cannot read print errors to stderr and make find exit nonzero; filter with 2>/dev/null for interactive comfort, and never interpret those errors as absence of files.
Difference between -mtime and -ctime again?
-mtime is content change, -ctime is metadata change (permissions, rename, hardlink count); a chown or a move bumps ctime without touching mtime, which confuses exactly one report a quarter.
How Kinetikatech helps with linux commands & shell skills
Here's the deal: The commands and scripting habits that decide whether an administrator operates a server or fights it: search, transform, transfer, and supervise text and processes with the tools that live in every base install. Hand it to our Linux Server Security and Server Management service and it's covered, assessed properly, implemented cleanly, monitored around the clock.