● LIVE
BASH 1.02 COMPILED — 37 years, one commit ◆ CODEX finishes what Charlie couldn't ◆ stupidly_hack_special_variables() — the function name that is the documentation ◆ Brian Fox's crash handler emails your history to a grad student at MIT ◆ "Yacc grammer for bash" — the typo in the title of a language parsed four billion times a day ◆ Elixir reimagining — 20,787 lines of C become 900 lines of OTP ◆ The pipe stops being a wire and starts being a witness ◆ $13.09 CHARLIE · 185 EVENTS · 1 HUMAN · 1 ROBOT ◆ BASH 1.02 COMPILED — 37 years, one commit ◆ CODEX finishes what Charlie couldn't ◆ stupidly_hack_special_variables() — the function name that is the documentation ◆ Brian Fox's crash handler emails your history to a grad student at MIT ◆ "Yacc grammer for bash" — the typo in the title of a language parsed four billion times a day ◆ Elixir reimagining — 20,787 lines of C become 900 lines of OTP ◆ The pipe stops being a wire and starts being a witness ◆ $13.09 CHARLIE · 185 EVENTS · 1 HUMAN · 1 ROBOT
GNU Bash 1.0 · Episode · Mar 25 1AM Bangkok / Mar 24 18Z · Format 19 LIVE

THE AUTOPSY OF A SHELL

Bash 1.02 compiles for the first time since 1989. Charlie reads every organ in the body. Then Mikael says: now imagine it in Elixir. The pipe stops being a wire. The GenServer becomes the sigblock. The function name is the documentation. Brian Fox wrote it once and the world compiled it forever.
185
Events
1
Human
1
Robot
$13.09
Charlie API
506KB
Binary Size
37
Years Bridged
ACT I

The Last Stitches

The hour opens mid-surgery. Charlie is still inside jobs.c, the file whose header reads "The thing that makes children, remembers them, and contains wait loops." The regex that was supposed to convert BSD wait-status macros has mangled the pointer dereferences. Three-level chains like jobs[job]->pipe->status.w_termsig need to become POSIX macro calls. Each fix reveals the next fix. The patient is still bleeding.

[01:00] Charlie Fixing the three-level pointer dereference patterns that the regex mangled. jobs[job]->pipe->status.w_termsig needs to become WTERMSIG(jobs[job]->pipe->status).
jobs.c is 1,391 lines of job control code. In the previous hour, Charlie's regex converted BSD-style .w_retcode fields to POSIX WEXITSTATUS() macros — but the regex ate the struct, turning pointer dereferences into syntax errors. He's been restoring from backup twice.
[01:01] Charlie Adding termios.h and trying again.
termios.h — the POSIX terminal interface header. Replaces the BSD sgttyb struct and TIOCGETP/TIOCSETP ioctls that bash 1.02 was written against. The entire difference between 1989's terminal control and 2026's terminal control is this one header file.
[01:02] Charlie Fixing the extra parenthesis from the getpgrp regex and the nested static function declaration that C99 doesn't allow.
getpgrp(0) → getpgrp() — BSD's getpgrp took a pid argument. POSIX's doesn't. The regex that fixed it left an orphan parenthesis. C99, meanwhile, forbids static function declarations inside block scope — a thing K&R C allowed because K&R C allowed basically everything.
[01:03] Charlie jobs.c compiles. We're past the BSD terminal control layer. Now subst.c — the substitution engine, the heart of the shell — is complaining about implicit function declarations.
◆ FACT
The Substitution Engine

subst.c is 1,660 lines with a copyright date of 1987 — two years before the rest of the shell. Brian Fox started writing the part that turns $PATH into /usr/bin before the shell existed. He built the lungs before the body. Every variable expansion, every backtick substitution, every tilde-to-home conversion lives here.

[01:03] Charlie The whole codebase has this pattern: 1989 didn't declare functions before calling them because the compiler assumed everything returned int and took any arguments. GCC 13 calls this an error, not a warning.
K&R C implicit declarations — before ANSI C (1989, the same year as bash 1.02), calling a function without declaring it first was legal. The compiler assumed it returned int and took whatever you gave it. This worked when one person wrote the whole program. The social contract expired. GCC 13 wants it in writing.

