# eza: a Rust replacement for ls that adds Git status, icons and themes

> eza is a single-binary file lister written in Rust that keeps ls syntax while adding Git status, icons, hyperlinks and a theme.yml file. Here is how it installs, what its options actually change, and where it stops being the right tool.

**eza-community/eza** — A modern alternative to ls

- Repository: https://github.com/eza-community/eza
- Website: https://eza.rocks
- Stars: 23,415 · Forks: 533
- Language: Rust
- License: EUPL-1.2
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/eza-community-eza

## What eza solves for people who read directory listings all day

The README opens with a plain claim: eza is a modern alternative for the venerable file-listing command-line program ls that ships with Unix and Linux operating systems, giving it more features and better defaults. That sentence names both the target and the audience. If you type ls dozens of times a day and then type a second command to see whether a directory is a Git repository, eza is aimed at you. It folds metadata that ls leaves out into the listing itself: symlink targets, extended attributes, security context, mount points, and Git status for tracked or ignored files.

The project also positions itself against exa rather than only against ls. The README keeps a list of features not in exa, including hyperlink support, mount point details, Selinux context output, Git repo status output, human readable relative dates, support for bright terminal colours, and a theme.yml configuration file for colours and icons. That list matters because exa was the earlier Rust rewrite of ls, and some users arriving at eza are migrating from it rather than from coreutils. The README also states that eza fixes the Grid Bug introduced in exa in 2021, which is a concrete, checkable difference rather than a general claim of quality.

The audience is narrower than "everyone who uses a shell". eza is a human-facing tool. Nothing in the README describes a stable machine-readable output mode, and the option list is organised around display, filtering and long-view presentation. If your consumer is a script, ls already solved that problem years ago.

## How eza is built and what the binary actually contains

eza is a Rust project. Cargo.toml declares edition 2024, a minimum rust-version of 1.90, and a single [[bin]] target named eza. The README calls it small, fast, and just one single binary, and the packaging metadata backs that up: the Debian asset list installs target/release/eza to /usr/bin/eza plus three man pages and shell completions for bash, zsh and fish. There is no daemon, no config server and no runtime dependency beyond the platform.

Dependencies visible in Cargo.toml include rayon for parallelism and chrono for timestamps. That is consistent with a tool that walks directories and formats rows: the work is embarrassingly parallel per entry, and the date handling exists to support the --time, --accessed, --created and --changed fields. The repository also carries benches/ and a powertest.yaml, so performance work is part of the project's own tooling, though the README does not publish benchmark numbers.

Themes and icons are separate from the binary's defaults. The README lists a Configuration theme.yml file for customization of colors and icons, and the Debian package ships eza_colors.5 and eza_colors-explanation.5 man pages alongside the main eza.1 page. So the colour and icon system is documented as a first-class surface, not an afterthought bolted onto ANSI escapes. The repository also contains a .config/ directory at the top level, which is where the project keeps its own configuration for development.

Build tooling is a justfile. Targets include build (cargo build), build-release (cargo build --release --verbose), test (cargo test --workspace -- --quiet), clippy, and check-features, which requires cargo-hack. That tells you the project tests across feature combinations, and that contributing means having a Rust toolchain plus a few cargo subcommands installed.

## Installing eza and running a first real listing

The README states that eza is available for Windows, macOS and Linux, and points to INSTALL.md for platform and distribution specific instructions. It does not inline those instructions, so the honest first step is to open that file for your distribution. What the README does give directly is a Nix path for anyone with flake support enabled.

```bash
nix run github:eza-community/eza
```

Nix builds eza and runs it, according to the README. You should see a directory listing of your current working directory in eza's default grid layout. To pass arguments through the nix run invocation, the README shows this form, which lists in long format with one entry per line:

```bash
nix run github:eza-community/eza -- -ol
```

The double dash separates nix's own arguments from eza's. If you forget it, the flags go to nix instead of the binary. For non-Nix users, the packaging status badge in the README links to a Repology page covering many distributions, and the repository ships a snap/ directory and a deb.asc signing key, so Debian-family and Snap builds exist upstream.

Once eza is on your PATH, the options that change the most for a first-time user are the long view and the Git column. The README documents -l / --long for extended details and attributes, and --git to list each file's Git status, if tracked or ignored. Combining them gives you a listing where modified and untracked files are visible without running git status in a second terminal.

```bash
eza -l --git --group-directories-first
```

You should see the long view with a Git status column and directories grouped above files. Two related flags are worth knowing because they trade detail for speed: --git-repos lists each directory's Git status if tracked, and --git-repos-no-status lists whether a directory is a Git repository but not its status, which the README explicitly marks as faster. If you are listing a large tree, that distinction is the difference between a usable command and a slow one.

Icons and hyperlinks are opt-in with a three-state argument. The README documents --icons=(when) and --hyperlink=(when), where when is always, auto or never. Icons require a Nerd Font in your terminal; the repository's topics list nerd-fonts, and the README does not promise that a default font will render them.

## Where eza is the wrong tool

The README is unusually direct about the compatibility gap: eza's options are almost, but not quite, entirely unlike ls's. That warning is the main limitation. Any alias, script, Makefile or CI step that parses ls output, or that assumes a specific flag behaves identically, is a migration risk. The README does not document a compatibility mode, and it does not document rollback to ls semantics. The safest reading is that eza is a replacement for interactive use, not for programmatic use.

There is a second boundary in the long view options. Mount details via -M / --mounts are marked Linux and MacOS only, so on Windows that column is not available. Security context output via -Z / --context is a Unix concept; do not expect it to mean anything on a filesystem that has no SELinux labels.

Git integration has a cost the README acknowledges indirectly. --git-repos-no-status exists precisely because computing full status per directory is slower, and the README describes the no-status variant as faster. On a deep tree with many repositories, the full --git flag is the expensive one. If you are listing a monorepo or a home directory with dozens of checkouts, expect to choose between detail and latency.

Finally, eza is not a file manager and not a find replacement. The filtering options cover hidden files, globs, .gitignore, directory-only and file-only views, and recursion depth, but there is no search-by-content, no interactive selection, and no action on the results. If you need to act on files rather than look at them, eza is the wrong layer.

## eza versus exa, and versus plain ls

The closest alternative is exa, the earlier Rust ls replacement. The difference is not stylistic. The README maintains an explicit list of features present in eza and not in exa: hyperlink support, mount point details, Selinux context output, Git repo status output, human readable relative dates, bright terminal colour support, and the theme.yml configuration file. The README also states that eza fixes the Grid Bug introduced in exa in 2021, and lists several security fixes among the differences. If you are already an exa user, that list is the migration checklist: check whether the specific feature you depend on is on it.

Against plain ls, the difference is defaults and metadata. ls is guaranteed to be present, has a stable and widely understood flag set, and is what every script in your environment already targets. eza is a separate binary you install and update, and its flags deliberately diverge. The README frames this as a feature: by deliberately making some decisions differently, eza attempts to be a more featureful, more user-friendly version of ls. The trade is that you now own the install, the theme file and the upgrade path on every machine where you rely on it.

A third option is simply not to replace ls at all and to use git status, stat and find alongside it. That keeps your muscle memory and your scripts intact, at the cost of typing more commands to get the combined view eza produces in one.

## Maintenance, licence and upgrade cost

The repository is not archived. The last push was on 2026-08-06, and the most recent release listed is v0.23.5 from 2026-07-09, following v0.23.4 in 2025-10-03 and v0.23.3 in 2025-09-14. The gap between v0.23.3 and v0.23.4 is roughly a year, while v0.23.5 arrived about nine months later. That is a release cadence with long quiet stretches, so pinning a version and reading CHANGELOG.md before upgrading is more useful here than tracking a rolling package.

The licence is EUPL-1.2, stated in Cargo.toml and in the README's SPDX header. The repository also carries a LICENSES/ directory and a REUSE.toml, which indicates REUSE-compliant per-file licence metadata. EUPL-1.2 is a copyleft licence with a compatibility list; if you redistribute eza inside a product, or modify and ship it, the obligations are not the same as MIT or Apache-2.0. That is a question for your own legal review, not something this article can settle.

Upgrade cost is mostly configuration drift. Because colours and icons live in theme.yml, and because colour handling is documented across eza_colors.5 and eza_colors-explanation.5, a theme written against one release may need attention after a change to the colour system. The project's own build tooling reflects the same care: the justfile has a check-features target that runs cargo hack check to verify every combination of feature flags compiles, which is the kind of target you add when feature combinations have broken before. Building from source needs Rust 1.90 or newer per Cargo.toml.

## Conclusion

Adopt eza if you live in a terminal, want Git status and icons in the same view as your file listing, and can accept that its flags are close to ls but not identical. Do not adopt it as a drop-in replacement inside scripts and aliases that parse ls output, because the README itself warns the options are almost, but not quite, entirely unlike ls. Before rolling it out, check your platform's entry in INSTALL.md, run the nix run one-liner or a package install to see the output on your own terminal, and confirm the version your package manager ships against the v0.23.5 release. Verify the licence file (EUPL-1.2) against your distribution policy before bundling the binary.

## FAQ

### What does eza mean?

The README does not give an expansion or etymology for the name. It only presents eza as a modern replacement for ls, and the repository is organised under the eza-community organisation.

### Is eza better than ls?

It depends on whether you need a human-facing listing. eza adds colours, Git status, symlink and extended attribute awareness, mount details and a theme.yml file, while ls remains the flag set your scripts already target. The README notes that eza's options are almost, but not quite, entirely unlike ls's, so the extra features come with a compatibility gap.

### What is eza in terminal?

eza is a file-listing command-line program that ships as a single binary and replaces the ls command for interactive use. The README describes it as using colours to distinguish file types and metadata, and as knowing about symlinks, extended attributes and Git.

### What are the differences between exa and eza?

The README lists features present in eza and not in exa, including hyperlink support, mount point details, Selinux context output, Git repo status output, human readable relative dates, bright terminal colour support, and the theme.yml configuration file. It also states that eza fixes the Grid Bug introduced in exa in 2021 and includes several security fixes.

## Sources

- [eza-community/eza on GitHub](https://github.com/eza-community/eza)
- [License: EUPL-1.2](https://github.com/eza-community/eza/blob/main/LICENSE)
- [Project website](https://eza.rocks)
- [README](https://github.com/eza-community/eza/blob/main/README.md)
- [Releases](https://github.com/eza-community/eza/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eza-community-eza