A modern replacement for ‘ls’.
exa is a modern replacement for the venerable file-listing command-line program
lsthat ships with Unix and Linux operating systems, giving it more features and better defaults. It uses colours to distinguish file types and metadata. It knows about symlinks, extended attributes, and Git. And it’s small, fast, and just one single binary.
By deliberately making some decisions differently, exa attempts to be a more featureful, more user-friendly version of
ls. For more information, see exa’s website.
exa’s options are almost, but not quite, entirely unlike
--alloption twice to also show the
These options are available when running with
Some of the options accept parameters:
exa is available for macOS and Linux. More information on how to install exa is available on the Installation page.
$ pacman -S exa
$ apt install exa
$ dnf install exa
$ emerge sys-apps/exa
If you’re using Homebrew on macOS, install the
$ brew install exa
If you're using MacPorts on macOS, install the
$ port install exa
$ nix-env -i exa
$ zypper install exa
$ apt install exa
$ xbps-install -S exa
Compiled binary versions of exa are uploaded to GitHub when a release is made. You can install exa manually by downloading a release, extracting it, and copying the binary to a directory in your
$PATH, such as
For more information, see the Manual Installation page.
If you already have a Rust environment set up, you can use the
$ cargo install exa
Cargo will build the
exabinary and place it in
To build without Git support, run
cargo install --no-default-features exais also available, if the requisite dependencies are not installed.
Once Rust is installed, you can compile exa with Cargo:
$ cargo build $ cargo test
The just command runner can be used to run some helpful development commands, in a manner similar to
just --tasksto get an overview of what’s available.
If you are compiling a copy for yourself, be sure to run
cargo build --releaseor
just build-releaseto benefit from release-mode optimisations. Copy the resulting binary, which will be in the
target/releasedirectory, into a folder in your
/usr/local/binis usually a good choice.
To compile and install the manual pages, you will need pandoc. The
just mancommand will compile the Markdown into manual pages, which it will place in the
target/mandirectory. To use them, copy them into a directory that
/usr/local/share/manis usually a good choice.
exa depends on libgit2 for certain features. If you’re unable to compile libgit2, you can opt out of Git support by running
cargo build --no-default-features.
If you intend to compile for musl, you will need to use the flag
vendored-opensslif you want to get the Git feature working. The full command is
cargo build --release --target=x86_64-unknown-linux-musl --features vendored-openssl,git.
For more information, see the Building from Source page.
exa uses Vagrant to configure virtual machines for testing.
Programs such as exa that are basically interfaces to the system are notoriously difficult to test. Although the internal components have unit tests, it’s impossible to do a complete end-to-end test without mandating the current user’s name, the time zone, the locale, and directory structure to test. (And yes, these tests are worth doing. I have missed an edge case on many an occasion.)
The initial attempt to solve the problem was just to create a directory of “awkward” test cases, run exa on it, and make sure it produced the correct output. But even this output would change if, say, the user’s locale formats dates in a different way. These can be mocked inside the code, but at the cost of making that code more complicated to read and understand.
An alternative solution is to fake everything: create a virtual machine with a known state and run the tests on that. This is what Vagrant does. Although it takes a while to download and set up, it gives everyone the same development environment to test for any obvious regressions.
First, initialise the VM:
host$ vagrant up
The first command downloads the virtual machine image, and then runs our provisioning script, which installs Rust and exa’s build-time dependencies, configures the environment, and generates some awkward files and folders to use as test cases. Once this is done, you can SSH in, and build and test:
host$ vagrant ssh vm$ cd /vagrant vm$ cargo build vm$ ./xtests/run All the tests passed!
Of course, the drawback of having a standard development environment is that you stop noticing bugs that occur outside of it. For this reason, Vagrant isn’t a necessary development step — it’s there if you’d like to use it, but exa still gets used and tested on other platforms. It can still be built and compiled on any target triple that it supports, VM or no VM, with