eza Continued exa's Modern ls Experiment
After exa became unmaintained, the community fork eza carried its Rust-based, Git-aware directory listing interface forward under active, ongoing stewardship.
The Rust-based exa utility offered a modern alternative to ls, with color, tree views, Git status, metadata columns, and human-friendly formatting. When the original project stopped receiving maintenance, contributors established eza as a community fork so the idea could continue without depending on an absent maintainer.
A fork preserves code, but governance keeps it alive
Creating a fork is technically easy; maintaining releases, reviewing security reports, managing packaging, and deciding compatibility policy are the real work. The eza project documents its lineage directly and uses a new name, repository, package identity, and release stream rather than implying that the original exa repository resumed activity.
For users, migration is usually straightforward because eza deliberately retains a familiar command-line interface. It is still important to inspect scripts and aliases: a drop-in-looking command can change defaults or add behavior over time, and ls output should not be parsed as a stable machine protocol in the first place.
Why not silently replace ls everywhere
Interactive aliases such as alias ls='eza' are personal preferences. System scripts should call the exact tool and options they require. POSIX ls, GNU ls, BSD ls, exa, and eza do not promise identical flags or output, and remote recovery environments may have only the base system implementation.
The safest adoption path is to install eza, try explicit invocations, then add narrowly scoped interactive aliases after verifying color, icons, pager behavior, and terminal-font assumptions. Keep scripts independent of decorative output.
A broader open-source lesson
The transition illustrates a healthy use of permissive licensing: users were not trapped when stewardship ended. But it also shows that continuity is a social achievement. The active project exists because maintainers took responsibility for releases and community processes, not merely because the source remained downloadable.
Part of a broader pattern, not an isolated case
exa-to-eza is one specific instance of a wider trend of ls-adjacent and other classic Unix utilities gaining actively-developed Rust-based reimplementations over the past several years — ripgrep alongside grep, fd alongside find, and bat alongside cat all follow a similar shape: a modern rewrite adding color, smarter defaults, and better ergonomics on top of the same fundamental task the original tool performed. eza’s own continuation of that pattern after exa’s stall is a reminder that this entire category of tooling depends on ongoing, voluntary maintenance in exactly the same way traditional Unix utilities historically have — a fast, well-received initial release doesn’t guarantee long-term stewardship on its own.
What actually changed for users making the jump
eza carried forward exa’s core feature set — colorized output keyed to file type, a tree view (eza --tree), inline Git status columns showing modified/staged/untracked state per file, and extended file metadata display — while continuing active development on top of that base rather than freezing it at exa’s last state. Users migrating typically notice little day-to-day difference in the base command’s behavior, which is precisely the point: the fork’s job was preserving continuity of a tool people already relied on, not introducing a jarring reinvention just to justify the new name.
Confirming which one you actually have installed
Because exa and eza are separate binaries with separate package names, a system can technically have either, both, or neither installed depending on which package repository or installation method was used historically — which eza, which exa, and checking each binary’s own --version output confirms exactly what’s actually present before assuming a script or alias referencing one name will resolve to the tool you expect.
Related: How to Evaluate a Modern Shell Without Breaking Your Workflow · Command Substitution vs Process Substitution
Sources: