Linux Commands to Go

Every article here has the same shape. It opens with the command you would actually type — lscpu, curl, ps, grep, envsubst, aws s3 ls — and it closes with a Go program that does the same job in a way you could put on a server and leave running.

That order is the whole point, and it is not the order most tutorials use.

Why start with the command

The command is the fastest way to learn what the data looks like. Before you can write a program that reports CPU usage, you need to know that Linux does not have a “CPU usage” number anywhere — it has a file, /proc/stat, full of counters that only ever go up. You find that out in about forty seconds with cat. You find it out in about two hours if you start by opening an editor.

So the first half of each article is spent in the shell, on purpose, until the concept is concrete and you have seen the actual bytes.

Why not stop there

Because the shell version is a demo, and you will find out where it stops the hard way. Three examples, all of them from articles in this series:

• It is fine until it has to be a number. grep will find the slow requests in an nginx log. It will not give you the 95th percentile, and the awk one-liner that does is write-only by the third field.
• It is fine until there is more than one of something. A for host in ...; do ssh ...; done loop is a perfectly good deploy script for three servers. At thirty it is a fifteen-minute deploy where one host failed and you cannot tell which, because the output of thirty SSH sessions arrived interleaved.
• It is fine until it has to be right. Reading /proc/stat once gives you the average CPU usage since the machine booted, which is a number that looks plausible and is useless. You need two reads and the difference between them. The CPU article walks into that wall deliberately, then fixes it.

The Go half is not there because Go is fashionable. It is there because a single static binary with no runtime, no dependency tree, and real error handling is the thing you can copy onto a server and trust — and because writing it forces you to answer the questions the command was quietly answering for you.

The five ideas that keep coming back

Read three or four of these and you will notice the same handful of problems wearing different clothes. They are the actual curriculum:

The kernel talks to you in text. /proc/stat, /proc/meminfo, /proc/<pid>/status — CPU monitoring, process management, and health checks all end up reading the same pseudo-filesystem. Once you have parsed one of these you have parsed all of them.

Counters are cumulative; you want deltas. Almost every metric Linux exposes is a number since boot. Sample it twice, subtract, divide by the interval. Miss this and your dashboard confidently displays the wrong thing forever, which is worse than displaying nothing.

Parsing is where the bugs live. Not the network code, not the concurrency — the parsing. A timestamp that is ambiguous twice a year when the clocks go back. An nginx log line with a space inside a quoted field. A sudoers file with an #includedir in it. The interesting failures in this series are nearly all somebody’s text format meeting reality.

Do it to one thing, then do it to N things. Every tool here has a step where it stops handling one server and starts handling a list of them, and the step after that is always about the failure modes that only appear at N: one host hanging forever, partial success, output that has to stay attributable to the host it came from.

“Failed” needs a definition. Exit codes, signals, HTTP status, a health check that is neither up nor down. The deploy tool needs to decide what triggers a rollback. The supervisor needs to decide what counts as a crash worth restarting. Getting this wrong is how you build something that restarts a healthy process in a loop.

How to read this

Not in order. These were written as independent articles over about four years, and none of them assumes you have read another. Pick the one that matches a problem you currently have — that is the version of this you will actually finish.

If you want a route anyway:

• Shortest way in: Master tmux. Small, immediately useful, and the Go part is a thin CLI over commands you already ran by hand.
• The series in miniature: CPU Monitoring. Two commands, a wrong answer, the reason it is wrong, and the fix. If you only read one, read this one.
• The one that changes how you work: Deployment Automation, because rollback and parallelism are where hand-rolled deploy scripts stop being adequate.

What you need

A Linux or macOS shell, and Go 1.21 or newer. A few articles want Docker (container logs, nginx logs) and two want an AWS account with credentials configured — the free tier covers everything they do. No Kubernetes anywhere in the series. No framework. The Go programs use the standard library and, where a cloud API is involved, that vendor’s SDK; nothing else.

Every article is self-contained: the code is complete rather than elided, and it is built up a step at a time so you can stop at any point and still have something that runs.

What this does not cover

There is no Kubernetes, no service mesh, no Terraform here — those live elsewhere on this site. This series is deliberately about the layer underneath: the commands on the box, the files they read, and what it takes to turn one into a program you would leave running.