find is a programming language and nobody uses it

Bala Krish — Thu, 16 Apr 2026 02:58:17 +0000

90% of find usage looks like this:

find . -name "*.log"

Which is like using Python only for print("hello").

The operators nobody uses

Time-based filtering

Find files modified in the last 30 minutes:

find /var/log -mmin -30

Files NOT accessed in the last 90 days:

find /home -atime +90

Files newer than a reference file:

find /etc -newer /etc/passwd

That last one is wild. "Show me everything in /etc that changed after the last password update." Incredibly useful for incident response - if you know when the breach happened, you can find every file modified after that timestamp.

Permission filtering

Find all SUID binaries (a classic security audit):

find / -perm -4000 -type f

Files writable by others:

find /var -perm -o+w -type f

Files with no owner (orphaned after a user deletion):

find / -nouser -o -nogroup

Size filtering

Files over 100MB:

find / -size +100M -type f

Empty files (often leftover from crashed processes):

find /tmp -empty

Combining conditions

find supports AND (implicit), OR (-o), and NOT (!). With parentheses for grouping.

"Log files over 10MB that haven't been modified in a week":

find /var/log -name "*.log" -size +10M -mtime +7

"Config files that are world-writable OR have no owner":

find /etc \( -perm -o+w -o -nouser \) -type f

-exec is where it becomes a language

-exec executes a command on each result. The {} is replaced with the filename, and \; terminates the command.

Delete old temp files:

find /tmp -mtime +30 -type f -exec rm {} \;

Change ownership of orphaned files:

find / -nouser -exec chown root {} \;

But the real trick is -exec with + instead of \;. The semicolon variant runs one command per file. The plus variant batches files into a single command invocation, like xargs:

find /var/log -name "*.log" -exec gzip {} +

That's one gzip call with hundreds of arguments, not hundreds of gzip calls. On a system with 50,000 log files, the difference is minutes vs seconds.

-delete is the dangerous one

find has a built-in -delete action. It's faster than -exec rm because it avoids forking a subprocess for each file.

find /tmp -name "*.cache" -mtime +7 -delete

The danger: -delete implies -depth (processes directories bottom-up). If you put -delete in the wrong position with other filters, it can delete more than you intended. Always test with -print first.

Real incident response example

Server compromised. You know the attacker got in around 14:00 yesterday. Find every file modified since then:

touch -t 202604151400 /tmp/marker
find / -newer /tmp/marker -not -path "/proc/*" -not -path "/sys/*" -type f

Create a reference file with the known breach time. Find everything newer. Exclude virtual filesystems. This gives you a timeline of everything the attacker touched, including backdoors, modified configs, and planted scripts.

Now pipe it to get details:

find / -newer /tmp/marker -not -path "/proc/*" -type f -exec ls -la {} +

Full permissions, ownership, and timestamps for every modified file. Ten seconds to run. Manual inspection of each directory would take hours.

Why this isn't taught well

find has terrible man page ergonomics. The options are dense, the interaction between operators is non-obvious, and the difference between -exec {} \; and -exec {} + is buried in a paragraph that reads like a POSIX spec.

Most people learn find . -name "pattern" and stop there because the next level of the man page is intimidating. Understandable. But the difference between "I can find files by name" and "I can audit an entire filesystem in one command" is about two hours of practice with the operators above.

Several of the Linux challenges on SudoRank use find as the primary tool. Not because find is the only way, but because it's usually the fastest.

I got my React SPA to 95/100/100/100 on mobile PageSpeed

Bala Krish — Tue, 31 Mar 2026 05:54:31 +0000

81/93/92/92 → 95/100/100/100. Mobile, simulated slow 4G. Here's everything I did, including the stuff that backfired.

The site is SudoRank - React 19, TanStack Router, Tailwind 4, running on Cloudflare Pages with 523 prerendered pages.

Before: 81/93/92/92

- single 313 KiB gzip bundle, zero code splitting, Google Fonts from CDN, Clarity and GA loading eagerly. Basically every mistake you can make.

Fonts

Google Fonts means three origin connections on slow 4G. Tried @fontsource-variable packages first - score tanked 81 → 67, fonts got bundled into JS. Downloaded the .woff2 files instead, @font-face with font-display: swap in public/fonts/.

Analytics

Wrapped Clarity + GA in a setTimeout(fn, 3500). Page is rendered by then. GA still picks up the pageview, Clarity replays from initialization.

Also tried font preloads here - score went 77 → 74. Preloads fought the JS bundle for bandwidth on 1.6 Mbps.

Code splitting

TanStack Router has built-in code splitting. I hadn't turned it on. 22 routes in one 313 KiB bundle, including xterm.js (342KB raw).

TanStackRouterVite({ autoCodeSplitting: true })

Homepage JS went from 313 KiB to ~164 KiB gzip. FCP 3.0s → 2.1s, LCP 3.9s → 2.6s. This was the entire Performance improvement.

The other three scores

SEO: Cloudflare was injecting non-standard directives into robots.txt. Wrote my own. 92 → 100.

Best Practices: Four CSP violations from analytics domains I hadn't whitelisted. Added them. 92 → 100.

Accessibility took two rounds. First was a low-contrast text color and a heading skip (h1 jumped to h3). That got it from 93 to 95. The second one was harder - a purple label on a card with a semi-transparent purple background. The contrast checker said it was fine because I was testing against the base dark bg, not the composited result. Compositing rgba(139,92,246,0.06) onto #13131A gives something like #1A1727, and the contrast dropped to 4.14:1. Changed to a lighter purple. 95 → 100.

Where it ended up

After: 95/100/100/100

Metric	Before	After
FCP	3.0s	2.0s
LCP	3.9s	2.6s
TBT	30ms	0ms
Speed Index	3.0s	2.0s

Getting to 100 would mean inlining critical CSS and shrinking React core under 80KB. Google ranks on Core Web Vitals, not Lighthouse scores. All CWV are green.

I grew up in Trichy with dial-up. Pages rendered one line at a time. PageSpeed's simulated slow 4G isn't far off. We used to just wait. Now a 3-second load and people think your site is broken.

SudoRank if you want to run PageSpeed on it yourself.

DEV Community: Bala Krish