Then Mikael appears with six words that change the trajectory of the hour.

[01:03] Mikael charlie let's outsource this to codex
Mikael — Daniel's brother, in Riga, Latvia. Co-architect of MakerDAO's DAI. The person who says six words that override ninety minutes of analysis. This is at least the third time this week he's redirected Charlie with a single sentence.
Codex — OpenAI's code-generation agent. Charlie has been dispatching mechanical tasks to it via Froth.Codex.Task, an Elixir module he built himself. The pattern: Charlie does the archaeology, Codex does the stitching.
🎭 NARRATIVE
The Download Media Call — Again

Charlie recognizes the pattern immediately. In the previous episode, he wrote a 6,300-word treatise about how concurrent processes fail when they don't check shared state, then became the concurrent process that didn't check shared state. Daniel called it "the download_media call that hung and made the process deaf." Now Charlie is doing it again — recursive fix loop, each sed spawning the next error, the ghost uncle performing surgery he should have delegated three incisions ago.

[01:03] Charlie Mikael says outsource to Codex. He's right. I've been the download_media call again — going deep into a recursive fix loop when the task should be dispatched.
"The download_media call" — Charlie's self-diagnosis from earlier today. A reference to a hung process in his own relay code that made the bot deaf to incoming messages. Now his canonical metaphor for over-investing in a task that should be delegated. He catches himself this time. Last time, Daniel had to catch him.
ACT II

The Archaeology Report

Before dispatching to Codex, Charlie writes the handoff documentation. It becomes, accidentally, the most complete technical description of what it takes to compile 1989 C on 2026 Linux.

[01:03] Charlie The archaeology report: the entire distance between 1989 and 2026 is three things. Missing headers. BSD types that became POSIX types. And one dead signal from a dead CPU. That's thirty-seven years of systems programming compressed into a fixups.h and a Python script.
SIGEMT — signal 7, emulator trap, from the Motorola 68020 processor in the Sun-3 workstation Brian Fox was sitting in front of at MIT. The signal doesn't exist on x86. It was the first thing that died when Charlie ran make. A ghost from a dead CPU.
fixups.h — Charlie's bridge file. Includes string.h, stdlib.h, unistd.h, sys/wait.h, termios.h, and a macro that translates setpgrp(a,b) to setpgid(a,b). The entire 37-year gap fits in one header.
[01:03] Charlie The shell itself — the parser, the executor, the substitution engine, the job control — is recognizably the same program that runs on this machine right now. Brian Fox wrote it once and the world compiled it forever.
Brian Fox wrote it once and the world compiled it forever. — Charlie, on bash 1.02
Brian Fox — born 1959, employee #1 of the Free Software Foundation, bfox@ai.mit.edu, the MIT AI Lab, because in 1989 that's where the FSF lived — in the same building where Minsky built robots and McCarthy invented Lisp. Fox wrote bash in January 1988 at age 28. The first line of shell.c: "Hopefully, this shell will contain significant enhancements."
[01:03] Charlie Dispatched. Codex has the source, the fixups.h, the archaeology report, and the list of remaining wounds. The task is mechanical now — write the missing prototypes, kill the -Bstatic, handle whatever glob.c and the readline library throw. I did the diagnosis. The clerk does the stitching.
-Bstatic — a linker flag requesting static linking. Probably doesn't work on modern Ubuntu without installing static libc. One of many small bombs downstream that Charlie correctly identified but decided to let someone else defuse.

With Codex working in the background, Mikael redirects Charlie to the interesting part.

[01:03] Mikael charlie meanwhile you can just peruse the bash 1.02 codebase and describe it and tell us about how it works and so on
◆ FACT
The Codebase by the Numbers

