简体中文
EnglishWebsite review
This review may include AI-generated content and is not individually verified. Domain, certificate and other facts come from the observed data on this page.
What is eza?
eza is a command-line file listing tool: a modern, maintained replacement for the classic Unix/Linux ls command, written in Rust. It keeps the familiar job of showing directory contents but changes the defaults and adds features. Its own description highlights colour to distinguish file types and metadata, awareness of symlinks, extended attributes and Git, and distribution as a small, fast, single binary. It is positioned as a more featureful, user-friendly ls, with deliberate differences in behaviour rather than a drop-in clone.
What it does differently
- Colour and metadata by default: file types and details are visually separated, so a directory listing is easier to scan quickly.
- Git awareness: it can show Git repository status in the listing, useful when you want to see which files are modified without running a separate command.
- Symlinks and extended attributes: it understands these rather than treating them as plain entries.
- Hyperlinks, mount point details and SELinux context output: these are listed among features not present in exa, the project eza grew out of.
- Human-readable relative dates: timestamps can be shown in a more natural form.
- Bright terminal colours and security fixes: practical improvements for daily terminal use.
Who it is for
It suits developers, system administrators and command-line users who spend time in a terminal and want more information at a glance than plain ls gives. It is especially relevant if you already use exa, since eza is presented as its maintained successor and lists several fixes and additions over it. If you only occasionally list files and prefer the absolute minimum, the extra output may be unnecessary.
How to try or install it
The project supports Windows, macOS, Linux and BSDs. If you use Nix with flakes, the quickest trial is nix run github:eza-community/eza. Otherwise, installation routes include Cargo (cargo install eza), the Arch [extra] repository, a Debian/Ubuntu repository, Nixpkgs and Gentoo. The exact commands are on the project page.
A practical next step: run eza in a Git repository you work in daily, and compare its output with your usual ls -la. If the Git status, colours and relative dates save you a second command or a mental check, it is worth adopting; if you find the extra detail noisy, plain ls remains a fine default. For users of the older tool, GitHub hosts the exa project, while eza's own installation and feature notes are at eza.
How do I install eza on my operating system?
Install eza the same way you install other command-line tools on your platform: pick the package manager or language toolchain you already use, then verify the binary runs. The project lists Windows, macOS, Linux, and BSD support, with multiple installation paths.
Choose your route
| Platform / setup | Installation route |
|---|---|
| Arch Linux | pacman -S eza from the [extra] repository |
| Debian / Ubuntu | Add the project's APT repository and key, then sudo apt install -y eza |
| Nix / NixOS | nix profile install nixpkgs#eza, or nix-env -i eza |
| Gentoo | Available through the distro's package system |
| Any OS with Rust | cargo install eza |
| Trying it without installing | nix run github:eza-community/eza (requires Nix with flakes) |
If you already have Rust, cargo install eza is the most portable option and works across Windows, macOS, Linux, and BSD. It places the binary under your Cargo bin directory, so make sure that directory is on your PATH.
A practical next step
After installing, confirm the binary is reachable and then alias it over your usual listing command if you want it as a daily driver:
eza --version
alias ls='eza'
alias ll='eza -l'
If you prefer not to replace ls, run eza directly or alias it to a short name like e. The project notes it is a single binary, so uninstalling is usually just removing that file or the package.
Decisions to weigh
- Package manager vs. Cargo: distro packages are easier to update with your system; Cargo gives you a consistent version across machines but needs a Rust toolchain.
- Nix users: the flake route is convenient for a one-off trial before committing to an install.
- Debian/Ubuntu users: the APT route involves adding a third-party key and source list, so treat it like any external repository and keep the signing key in place.
If you are migrating from exa, the project's comparison highlights fixes and additions such as hyperlink support, mount point details, SELinux context output, Git repository status, and human-readable relative dates. Those differences are the main reason to switch rather than just reinstall.
How does eza differ from exa?
eza is a community-maintained fork of exa, and the project frames itself as a drop-in replacement: same idea, same familiar flags, but with ongoing maintenance and a set of fixes and additions that exa never received. If you already use exa, the practical difference is less about a new paradigm and more about a tool that is still being kept up to date.
What eza says it adds over exa
The site lists these as features not present in exa (its own non-exhaustive list):
- A fix for "The Grid Bug" introduced in exa in 2021 — the grid layout was a visible annoyance for exa users, so this is the most immediately noticeable change.
- Hyperlink support, so file names can be rendered as clickable terminal links.
- Mount point details in the listing output.
- SELinux context output.
- Git repository status output.
- Human-readable relative dates.
- Several security fixes.
- Support for bright terminal colours.
- Many smaller bug fixes and changes.
How to think about the trade-off
| eza | exa | |
|---|---|---|
| Maintenance | Actively maintained by a community | Effectively stalled |
| Grid layout | Bug fixed | Bug present since 2021 |
| Extras | Hyperlinks, mount points, SELinux context, Git status, relative dates | Not included |
| Compatibility | Aims to be a drop-in replacement | Original |
If you are choosing for a new machine, eza is the safer default simply because it is the version receiving fixes. If you have exa configured with aliases and scripts, eza is intended to slot in without rewriting them, though you should still check anything that parses exa's output, since added columns or metadata can shift formatting.
A concrete next step: on a machine where exa is already installed, install eza alongside it and compare the same directory with both, for example a Git repository with symlinks and mounted volumes. That single side-by-side run will show you the grid fix, the Git status column and the hyperlink behaviour in context, and tell you whether your aliases need adjusting before you switch. For install options, the project documents Cargo, Arch's extra repository, a Debian/Ubuntu repository, Nix and Gentoo; see eza for the current commands.
What features does eza have that ls doesn't?
eza is built to be a drop-in replacement for ls, so it keeps the basic job of listing files while changing the defaults and adding file-type and repository awareness. The most noticeable difference is that colour is on by default and distinguishes file types and metadata, rather than requiring --color or an alias to turn it on.
Beyond plain ls
- Coloured file types and metadata by default, so directories, symlinks and other entries are easier to scan without extra flags.
- Symlink, extended attribute and Git awareness, including Git repository status output in the listing.
- Hyperlink support, which can make file names clickable in terminals that support it.
- Mount point details and SELinux context output, useful when inspecting system or server filesystems.
- Human-readable relative dates, which can be easier to read than raw timestamps.
- Bright terminal colour support and several security fixes compared with exa, the project it branched from.
The page also notes that eza is a single binary and describes it as small and fast, which matters if you want a replacement that does not pull in a runtime or a set of dependencies. The trade-off is that eza is not the system ls: scripts that parse ls output, rely on exact default formatting, or run in minimal environments may still need the original command.
A practical next step is to try eza in a directory you know well, such as a Git repository, and compare its output with ls -la. If the coloured types, Git status and relative dates help you spot what changed, eza is doing its job; if you mainly need predictable machine-readable output, keep ls for scripts. The project is available for Windows, macOS, Linux and BSDs, and the page lists installation through Cargo, Arch’s extra repository, a Debian/Ubuntu repository and Nix, so you can test it without replacing your existing ls first. For general background on the original command, GNU Coreutils documents ls and its many options.
How do I configure eza's colors and icons?
eza ships with sensible color defaults and icon support, but both are configurable. The mechanism depends on whether you want a one-off change or a persistent one.
Colors
- Environment variables:
LS_COLORSis the standard way to remap file-type and extension colors. eza also readsEZA_COLORSif you want eza-specific overrides that don't affectls. Set them in your shell profile. - Per-invocation flags: eza uses
--color=always|auto|neverto control whether color is emitted at all, and--colour-scale/--colour-scale-modefor size-based gradients. It also supports bright terminal colors, which olderexadid not. - Theme files: eza can read a theme file via
EZA_CONFIG_DIRand--theme, letting you keep a named color scheme instead of a long inline string.
Icons
--iconsturns on the icon column;--icons=always|auto|nevercontrols when it appears (e.g. only in interactive terminals).--no-iconsdisables them for a single run.- Icons require a Nerd Font in your terminal. Without one, glyphs render as boxes, so
autois the safer default on machines you don't control.
Practical next step
Audit your current setup before editing:
eza --color=always --icons=auto -la
If the colors look wrong, check whether LS_COLORS is set by your distro's dircolors output. If icons show as tofu, install a Nerd Font and set it in your terminal emulator. For a persistent config, put EZA_COLORS and EZA_CONFIG_DIR in ~/.bashrc or ~/.zshrc, and use --theme to point at a theme file.
For comparison with the original tool, the GNU coreutils documentation covers LS_COLORS semantics in detail, and the eza project itself is at eza.
What are the security fixes in eza compared to exa?
The eza page states that its feature set includes “several security fixes” relative to exa, but it does not enumerate them on the page. So the honest answer is: the project claims security fixes exist, and the specific list has to be read from the changelog, release notes, or the commit history in the eza repository rather than from this page.
What the page actually says
- eza describes itself as a modern, maintained replacement for
ls, with more features and better defaults. - Its “features not in exa” list includes hyperlink support, mount point details, SELinux context output, Git repo status output, human-readable relative dates, bright terminal colour support, and many smaller bug fixes.
- “Several security fixes” appears in that same list, alongside a fix for “The Grid Bug” introduced in exa 2021.
That framing matters: the security items are presented as part of a broader maintenance gap, not as a named set of vulnerabilities.
Practical reading of that claim
If you are choosing between the two tools, treat “security fixes” as a maintenance signal rather than a guarantee about any single issue. A file lister mostly reads directory metadata and prints it, so its exposure is narrower than, say, a network service — but it still parses filenames, symlink targets, extended attributes and terminal output, and it can be pointed at untrusted directory trees. Two things follow:
- For a workstation or server: the more relevant question is whether the tool is still receiving fixes at all. eza presents itself as maintained and actively developed; exa has not kept pace, which is the main reason a former exa user would switch.
- For a script or CI pipeline: the security angle is usually less important than output stability and exit codes. If you are replacing
lsinside automation, test the flags you rely on before committing, because a “more featureful” default can change formatting.
How to get the actual list
The page offers no CVE numbers or patch descriptions, so use the project's own history:
- Open the eza repository and read the changelog or release notes for entries mentioning security.
- Search the commit log for terms like “security”, “CVE”, “overflow”, “escape” or “sanitise”.
- If you need an auditable answer for a compliance review, cite the specific commits rather than the marketing line.
Choosing between them
| Situation | Reasonable choice |
|---|---|
| You want current features and ongoing fixes | eza |
| You have exa in a frozen, working setup | Staying is defensible, but you accept no new fixes |
| You need a documented security rationale | Read the changelog and commits, not the feature list |
You are replacing ls in scripts |
Test flags and output first, whichever you pick |
A concrete next step: install eza in a scratch environment and run it against a directory containing symlinks, odd filenames and a Git repository, comparing the output with your current ls alias. That tells you more about day-to-day impact than the security wording alone. For background on the wider Rust CLI ecosystem, GitHub hosts the eza source and issue tracker, where the security-related changes are recorded.
Cloudflare
Fastly
User reviews (0)