eza Continued exa's Modern ls Experiment

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 that source availability and active stewardship are different things. A fork can continue code under the applicable license, but users still need to evaluate the new project’s governance, release process, packaging, and maintenance activity. The eza project has its own repository, documentation, license, and release history.

Part of a broader pattern, not an isolated case

The eza repository describes itself as a modern alternative to ls, built on exa, and documents features including color, Git status, tree views, and extra metadata. Those are project claims about the tool’s interface, not a promise that output matches every system’s ls implementation.

What actually changed for users making the jump

The fork kept the same general task while adding its own features and fixes. Its release notes are the place to verify a capability for a specific release; the repository README is useful for the current feature overview. The fact that eza is descended from exa does not establish that every exa flag, theme, alias, or output detail is unchanged.

Confirming which one you actually have installed

Because exa and eza are separate executable names, a host may have either, both, or neither installed. Prefer command -v to identify what the current shell resolves, then query each executable directly:

command -v eza || true
command -v exa || true
eza --version
eza --help

The result depends on PATH, aliases, and shell functions. If command -v reports a function or alias rather than a path, inspect that definition before diagnosing the package installation.

Check a migration instead of assuming drop-in compatibility

Interactive users can compare representative views, but scripts need stricter treatment. Directory listings are presentation, not a stable machine-readable protocol. Color, icons, terminal width, locale, sort order, Git metadata, and platform-specific file attributes can all affect what a person sees. Never parse the default grid or long listing in automation when the tool exposes a structured format or the operating system offers a dedicated metadata interface.

Start with an explicit eza invocation instead of replacing ls globally:

eza --oneline --reverse --sort=size
eza --long --header --inode --git
eza --long --tree --level=3

These are documented examples in the eza manual. Confirm that each option exists in the installed version with eza –help, especially on older package repositories. Terminal icons may require a compatible font; color and hyperlink behavior depend on terminal support and configuration. A plain mode can be preferable in logs, CI, and remote recovery shells.

If an interactive alias is desired, keep it in a user configuration file and make it easy to bypass. System scripts should name the executable and options they require. A global alias can change how a human types ls but does not reliably change scripts, which may run in noninteractive shells that load different configuration.

What the project state says as of this update

The eza release page lists v0.23.5, published July 9, 2026, and the project organization continues to describe eza as a maintained replacement for ls. This is evidence of a project release and repository activity at the time checked; it is not a service-level maintenance guarantee or a promise about future release dates. Pin or record package versions when reproducibility matters.

The original exa maintainer’s 2023 issue explicitly says exa is unmaintained and directs users to eza. The issue also explains the social context: the maintainer said solo maintenance had not been sustainable and that eza offered a place to continue contributing. This is more informative than attributing the fork to a sudden technical failure or assuming that forking automatically solves governance.

Operational adoption checklist

Before changing developer images, compare the package source, version, license, binary path, completion scripts, and man page. Test hidden files, symlinks, unreadable directories, filenames with spaces or control characters, very narrow terminal widths, and output redirected to a file. Check Git status display in a clean and dirty working tree. Confirm that scripts do not depend on icons or parsing output that changes with color settings.

For a fleet, roll out to a small group first and make rollback a package or configuration change, not a manual replacement of system ls. Keep the operating system’s base utilities available for emergency environments, containers, and minimal systems. The project’s lineage explains why eza exists; the installed release’s manual and test results determine whether it fits a particular workflow.

Compatibility is a command-line contract, not a family tree

Being built from exa means the fork began with shared code and a related purpose. It does not mean eza is a formally compatible replacement for every version of exa, or that it implements every option accepted by GNU, BSD, BusyBox, or toybox ls. The eza manual documents its own command-line grammar; use that grammar as the supported interface.

This distinction matters for shell aliases and deployment scripts. A developer may choose eza for an interactive directory view, while a script should use an option documented by the exact installed binary. In containers and recovery shells, eza may not be installed at all. Scripts that call it without checking availability can fail in environments where base ls is guaranteed but optional tools are not.

Avoid relying on column positions or color codes in captured output. If the goal is to find files by size, use a file traversal utility or a language API that returns metadata, rather than splitting a formatted listing. If the goal is a human audit, eza’s long or tree views can be convenient; keep color, icons, hyperlinks, and Git annotations as presentation layers, not as data fields consumed by automation.

Package and configuration migration

The project installation guide lists multiple distribution methods, including package managers and downloadable release artifacts. Different methods can lag at different versions, so a host’s package name alone does not prove which release is installed. Record the resolved executable path and version in a support report, and use the package manager’s own inventory command when diagnosing a managed workstation.

If a team wants to expose eza under an ls-like alias, prefer a shell-level interactive alias rather than overwriting the operating system’s ls binary. Preserve an escape hatch that invokes the real base utility by absolute path where that is appropriate for the platform. Avoid adding an exa-named compatibility symlink unless all scripts and packages that might resolve exa have been checked; a name alone cannot guarantee identical parsing or output.

Review startup behavior too. An alias may be defined only in an interactive shell, while editor tasks, scheduled jobs, and remote automation often use noninteractive shells. Test both. If a user’s interactive alias changes sort order or includes icons by default, make sure documentation tells collaborators how to obtain a plain, reproducible listing.

Maintenance signals are evidence, not a guarantee

The 2023 exa issue and the eza release history are complementary evidence. The issue records the decision to direct users from an unmaintained upstream repository to its active fork. The release page records concrete shipped versions and changes, while repository activity shows whether the project has continued to receive work. None of these promises a particular response time, security-support window, or release cadence.

For organizations, adopt eza the same way as any third-party command-line dependency: identify its source, license, update channel, architecture support, and responsible owner. Pin versions in reproducible build environments, verify checksums or signatures when available through the official release process, and subscribe to release notes. A utility used only by individual developers may need a lighter process than one installed in privileged automation, but both should have a clear rollback plan.

Related:

Sources: