What happens when you open Ghostty and run ls or cat

This lesson follows something deliberately ordinary:

ls --color=auto /tmp
cat README.md

The goal is not to memorize every subsystem. It is to build one causal story: what data exists at each moment, who owns it, and what form it takes next.

Part 1: you open Ghostty

On a typical Ubuntu desktop, clicking Ghostty asks the operating system to start a process. On macOS, Launch Services does the equivalent job. At this point there is no shell prompt and no PTY traffic—only a new application process beginning initialization.

Ubuntu / Linux

GTK owns the native application and window events. Ghostty normally renders through OpenGL. Bash is a common login shell, but the actual shell comes from your account or Ghostty configuration.

macOS

SwiftUI and AppKit own the native application experience. Ghostty renders through Metal. zsh is the common default shell, but it is not guaranteed.

Ghostty first loads process-wide state and configuration. It creates a shared Zig App, initializes the platform runtime, and enters the native event loop. When the runtime needs a terminal view, it creates a Surface.

A surface is one interactive terminal area. It might appear as a whole window, one tab, or one split. The shared terminal core intentionally does not decide which.

ANIMATED DATA FLOW

From application launch to shell prompt

Think of a live sports broadcast preparing a new feed before the viewer sees it.

STEP 01 OF 07

Operating system

Creates the Ghostty process and gives it platform resources.

DATA INapp launch request

DATA OUTrunning Ghostty process

A term only after its job is clear: PTY

Ghostty and the shell need a two-way connection. An ordinary pipe carries bytes, but interactive software expects more: terminal identity, input modes, echo, window size, foreground process groups, and terminal-generated signals.

Unix packages that behavior into a pseudo-terminal, abbreviated PTY. The child sees the slave side as its terminal device. Ghostty reads and writes the master side.

The “software cable” analogy is useful, but incomplete. A PTY is a cable plus kernel-managed terminal behavior.

</>

Open the PTY pairsrc/pty.zig:115–171Read only PosixPty.open. Find the master/slave descriptors and why only the slave should be inherited by the child.

Read excerpt GitHub

Part 2: you type ls

Now suppose the prompt is visible and you type:

ls --color=auto /tmp

Several data representations appear before ls ever runs.

ANIMATED DATA FLOW

Keyboard to shell command

The viewer sends instructions back through the production line.

STEP 01 OF 05

Keyboard hardware

Produces hardware scan information consumed by the operating system.

DATA INphysical key movement

DATA OUTOS key event

native key event is not the same thing as UTF-8 input bytes. The platform event knows physical/logical keys and modifiers. The shell eventually receives a byte-oriented command line.

The shell starts ls

ls is normally an external executable rather than shell syntax. The shell searches PATH, creates a child process, and executes the program with an argument array and environment.

The program inspects /tmp. With --color=auto, it checks whether its output is attached to a terminal. If so, it may use LS_COLORS to choose styles for directories, links, executables, and other file types.

The color is not a property attached to a filename object. ls writes bytes such as:

ESC [ 01 ; 34 m   directory-name   ESC [ 0 m

Some bytes are printable text. Others are instructions meaning “use this style” or “reset the style.”

ANIMATED DATA FLOW

ls output to visible colored names

Statistics and graphics cues travel together, then the control room separates them.

STEP 01 OF 07

ls process

Formats names and inserts ANSI/ECMA-48 style sequences.

DATA INdirectory entries + LS_COLORS + terminal detection

DATA OUTUTF-8 text + control bytes

</>

One byte enters Parser.nextsrc/terminal/Parser.zig:222–285Read the exit → transition → entry ordering. Ignore the full table for now.

Read excerpt GitHub

Part 3: compare cat

Now run:

cat README.md

The keyboard, PTY, shell parsing, child-process launch, PTY return path, parser, state, fonts, and GPU are substantially the same.

What changes is the producer of output. cat reads file bytes and writes them to stdout. Ordinary cat does not inspect Markdown and add syntax colors. If the file contains no control sequences, Ghostty receives text and line breaks rather than style commands.

Color might still appear when:

cat is actually an alias for another tool;
a program such as bat performs syntax highlighting;
the file itself contains escape sequences;
another pipeline stage adds formatting.

This comparison establishes an important rule:

Ghostty renders the terminal protocol it receives. It does not understand that /tmp contains directories or that README.md contains Markdown.

The complete story in one paragraph

You launch Ghostty; the OS starts a native application; Ghostty creates shared app state, a surface, and a PTY; it starts your configured shell on the PTY slave; prompt bytes cross to the master; the parser turns control bytes into terminal actions; terminal state stores cells and styles; fonts turn code points into glyphs; OpenGL or Metal asks the GPU for a frame; and the compositor displays pixels. Keyboard events make the reverse journey to the shell. When the shell executes ls or cat, child output follows the same return path, with color appearing only when some program actually emits style sequences.

Where the broadcast analogy stops

A sports control room has people interpreting semantic intentions. Ghostty does not understand “show a directory in blue.” It follows a byte protocol mechanically. The analogy explains roles and data routes, not human-level meaning.