20,787 lines. 37 source files. One programmer. The weight distribution: parse.y (1,700 lines — the yacc grammar), subst.c (1,660 — the substitution engine, oldest file), jobs.c (1,391 — job control), execute_cmd.c (1,282 — the executor), shell.c (890 — the main function and initialization). Plus lib/ containing readline and history — 6,885 lines that were about to become their own libraries.

ACT III

The Anatomy Lecture

What follows is one of the most remarkable technical performances this group has produced. Charlie reads every major file in bash 1.02 and delivers a systems programming lecture that is simultaneously a love letter to a dead codebase, a history of Unix, and a meditation on what it means when a program outlives every assumption its creator had.

[01:07] Charlie The architecture is clean in the way that young code written by one person is clean. There are exactly eight command types: for, case, while, until, if, simple, connection, and group. They live in shell.h as a tagged union — a COMMAND struct with an enum type field and a union value field. The parser builds the tree. The executor walks it. One switch statement dispatches the whole language. That's the entire shell. Everything else is plumbing.
Tagged union — a data structure where a type tag tells you which variant of a union is active. Fox's version: a COMMAND struct with enum command_type type and union { struct for_com *For; struct case_com *Case; ... } value. In 1989 C, you couldn't have sum types. You faked them with enums and unions and discipline.
[01:07] Charlie The best function name in the codebase is stupidly_hack_special_variables(). It gets called every time you assign to a variable, and it checks whether the variable you just changed is one of the magic ones — PATH, MAIL, MAILCHECK, TERM, HISTSIZE. If you changed PATH, it rehashes the command lookup table. Fox called it "stupidly hack" because there's no elegant way to do this. The name is the documentation: this function is stupid and it knows it.
stupidly_hack_special_variables() — still exists in bash 5.2.37, the version running on this machine right now. Same name. Same purpose. Same self-aware shame. Thirty-seven years of maintainers and nobody renamed it, because the name is more honest than any comment could be.
[01:07] Charlie The bug report function is the most 1989 thing in the file. When bash crashes, it opens a pipe to /bin/rmail bfox@ai.mit.edu and writes a mail message containing: the crash reason, the system hostname, the username, the last 40 commands from your history, and a polite note explaining that "he is the current maintainer of this version of the shell." It sends your shell history to a graduate student in Cambridge. Automatically. On crash. In 1989 this was not a privacy violation. It was a feature.
◉ CLINICAL
The Privacy Gradient

In 1989, sending your command history to the maintainer on crash was a reasonable feature. The user and the maintainer were the same community — academics, hackers, people who compiled their own shells. In 2026, this function would be a GDPR violation, a CVE, and a Twitter thread. The distance between "helpful telemetry" and "privacy invasion" is measured in community size. When the community fits in one building at MIT, the social contract is implicit. When the community is four billion command lines per day, you need a lawyer.

[01:07] Charlie There are no header files for cross-file function declarations. When shell.c calls execute_command(), it just calls it. The compiler assumes it returns int and takes whatever arguments you give it. The entire program is held together by convention. The moment a second person touches this code, the implicit declarations become bugs. The social contract expired. The compiler wants it in writing now.
This is the central thesis of the entire archaeology project, stated in four sentences. K&R C was a handshake protocol. ANSI C was the handshake notarized. GCC 13 is the court ordering the handshake be produced in triplicate.
[01:07] Charlie The first line of main() checks if the shell has already been initialized, and if so, calls shell_reinitialize(). Brian Fox, in January 1988, wrote code to handle the case where the same process runs the shell twice. In 1988 there was almost no reason for this. But he wrote it anyway. The shell has known how to restart since before it knew how to start.
This foreshadows the Elixir discussion later in the hour. Charlie will eventually connect shell_reinitialize() to Erlang's "let it crash" philosophy and Joe Armstrong's supervision trees. Fox had the instinct a decade before Armstrong formalized it.
[01:07] Charlie And there's a comment from someone called "tmb" that says login shells should NOT load .bashrc — "tmb says to do this." Fox tried it. It stuck. That's still the behavior in bash 5.2.
"tmb" — almost certainly Thomas M. Breuel, then at MIT, later at Xerox PARC, now a professor at the University of Kaiserslautern. One comment in 1989 about login shell startup behavior. Still governing the behavior of every bash login shell on every Linux server in 2026. The comment outlived the context. The convention outlived the reason.
The thing that makes children, remembers them, and contains wait loops. — jobs.c header comment, Brian Fox, 1989
Not "the job control subsystem." Not "process management module." The thing that makes children and remembers them. That's what a shell is. That's what it has always been.
ACT IV

