The Shell Engineer's Toolkit, Part 2: Processes, Networks, and System State
These commands form the operational half of shell scripting. Knowing how to safely inspect and signal processes, test network reachability at the port level, and pull system metrics without forking extra processes separates a brittle script from one that runs reliably in production.
The second installment of a shell command series shifts from static files to the dynamic, running system. It catalogs the tools for process management—ps, top, jobs, nohup, kill, and nice—and explains when to reach for each, from one-off snapshots to real-time monitoring and signal-based control. The network section covers connectivity testing with ping and nc, HTTP operations with curl, remote access via ssh and rsync, and DNS debugging with dig. A final block on system information details commands like uname, free, df, and direct reads from /proc, which avoids forking a new process in scripts. The emphasis throughout is on safe defaults, practical combinations, and the observation-first, action-second mindset required when commands can affect live services.
The article frames shell proficiency not as memorizing flags but as pattern recognition—knowing which tool fits a given operational moment. This mirrors how experienced engineers actually work: they recall a capability, then look up the exact syntax.
The distinction between 'observation' and 'control' commands is a useful safety heuristic. Commands that can mutate system state (kill, pkill) demand a verification step first, a practice that is often skipped in hurried debugging.
Preferring direct /proc reads over command calls is a small optimization that compounds in scripts with many system checks, yet it remains underused outside of advanced Linux environments.