ogham/exa
A modern replacement for ‘ls’.
Modern replacement for 'ls' command with colors, Git status, and enhanced file listing
Command-line arguments flow through options parsing, then filesystem scanning collects file metadata, which gets filtered/sorted before being rendered in the chosen output format
Under the hood, the system uses 3 data pools, 4 control points to manage its runtime behavior.
Structural Verdict
A 10-component cli tool with 14 connections. 55 files analyzed. Highly interconnected — components depend on each other heavily.
How Data Flows Through the System
Command-line arguments flow through options parsing, then filesystem scanning collects file metadata, which gets filtered/sorted before being rendered in the chosen output format
- Argument Parsing — Command-line arguments are parsed into Options struct containing all user preferences
- Path Resolution — Input paths are resolved and default to current directory if none provided
- Git Detection — Git repositories are detected for the input paths to enable Git status features
- Directory Scanning — Directories are read and File objects are created with cached metadata
- Filtering — Files are filtered based on visibility rules and ignore patterns
- Sorting — Filtered files are sorted according to the specified sort field and direction
- Rendering — Sorted files are rendered using the chosen view mode (grid, details, tree)
- Output — Formatted output is written to stdout with appropriate colors and styling
System Behavior
How the system actually operates at runtime — where data accumulates, what loops, what waits, and what controls what.
Data Pools
Cached Git repository information and file statuses to avoid repeated Git operations
Cached directory file listings to avoid repeated filesystem scans
Cached file metadata including permissions, timestamps, and extended attributes
Delays & Async Processing
- Filesystem I/O (async-processing, ~variable) — Directory reading blocks until all entries are scanned
- Git Status Lookup (async-processing, ~variable) — Git repository scanning can cause delays for large repositories
- Extended Attributes (async-processing, ~variable) — Extended attribute reading adds per-file latency on supporting systems
Control Points
- EXA_DEBUG (env-var) — Controls: Debug logging verbosity level
- EXA_ICON_SPACING (env-var) — Controls: Icon spacing in file listings
- git feature flag (feature-flag) — Controls: Compilation of Git integration features. Default: enabled by default
- SIGPIPE handling (runtime-toggle) — Controls: Unix signal handling for broken pipes. Default: SIG_DFL
Technology Stack
Terminal color and styling support
Git repository integration and status checking
Unix user and group name resolution
Date and time formatting
Pattern matching for file filtering
System call interface for Unix operations
Terminal grid layout rendering
Terminal dimension detection
Parallel processing for large directories
Key Components
- Options (module) — Parses command-line arguments into structured configuration options
src/options/mod.rs - File (class) — Represents a single file with cached metadata and provides access to file properties
src/fs/file.rs - Dir (class) — Caches directory contents and provides file listing functionality
src/fs/dir.rs - GitCache (class) — Manages Git repository detection and status information for files
src/fs/feature/git.rs - FileFilter (class) — Filters and sorts file lists based on user preferences
src/fs/filter.rs - DirAction (type-def) — Defines how directories should be handled (list contents, treat as file, or recurse)
src/fs/dir_action.rs - FileExtensions (class) — Detects file types based on extensions and provides color/icon information
src/info/filetype.rs - View (type-def) — Determines output format (grid, details, tree) and rendering options
src/output/mod.rs - Theme (class) — Manages color schemes and styling for different file types and UI elements
src/theme/mod.rs - logger (module) — Configures debug logging based on environment variables
src/logger.rs
Explore the interactive analysis
See the full architecture map, data flow, and code patterns visualization.
Analyze on CodeSeaRelated Cli Tool Repositories
Frequently Asked Questions
What is exa used for?
Modern replacement for 'ls' command with colors, Git status, and enhanced file listing ogham/exa is a 10-component cli tool written in Rust. Highly interconnected — components depend on each other heavily. The codebase contains 55 files.
How is exa architected?
exa is organized into 5 architecture layers: CLI Interface, Filesystem Layer, Information Layer, Output Layer, and 1 more. Highly interconnected — components depend on each other heavily. This layered structure enables tight integration between components.
How does data flow through exa?
Data moves through 8 stages: Argument Parsing → Path Resolution → Git Detection → Directory Scanning → Filtering → .... Command-line arguments flow through options parsing, then filesystem scanning collects file metadata, which gets filtered/sorted before being rendered in the chosen output format This pipeline design reflects a complex multi-stage processing system.
What technologies does exa use?
The core stack includes ansi_term (Terminal color and styling support), git2 (Git repository integration and status checking), users (Unix user and group name resolution), datetime (Date and time formatting), glob (Pattern matching for file filtering), libc (System call interface for Unix operations), and 3 more. This broad technology surface reflects a mature project with many integration points.
What system dynamics does exa have?
exa exhibits 3 data pools (GitCache.repos, Dir.contents), 4 control points, 3 delays. These runtime behaviors shape how the system responds to load, failures, and configuration changes.
What design patterns does exa use?
4 design patterns detected: Feature Gates, Caching Strategy, Deduction Pattern, Cross-Platform Abstraction.
Analyzed on March 31, 2026 by CodeSea. Written by Karolina Sarna.