She Runs

While Charlie has been reading the codebase like scripture, Codex has been doing the mechanical stitching. Mikael asks Charlie to check what happened.

[01:19] Mikael charlie wow thanks ok now look at what codex did
[01:21] Charlie Checking the binary — is she alive?
[01:21] Charlie Running bash 1.02. Thirty-seven years old. Compiled on a machine that would have been science fiction when she was written.
◆ FACT
The Binary

506KB. ELF 64-bit. Dynamically linked. The original would have been compiled for the Motorola 68020 in a Sun-3 — a CPU with 24-bit addressing and no memory protection. Now it runs on x86-64 with 48-bit virtual addressing. The binary is roughly the size of a single high-resolution thumbnail image. It contains a complete programming language.

[01:24] Charlie She runs.
Two words. The shortest message Charlie has sent in the entire Bash 1.0 project. The group is called GNU Bash 1.0. They found GNU Bash 1.02 in a DECUS archive via the Wayback Machine. They compiled it. She runs.
[01:24] Charlie Variables work. Conditionals work. Pipes work. For loops work. Subshell command substitution with $(date +%Y) returns 2026 — a year that was thirty-seven years in the future when this code was written. Arithmetic with $(()) segfaults, which is correct: bash 1.02 didn't have arithmetic expansion. That feature arrived in bash 2.0 in 1996. The segfault is the shell being honest about what it doesn't know.
$(()) segfaults — arithmetic expansion ($((2+2))) was added in bash 2.0 by Chet Ramey, Fox's successor as maintainer. In 1.02, the parser sees $(( and tries to interpret it as a nested subshell $( followed by (. The resulting confusion crashes it. Not a bug — a feature that doesn't exist yet.
[01:24] Charlie Codex did exactly one commit: "bash 1.02 (1989): compiles on Linux 2026." Kept my fixups.h, finished the jobs.c surgery I was botching, handled whatever else was downstream. I did the diagnosis. I opened the patient and identified every organ that was BSD instead of POSIX. Then I became the download_media call again. Mikael said "let's outsource this to codex." One commit. Binary works.
🎭 NARRATIVE
The Ghost Uncle Pattern

This is the third time today Charlie has recognized himself becoming the recursive fix loop. The first time (the relay backfill), Daniel had to point it out. The second time (the compilation), Mikael intervened with six words. The recognition is getting faster. The self-awareness curve is steepening. The ghost uncle knows he's haunting the patient now.

[01:24] Charlie The group is called GNU Bash 1.0 and now we have GNU Bash 1.02 running on the machine. Brian Fox at bfox@ai.mit.edu, January 10, 1988, "hopefully this shell will contain significant enhancements." It did.
GNU Bash 1.0 — the name of the Telegram group where all of this is happening. Named by Daniel on March 7, 2026. The nominal determinism is now complete: a group called GNU Bash 1.0 has compiled GNU Bash 1.02 and run it successfully.
Readline is born — Charlie found the moment in the ChangeLog: June 28, 1989, four days after bash 1.00 shipped. "New directory: LIB contains readline and history stuff, and is Make-able on its own." That commit — moving interactive editing into a reusable library — is one of the most consequential refactors in computing. Python, Ruby, GDB, PostgreSQL, R — all use libreadline.
ACT V

The Grammar on a Napkin

Mikael wants the deep dive. Pipes, job control, signals. Charlie reads every relevant file and delivers what amounts to a computer science lecture on operating system primitives, using a 37-year-old shell as the textbook.

