tmux is a production-grade terminal multiplexer written in C with a client-server architecture. The server process manages sessions, windows, and panes (each backed by a PTY), while client processes connect over a Unix socket and communicate via a versioned imsg-based protocol (PROTOCOL_VERSION 8). The codebase is organized into command dispatch (cmd_entry structs), a grid-based screen buffer with history and reflow, a scene-cached redraw engine, a terminal I/O layer (tty.c) with terminfo parsing and feature negotiation, and an extensive options/hooks/events system. Entry points are tmux.c (main), server.c (event loop), and the control protocol for programmatic clients. Externally it depends on libevent, terminfo, and POSIX/BSD PTY APIs, with a compat/ layer shimming missing functions across a dozen platforms.
node-pty is a Node.js native addon that provides cross-platform pseudoterminal (PTY) fork functionality. It allows spawning processes with PTY file descriptors, enabling terminal emulators like VS Code, Hyper, and xterm.js to interact with shell processes. The architecture consists of a TypeScript abstraction layer (`Terminal` base class, `UnixTerminal`, `WindowsTerminal`) that handles platform differences and wraps platform-specific C++ native modules. On Unix (Linux/macOS), it uses `forkpty(3)` and `posix_spawn`; on Windows, it leverages the ConPTY API via named pipes and worker threads to avoid deadlocks. Key entry points are the `spawn()` and `open()` functions exported from `src/index.ts`, which delegate to the appropriate platform implementation. Data flows through a pair of sockets: an input socket for writing to the PTY and an output socket for reading, with careful handling of backpressure and async I/O on each platform. The module addresses advanced challenges such as FD leakage prevention, signal handling across processes, and non-blocking I/O with custom write streams. It is a mature, well-tested library used by major terminal applications.
This repository is an OpenCode plugin that provides interactive pseudo-terminal (PTY) management for AI coding agents. It allows agents to spawn, write to, read from, and kill multiple background terminal sessions, enabling long-running processes like dev servers, watch modes, and interactive programs. The plugin exposes five tools (pty_spawn, pty_write, pty_read, pty_list, pty_kill) and two slash commands for opening a web UI. The architecture is modular: a core PTYManager orchestrates session lifecycle, output buffering (via a RingBuffer), and exit notifications, while adapters decouple the plugin from OpenCode V1 and V2 APIs. A Bun-based web server serves a React frontend with real-time WebSocket streaming and a REST API for session management. The codebase demonstrates strong TypeScript patterns, clean abstractions, and comprehensive testing (unit, integration, and Playwright E2E).
This is a Go library for console and terminal handling, part of the containerd project. It provides a cross-platform `Console` interface with methods for setting raw mode, resizing, disabling echo, and querying window size. The library supports Linux, macOS, FreeBSD, NetBSD, OpenBSD, Windows, and z/OS via build tags. On Linux, it includes an `Epoller` that uses edge-triggered epoll for efficient non-blocking I/O, handling EAGAIN/EIO errors gracefully. It can create PTY pairs (`NewPty`) and obtain the current process console (`Current`). The only external dependency is `golang.org/x/sys`. The code is idiomatic, well-tested, and follows Go best practices, though the dependency version and CI Go version are outdated.
emacs-libvterm is a terminal emulator package for GNU Emacs, implemented as a hybrid of a C dynamic module and an Emacs Lisp package. The C module (vterm-module.c, elisp.c, utf8.c) wraps libvterm and exposes a small API (vterm--new, vterm--update, vterm--redraw, vterm--write-input, vterm--set-size, etc.) to Elisp. The Elisp side (vterm.el) provides the user-facing commands (vterm, vterm-other-window), manages the pty-backed shell process, defines keybindings, and implements copy mode, directory/prompt tracking, TRAMP support, and bookmarks. The module renders terminal cells into the Emacs buffer as text with font-lock face properties, batching runs of cells with identical attributes for performance. Data flows are bidirectional: keystrokes go from Emacs keybindings through vterm--update into the C term_process_key handler, which translates them into libvterm keyboard events and flushes resulting output bytes back to the pty. Shell output arrives via the process filter vterm--filter, which handles partial multibyte characters split across chunks, feeds bytes into libvterm, and triggers damage-based invalidation. The redraw pipeline (term_redraw, refresh_scrollback, refresh_screen, refresh_lines) maintains a scrollback ring buffer with per-line metadata (working directory, prompt column) that survives window resizes and reflow. OSC 51 escape sequences from the shell drive directory tracking, prompt detection, and whitelisted Elisp evaluation via vterm-eval-cmds. Notable engineering: the scrollback ring buffer with per-line metadata and resize handling, the batched cell rendering with text-property coalescing, and the clean separation between the Emacs API bridge (elisp.c) and terminal logic. The codebase carries compatibility shims for old libvterm versions (VTermStringFragment, VTermSelectionMask, sb_clear, reflow) and a dead Travis CI config targeting Emacs 25.3/26.1, indicating medium technical drift despite active maintenance. The term_process_key function is a monolithic if-else chain, and the CMake feature detection uses grep on headers, but overall the code is well-structured and battle-tested.
SteamDepotDownloaderGUI is a Tauri v2 desktop application that provides a graphical interface for DepotDownloader, a CLI tool for downloading specific versions (manifests) of Steam games. The app allows users to input Steam credentials (or download anonymously), app/depot/manifest IDs, and an output directory. The Rust backend downloads the DepotDownloader binary from GitHub, extracts it, and spawns it as a child process via a pseudo-terminal (PTY), streaming output to an xterm.js terminal component in the Preact frontend. The frontend also includes a clipboard parser that extracts identifiers from SteamDB's copy format, auto-filling the form. The architecture is a standard monolithic desktop app with clear separation between Rust backend (Tauri commands) and Preact frontend, communicating via Tauri's invoke system. Settings for output directory naming and mobile authentication are managed through a context. The code is well-organized, with reusable input components and a clean PTY abstraction, though testing is minimal beyond a single URL validation test.
Upterm is a terminal emulator for the 21st century, built as an Electron desktop application with TypeScript and React. It provides an IDE-like terminal experience with features such as autocompletion (for git, npm, brew, and many other commands), output prettyfiers (JSON tree, git grep, image display), multiple tabs and split sessions, a custom shell parser, and a plugin system. The application uses node-pty for pseudo-terminal management and Monaco Editor for the prompt input. It also includes a full VT100/xterm-compatible terminal emulator (Output.ts) that handles ANSI escape sequences, scrolling, cursor movements, and SGR attributes. Architecturally, Upterm follows a modular pattern with services (FontService, HistoryService, GitService, etc.) that communicate via RxJS observables, a plugin manager that registers autocompletion providers and prettyfiers, and a shell layer that parses commands and manages jobs. The codebase is well-structured and demonstrates non-obvious craftsmanship in areas like the history trie for fuzzy matching, man page parsing for flag extraction, and the terminal buffer implementation. However, the project is explicitly deprecated and unmaintained. The README states it is no longer accepting pull requests or issues. The codebase relies on outdated dependencies (Node 8.11.0, Electron 2.0.10, React 16.2.0) and has several incomplete features and security concerns (e.g., execFile with user-controlled input). Despite its quality, the technical drift is high, and the repository should be considered a reference or learning resource rather than a production-ready tool.