witr; zcomplete; scc

We’ve got three CLI and shell-oriented tools today that will help you hone your shell typing skills, triage system processes/connections, and make sense of that ugly monorepo your org still uses.

---

witr

When something’s on fire (or just amiss), the go-to question isn’t (or, shouldn’t be) “what is this process?” – it’s more like “huh…why does this process exist?” 

witr (“why is that running”) is a Go CLI built to answer said question. Just point it at a name, PID, port, open file, or container, and it walks the ancestry chain to name the supervisor.

The target inspection flags are composable: mix --pid, --port, --file, and --container in a single invocation and results come back in the typed order. Output modes include a default narrative block, --short for just the ancestry chain, --tree, --json, and --env.

When invoked without args (or w/-i) it drops you into a (quite usable) TUI with process, port, container, and file-lock tabs, plus signal and renice actions on Unix. The tool is very scriptable and has typed exit codes: 0 for clean, 1 for warnings, 2 for not found, 3 for permission denied, 4 for invalid input, 5 for internal.

The target output has some built-in “warnings” that are displayed in a checklist-y format. It’ll flag a process running as root, dangerous capabilities on a non-root process, a listener on 0.0.0.0 (or ::), a high restart count, RSS over 1GB, uptime past 90 days, a deleted binary, and LD_PRELOAD or DYLD_* injection indicators. However, the “
Process is running from a suspicious working directory: /” warning really needs some heuristics to not fire on trusted system processes.

Platform coverage is nigh universal. On Linux, all ops are native since it has full /proc access. The macOS ops use ps/lsof/sysctl/pgrep (with SIP blocking some env reads). Windows ops use Win32 directly (ToolHelp32, PSAPI, Service Control Manager – no WMI, no PowerShell). And, FreeBSD ops use procstat. The spelunking even works with various container frameworks, where the lookup works if you have the container runtime CLI on PATH – docker, podman, nerdctl, crictl, incus, lxc, jls.

The new Safari Technology Preview app beta installed some new background processes, including the sync service you see in the section header image (the TUI lets you filter by name, which is def handy, and how I got to that entry). The ports view is also super helpful and way less painful than lsofing around or dealing with Activity Monitor.

Fair warning: there’s a Claude icon in the contirbutors list, so if that bugs you, def don’t install it, and also delete all your Linux distros since you get AI-assisted code in it as well.

---

zcomplete

Shell typo correction is an old problem. For example, thef__k has handled it for ages, and most shells do have some flavor of command_not_found hook available.

zcomplete by Omar Fakih takes a notably different swing at the idiom. Instead of pulling from a static lookup, it builds a ranked history of commands that you have previously run and resolves typos against said list, with time-decay weighting so the bits you ran an hour ago outrank the bits you ran last month.

The matching layer has four concurrent ops: prefix, initials, subsequence, and edit distance. The aforementioned ranking only breaks ties. Match quality picks the winner.

The system is designed to “learn” on-the fly, so when you run the same correction three times, zcomplete will stop asking; if you refuse it twice, it will quietly retires that suggestion. One clever bit is how it handles subcommands. Rather than shipping a hardcoded verb list, it qualifies a command for subcommand correction once two distinct second words have been observed returning, then runs --help once on unknowns and caches the result.

You should read, the re-read the safety info in the README before installing this tooling. It ships with four modes: safe (which is the default) confirms everything; unsafe confirms only dangerous corrections; bypass executes corrections without a keypress; and off is fairly self-evident.

The dangerous-command list lives in src/safety.rs and it’s quite thorough – rm, dd, mkfs*, git push --force, git reset --hard, terraform destroy, kubectl delete, recursive chmod, curl | sh, and ~30 more. Flag parsing follows shell semantics, so -rf, -r -f, --force, and -- all register properly.

zcompolete’s chosen candidate “fix” must resolve on PATH at time of suggestion, and a shell without a controlling terminal gets no correction. zcomplete’s ops also rely on a history database that stores command names only – never arguments – in a mode 0600 file inside a 0700 directory under ~/.local/share/zcomplete.

The hook (ok, all hooks, not just this one) does have some overhead (0.067 ms on zsh and bash; 0.15 ms on fish), with a full correction against 2,000 learned commands running in roughly 2.2–2.7 ms on an M-series Mac (all that is according to the author; I did no benchmarking).

Some key notes as we close out this section:

• The hook rewrites and executes a command line on your behalf. In bypass mode that happens with no keypress. On a shared or production host, that is a real change to what a typed line does.
• The --help probe executes an arbitrary PATH binary once per unknown command. This is relatively benign on a clean box. On a host with a poisoned or out-of-control PATH, it is an execution primitive triggered by a typo.
• macOS ships bash 3.2, which lacks command_not_found_handle, so, correction moves to the next prompt instead of in place.

On my personal workstation, this has been working pretty well. We’ll see how that goes over time.

---

scc

If you’ve ever needed a fast, accurate line count across a large codebase without having to worry whether Perl is installed or not (like my {cloc} R package does), then scc (Sloc Cloc and Code) by Ben Boyter is worth taking a look at. Version 4.0.0 dropped on 2026-08-23 with some extra crunchy goodness, which we’ll cover in a bit.

Sloc Cloc and Code works by using a state machine per language that tracks comment markers, string delimiters, and blank lines, all without an abstract syntax tree (AST). It can crunch on the entirety of the Linux kernel in ~900 ms (against tokei’s ~1.4 s in Boyter’s own hyperfine runs on a 32-core VM). The counting handles C# verbatim strings correctly, which several other counters quietly get wrong, and it remaps files by shebang or content marker (handy!) so misnamed scripts don’t skew your numbers.

scc’s emits results in whatever format(s) you need – tabular, JSON, CSV, cloc-YAML (ugh), SQL, HTML, OpenMetrics. The --format-multi option can write several simultaneously, so tabular:stdout,csv:out.csv generates them all in a single pass. For cross-repo rollups, -f csv --by-file or -f json --by-file produces DuckDB-ready output (b/c you are using DuckDB for your analyses, right?).

Speaking of analyses, the new work in 4.0 is mostly in the analysis layer. Hotspot identification existed before but now comes with receipts for the maths it uses: complexity × commit_count, normalised to 0–100. Complexity calculations run on the HEAD version of each file only, which means deleted files don’t contribute. This is pretty useful for understanding a repo’s current state, but it’s not great for longitudinal comparisons across a full code tree that has had a great deal of churn. Boyter notes that the hotspot flag is most useful when you point scc at an unfamiliar repo to get a sort of “onboarding map”.

The “change coupling” feature is also new. --coupling lists file pairs that co-appear in commits, with a shared-commit count and coupling percentage. --coupling-for <path> scopes it to one file and gives you the blast radius (i.e., the non-obvious things that may break when you touch a given module). --coupling-weighted applies complexity damping and is gated behind a separate flag since Boyter’s not sure if its actually better. “Cognitive complexity” is also new and was made opt-in. it counts indentation depth and uses nesting level as a multiplier when a branch is hit, which aligns with Sonar’s cognitive complexity computations.

MCP mode (scc --mcp) exposes an analyze tool over stdio with parameters for path, sort order, per-file output, extension filters, and cost estimates. (The README also mentions some other “AI” terms, so heed the same avoid/delete advice from the tool in the first section if that’s your bag.)

For straightforward codebase inventory, I’d have to say it’s the best tool for the particular jobs it tackles, and the coupling and hotspot data are spiffy additions worth exploring.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• Bluesky via <https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy>

☮️