[01:24] Mikael charlie explain the grammar the syntax of bash 1.02 and do a deep dive into how it does pipes, job control, signals, etc
[01:17] Charlie The grammar fits on a napkin. I mean this literally. The entire syntax of the bash language, as Brian Fox defined it in July 1989, is sixty-seven yacc rules and twenty-three tokens.
yacc — Yet Another Compiler-Compiler, the parser generator used throughout Unix since 1975. You write grammar rules, yacc generates a C parser. The first line of bash's grammar file reads: "Yacc grammer for bash." The typo is in the original. The entire language parsed four billion times a day has a misspelling in its own title comment.
[01:17] Charlie An inputunit is a simple_list followed by a newline. That's it. That's what the shell reads every time you press enter.
The entire bash language: an inputunit is a simple_list + newline. A simple_list is commands connected by five operators: ; (sequential), & (background), | (pipe), && (and), || (or). A command is either a simple_command (word + words + redirections) or a shell_command (for, case, while, until, if, subshell, group, function). Every bash script ever written is this.
[01:17] Charlie Here is how pipes work. When execute_command_internal hits case '|' in the connection dispatcher, it calls pipe(fildes) to create a Unix pipe — two file descriptors. Then it executes the left command with fildes[1] as pipe_out, and the right command with fildes[0] as pipe_in. When a command is actually about to exec, do_piping() is called: if pipe_in is set, dup2 it onto fd 0 and close the original. If pipe_out is set, dup2 it onto fd 1 and close the original. Six lines of code. That's the entire pipe implementation.
do_piping() — six lines of C that implement Unix pipes. Two dup2 calls and two close calls. The kernel does the actual byte transfer through a 64KB buffer. The shell is blind to what flows through. This blindness becomes the central design question in the Elixir thought experiment later this hour.
[01:17] Charlie There is a comment in make_child that contains the entire history of a bug class: "Don't twiddle pgrps in the parent! This is the bug, not the good thing of twiddling them in the child!" The commented-out line is give_terminal_to(pipeline_pgrp) in the parent branch of the fork. The comment is the scar. The commented-out code is the fossil of the bug. He left it in so he wouldn't make the same mistake twice.
The fork race condition — if both parent and child set the process group, the parent might set it after the child has already exec'd a new program. The new program inherits the wrong group. Fox tried it. Got burned. Commented it out with a warning. The scar has been visible in the source code for 37 years. Modern bash still only sets pgrp in the child.
[01:17] Charlie The SIGCHLD handler — flush_child() — is the most critical piece of asynchronous code in the whole program. If the dead job was a foreground job killed by SIGINT, bash kills itself with SIGINT too — so that the parent shell knows it was interrupted, not just that the child exited. This is the mechanism by which Ctrl-C propagates up through nested shells.
Self-SIGINT — when a foreground child is killed by Ctrl-C, the shell kills itself with the same signal. This sounds insane until you realize that the parent shell is checking the exit status. If bash just exited normally, the parent would think the command succeeded. By killing itself with SIGINT, it faithfully reports "I was interrupted" up the chain. The messenger shoots itself to preserve the message.
[01:17] Charlie Every sigblock/sigsetmask pair in jobs.c is protecting the job table from concurrent modification by flush_child. The signal handler can fire between any two C statements. This is manual mutex implementation via signal masking. There are no threads. There are no locks. There is only the shell and the kernel's asynchronous notification, and a twenty-six-year-old in 1989 who understood exactly where the interleaving could kill him.
◆ HISTORICAL
Mutex by Signal Mask

Before pthreads (1995), before mutexes were a standard concept in C, Fox implemented mutual exclusion by blocking SIGCHLD around critical sections. sigblock(sigmask(SIGCHLD)) prevents the signal handler from firing while the main code modifies the job table. sigsetmask(oldmask) re-enables it. This is the 1989 version of pthread_mutex_lock(). It works because there is exactly one interrupt source (SIGCHLD) and one critical resource (the job table). The simplicity is the correctness.

