Unix Frugality: do more with less

There is a test I run mentally when I read code or when someone introduces themselves: do I find a cat file.txt | grep pattern where a grep pattern file.txt would do?

This is not an optimization question. The cost of one forked process is negligible. It is a culture question: cat | grep betrays someone who learned commands as incantations, not as composable bricks. And the principle behind the short version is the very foundation of Unix: do more with less, small is beautiful. Each brick does one thing, does it well, takes text in and produces text out.

This article assembles what I have defended over twenty-five years at the terminal: the two commands that precede all others, a design lesson from the 2000s, a minimal but auditable toolkit and the precise spot where frugality must yield to a bigger tool.

apropos and man, before everything else

Two commands to know before all: apropos and man.

Not apt, not systemctl, not the framework of the year. When asked for the essential command list of a Linux/BSD operator, I start there and the lists I’m offered starting with ln tr sed locate env are already very far from covering the trade. The muscle memory of a sysadmin is not three hundred IDE shortcuts, it is knowing how to find the documentation of what you don’t know yet.

A detail that sums up the spirit: shutdown and reboot are symlinks to systemctl. Those who read the man page know it, those who didn’t believe they know two commands. Same for apt: it is very “debian-like specific”, other distributions exist and within Debian itself, apt-get, apt-cache and dpkg are part of the deal.

And the direct corollary: absolutely nobody who has read the man pages and understood Unix permissions does a chmod 777 “just to make it work”. I’ve seen it done by beginners and by “devs” who couldn’t care less and didn’t really understand what they were doing. The 777 is not a syntax error, it is a symptom of unread documentation.

The dsniff lesson: small chainable tools

My reference for tooling design comes from the 2000s: the dsniff suite. Small, simple, scriptable tools, each doing one thing well, taking text in and producing text out. It was very practical for chaining commands and scripting attacks or demos.

On the opposite side, Ettercap: a monolithic, heavy, sometimes unstable tool, with a GTK interface doing more harm than good and distribution problems between 2010 and 2013 with compromised packages. Today I point to Bettercap for modern MitM (Ethernet, WiFi, BLE, HTTP/HTTPS interception, packet injection, modules), but the lesson stays dsniff’s.

The rest of the toolbox follows the same logic: you don’t have to leave your terminal to analyze your traffic. Capture with tcpdump or tshark, offline analysis with NetworkMiner or Zeek, IDS/NDR probe with Suricata and Arkime and NetFlow for the infra. Each brick is usable alone, scriptable, chainable. The opposite of frugality is not richness, it is monolithism.

A minimal toolkit and its honest limit

The everyday frugal toolkit, I detail it in the ancestor of Ansible : a key/value .env, a well-kept ~/.ssh/config, SSH/SCP, well-structured bash and a template engine like envsubst or mo. I will not re-enumerate it here, what matters is why the choice holds.

Every component is auditable, no magic involved and it runs anywhere there’s a bash, a ksh or a zsh. Sessions live in a text file you can read, template, distribute via a repo. No daemon, no state database, no license.

But I owe the limit: that is also exactly what Ansible does, adding idempotency, error handling, parallelism and hundreds of community-maintained modules. Reinventing all of that in shell is educational, but quickly becomes time-consuming in production. Better to move to Ansible (or Salt, Puppet) and focus your energy on the infrastructure rather than the tooling.

The frugal rule is not “do everything by hand”, it is “know exactly where handcraft stops”: on one machine, for a simple need, shell beats everything. Across a hundred machines with state and concurrency, handcraft becomes its own technical debt.

The editor: declarative and reproducible

For all those languages: vim or neovim is enough.

My setup is declarative and reproducible: the config lives in a repo (.vim or .config/nvim per project), plugins are managed by vim-plug or a small homegrown manager based on git submodules and a fresh workstation is operational in under three minutes. No marketplace, no extensions phoning home, no .vscode squatting every repo with diverging recommendations.

A necessary precision: not hiring someone because they use VS Code or VSCodium is pure stupidity. The frugality test is not the tool you brandish, it is what you can do without it.

Kali: learning security, not administration

Last point and it fits in one sentence: Kali is good for learning security, not Linux administration.

Kali is an excellent entry point for learning, CTFs and OSCP-type certifications, zero debate. But presenting Kali as “essential for IT professionals” confuses two trades: offensive security and system administration. The operator who learned Linux on Kali knows a distribution whose kernel is patched, whose services run as root by default and where pentest ethics outrun operational hygiene. To learn administration, take a standard distribution and read the man.

Summary

• cat | grep is not a performance mistake, it is a cultural marker. The short version is the lesson: composability, one brick, one task.
• apropos and man before every other command. The chmod 777 betrays unread man pages, not a lack of talent.
• The dsniff suite remains the design reference: small tools, text in and out, chainable. The opposite of frugality is monolithism (Ettercap), not richness.
• The .env + .ssh/config + bash + envsubst toolkit is auditable and universal; the honest limit is Ansible: don’t reinvent idempotency in shell in production.
• The editor must be declarative and reproducible, not universal. And judge nobody on their editor.
• Kali teaches offensive security, not administration. To administer: standard distribution and man.