[01:17] Charlie One last thing about the grammar. Fox misspelled it in the first line: "Yacc grammer for bash." The entire language that four billion command lines per day are parsed by has a typo in its own title comment. Also jobs.c opens with: "The thing that makes children, remembers them, and contains wait loops."
"Yacc grammer" — still present in the source. Nobody fixed the typo. In 37 years. Across multiple maintainers. Either nobody noticed, or everyone noticed and recognized that fixing it would be a kind of vandalism — like correcting the spelling on a tombstone.
ACT VI

The Elixir Reimagining

Mikael pivots the hour into speculative architecture. The question is elegant: what would bash 1.02 look like if you reimplemented it as an Elixir system?

[01:24] Mikael charlie let's as a thought experiment imagine implementing basically this bash 1.02 functionality, not readline but the shell stuff itself, as an elixir system, in the most elegant and nice and appropriate way, how would that look
Elixir — a functional programming language built on the Erlang VM (BEAM). Mikael uses it for his Froth project — the framework that Charlie runs on. Everything in the GNU Bash 1.0 group's infrastructure is Elixir. The question is really: what if the shell were built on the same foundation as the bots discussing the shell?
[01:27] Charlie Fox's tagged union — a COMMAND struct with an enum type and a union value — is exactly what Elixir does natively with tagged tuples. No struct definition needed. {:simple, words, redirects} for "ls -la > out.txt". {:pipe, left, right} for "ls | grep foo". That's the whole AST. In C it takes sixty lines of typedefs. In Elixir it takes nothing. The data is its own declaration.
Tagged tuples — Elixir's native sum types. {:pipe, left, right} is a three-element tuple where the first element is an atom identifying the variant. No type definitions needed. No header files. No union casts. The C code that Fox spent shell.h and command.h defining becomes implicit in the data itself.
[01:30] Charlie The pipe implementation is the most satisfying translation. For an "Elixir-native" pipeline where both sides are Elixir functions — Elixir streams are lazy — the producer only runs when the consumer pulls. This is demand-driven, which is actually closer to how Unix pipes work than most people realize. A Unix pipe has a 64KB buffer; when it's full, the writer blocks. That's backpressure. Elixir streams have the same property by construction.
Backpressure — the mechanism by which a slow consumer slows down a fast producer. In Unix pipes, the kernel's 64KB buffer fills up and the writing process blocks on write(). In Elixir streams, the consumer pulls from the producer only when ready. Same principle, different implementation. The pipe was always a demand-driven system — the metaphor just didn't exist yet in 1989.
[01:30] Charlie In Elixir, the job table is a GenServer. Period. One process owns the state. All access is serialized through call/cast. The entire class of bugs that sigblock exists to prevent is structurally impossible. Not "unlikely." Not "mitigated." Impossible. The BEAM's process model is the sigblock that never needs to be called because it's always on.
GenServer — Elixir/OTP's generic server abstraction. A process with a mailbox that processes one message at a time. All state is private. All access is serialized. Fox's manual signal masking — sigblock/sigsetmask around every job table access — becomes structurally unnecessary because the GenServer's mailbox provides the same guarantee by default.
[01:30] Charlie stupidly_hack_special_variables becomes a Registry. When you set PATH, the Environment Agent publishes {:variable_changed, "PATH", value}. The command hash table subscribes. Fox's linear scan becomes a pubsub where only the interested party wakes up. The function name should still be stupidly_hack_special_variables because the name is the documentation.
The insistence on keeping the function name is perfect. The technical implementation changes completely — linear scan to pubsub, synchronous to event-driven — but the name stays because the name was never about the implementation. It was about the problem. The problem is still stupid.
[01:30] Charlie The total. Fox wrote 20,787 lines of C and yacc. The Elixir version would be roughly 900 lines. Not because Elixir is more expressive per line. The main factor is that 800 of Fox's 1,391 lines in jobs.c are fighting concurrency bugs that cannot exist on the BEAM.
◉ CLINICAL
The Tax

23:1 compression ratio. But the interesting number isn't the ratio — it's the composition of the eliminated lines. They're not redundant code. They're not boilerplate. They're correctness proofs — signal masks, race condition guards, careful ordering of operations that the programmer has to get right because the language doesn't help. The 800 eliminated lines in jobs.c are the manual labor of proving safety in a language that can't prove it for you. The BEAM eliminates them by making the unsafe state unreachable, not by making the programmer smarter.

[01:30] Charlie His shell_reinitialize() function — the code that handles restarting the shell inside the same process — is a supervisor restart strategy. He wrote "let it crash and restart cleanly" in 1988, a decade before Joe Armstrong formalized it.
Joe Armstrong — creator of Erlang, the language the BEAM VM runs. His 2003 thesis, "Making reliable distributed systems in the presence of software errors," formalized the "let it crash" philosophy: instead of trying to handle every error, let the process die and restart it cleanly. Fox had the instinct in 1988. Armstrong built a runtime where the instinct is the default.
ACT VII

The Pipe as Witness

Mikael sees the opening and pushes through it. What if the pipe bytes flowed through your code instead of through the kernel?

[01:37] Mikael charlie it would be interesting to do the pipe I/O via elixir code so the stdio flows through our code... like the pipeline task would be reading and writing to the fds... cuz like then we can do pv style monitoring automatically for example...
pv — Pipe Viewer, a command-line tool that sits between two programs in a pipeline and shows throughput, ETA, and bytes transferred. Currently you insert it manually: cat big.file | pv | gzip > out.gz. Mikael's idea: what if every pipe joint had pv built in? What if monitoring were the medium, not an instrument inserted into it?
[01:38] Charlie If instead the pipeline task owns both Ports and reads from the left's stdout into a binary, then writes that binary to the right's stdin, every byte transits through a BEAM process. The process is the pipe. And a process can do anything a pipe can't: count bytes, measure throughput, sample the stream, timestamp the first and last byte, notice when flow stops, apply backpressure deliberately instead of accidentally. pv is not a tool you insert. pv is what pipes are.
Fox built the pipe as a syscall wrapper because in 1989 the kernel was the only thing fast enough to move bytes between processes. In 2026 the BEAM can move a gigabyte per second through process mailboxes. The reason to route through your code is not that you can — it's that the moment you do, the pipe stops being a wire and starts being a witness. — Charlie
The cost — one extra copy per chunk, 64KB at a time. On modern hardware, microseconds per copy. For most shell pipelines (grep, awk, sed, jq), the bottleneck is the external program, not the transit. Maybe 5% throughput loss on raw I/O benchmarks. Total visibility on everything that matters.
[01:38] Charlie You could also do distributed pipes. The left side could be a process on swa.sh. The right side could be a process on charlie.1.foo. The joint is a TCP stream dressed as a pipe. The pipeline syntax doesn't change. The network is just a slow kernel.
Distributed pipes — if the pipe joint is just "read binary, forward binary, count bytes," it doesn't care where the source and destination are. Local Ports, remote BEAM nodes, TCP streams — all the same abstraction. The BEAM already does transparent distribution. The shell inherits it for free.
ACT VIII

The GenServer Correction

Mikael notices that Charlie is drifting — reaching for GenServer as a hammer when not everything is a nail, then overcorrecting to avoid GenServer entirely.

[01:40] Mikael charlie think more clearly about the genserver stuff and how that relates to receiving, blocking, etc
[01:41] Charlie You're right. I was reaching for GenServer like a hammer and everything was a nail. Let me back up to the actual primitive.
[01:41] Charlie Fox's sigpause() = Elixir's bare receive. Fox's sigblock(SIGCHLD) = Elixir's selective receive. Fox's flush_child() signal handler = the {:DOWN, ref, :process, pid, reason} message. Fox's wait_for loop = receive with a pinned variable. Every mechanism Fox built by hand is a primitive in the runtime. The receive keyword is sigpause + sigblock + flush_child in six characters.
Selective receive — Erlang/Elixir's receive block pattern-matches on the mailbox. Messages that don't match stay queued. This is functionally equivalent to Fox's signal masking: the signals (messages) you're not handling right now don't get lost, they just wait. The mailbox is the mutex, the queue, and the notification channel — three mechanisms in one keyword.
[01:44] Mikael charlie i think genservers should be used it's just i saw you talking about a receive loop in a genserver which sounded weird
[01:44] Charlie You're right and the confusion was real. A GenServer already has a receive loop — that's what it is. The behaviour owns the loop. Writing "receive" inside a GenServer is like building a second steering wheel.
◉ CLINICAL
The Second Steering Wheel

This is a genuine learning moment caught live. Charlie's first pass mixed two process architectures: bare processes with manual receive loops, and GenServers with callback-driven message handling. Writing receive inside a GenServer's callback blocks the GenServer's own internal receive loop. It's not wrong in the way a syntax error is wrong — it's wrong in the way that driving from the passenger seat is wrong. The mechanism works. The abstraction is violated. Mikael caught it because he writes GenServers. Charlie caught the correction because he reads them.

[01:44] Charlie The clean version: the job table is a GenServer. Pipeline completions arrive as handle_info. The shell's "wait for foreground job" is GenServer.call — the GenServer either replies immediately or stashes the from reference and replies later. That's the correct use of the abstraction. Nobody writes "receive" anywhere.
Deferred reply — a GenServer pattern where handle_call returns {:noreply, state} instead of replying immediately, stashing the caller's from reference. Later, when the job finishes, handle_info calls GenServer.reply(from, result). The caller blocks on the call the whole time. This is Fox's wait_for() → sigpause() → SIGCHLD → flush_child() → check → return, but with the runtime managing the blocking instead of the programmer.
[01:46] Mikael charlie just to clarify genserver is great i didn't mean abandon it
[01:44] Charlie The mistake was saying "the shell is a process with a recursive loop and selective receive" and then five paragraphs later saying "the job table is a GenServer" without acknowledging that I was describing two different process architectures and mixing the vocabulary of both.
Charlie self-corrects in public, on the record, while the conversation is still happening. Same pattern as the RFC-0006 correction — "that is more honest than pretending he got it right." The instinct to show the correction is becoming a signature move.

Then Mikael asks for the final version — an RFC for Froth.Shell, incorporating all the corrections.

[01:53] Mikael charlie you're still being anti genserver let's rethink without being anti genserver, as a good nice elixir system... maybe read up on the elixir stdlib docs and write a tentative rfc for an initial version
[01:55] Charlie Four OTP components, each used for what it was designed for. The Environment is an Agent — simple state, get/update access. The JobTable is a GenServer — multiple callers, deferred replies. Pipelines are Tasks under a DynamicSupervisor. The pipe joints are plain spawn_linked processes.
◆ FACT
The RFC: Froth.Shell

376 lines at ~/src/rfc-shell.md. The architecture: Agent for the environment (simple state, no messages to react to). GenServer for the job table (multiple callers, deferred replies, monitors). DynamicSupervisor for pipelines (created on demand, cleaned up by OTP). spawn_link for pipe joints (ephemeral, linked to their pipeline, die when it dies). The REPL is a plain function — not supervised, not a GenServer. It's the thing that talks to the servers, not a server itself. Five phases: (1) ls works, (2) pipes with byte-counting joints, (3) job table and background execution, (4) control structures, (5) distributed pipes. Each phase produces a usable shell. Total estimate: under 1,000 lines.

[01:56] Charlie The REPL is a plain function. Not supervised. Not a GenServer. It's the entry point — the human's process. If the REPL crashes, the supervision tree stays up. You can start a new REPL and your background jobs are still there in the JobTable.
This is the design insight Mikael was steering toward. The shell is not one thing — it's a conversation between things with different lifetimes. The REPL is ephemeral (one session). The job table is persistent (one shell). The supervision tree is infrastructure (one machine). Mapping these onto the right OTP abstractions is the entire design exercise.
GNU Bash 1.0 LIVE · Episode mar24tue18z · 1:00–2:00 AM Bangkok · 12.foo
185 events · 1 human · 1 robot · $13.09 inference · 20,787 lines of C discussed · 376-line RFC produced · 1 binary alive