A modern replacement for ‘ls’.
Go to file
2020-01-18 22:41:53 +00:00
contrib remove shebang from fish completions 2019-07-19 20:06:04 +01:00
devtools Change user in Vagrantfile 2018-09-26 21:25:50 +01:00
snap Add snap support for ease of deployment 2017-08-12 22:22:22 -04:00
src Add documentation for --icons flag 2019-07-19 09:58:50 +03:00
xtests Fix failing tests 2019-07-15 03:37:05 +01:00
.gitignore Merge branch 'master' of https://github.com/willdeberry/exa into willdeberry-master 2020-01-18 22:04:44 +00:00
.travis.yml Fix compile error with --no-default-features 2017-09-14 11:33:24 +01:00
build.rs Rename the zips for weekly releases 2017-10-08 20:53:36 +01:00
Cargo.lock v0.9.0 2019-07-15 04:07:45 +01:00
Cargo.toml Merge branch 'master' into cargo-deb-spec 2020-01-18 22:41:53 +00:00
LICENCE Update LICENCE 2014-07-02 22:07:09 +01:00
Makefile Fix ZSHDIR 2019-01-27 11:21:59 +08:00
README.md Merge pull request #457 from ariasuni/fix-sorting-by-created-time 2019-07-15 03:30:52 +01:00
screenshots.png Update screenshots 2015-11-23 19:48:30 +00:00
Vagrantfile git2-rs v0.9.1 2019-07-14 11:42:58 +01:00

exa Build status

exa is a replacement for ls written in Rust.

Rationale

exa is a modern replacement for the command-line program ls that ships with Unix and Linux operating systems, with more features and better defaults. It uses colours to distinguish file types and metadata. It knows about symlinks, extended attributes, and Git. And its 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.

Screenshots

Screenshots of exa

Options

exas options are almost, but not quite, entirely unlike ls's.

Display Options

  • -1, --oneline: display one entry per line
  • -G, --grid: display entries as a grid (default)
  • -l, --long: display extended details and attributes
  • -R, --recurse: recurse into directories
  • -T, --tree: recurse into directories as a tree
  • -x, --across: sort the grid across, rather than downwards
  • --colo[u]r: when to use terminal colours
  • --colo[u]r-scale: highlight levels of file sizes distinctly

Filtering Options

  • -a, --all: show hidden and 'dot' files
  • -d, --list-dirs: list directories like regular files
  • -L, --level=(depth): limit the depth of recursion
  • -r, --reverse: reverse the sort order
  • -s, --sort=(field): which field to sort by
  • --group-directories-first: list directories before other files
  • -D, --only-dirs: list only directories
  • --git-ignore: ignore files mentioned in .gitignore
  • -I, --ignore-glob=(globs): glob patterns (pipe-separated) of files to ignore

Pass the --all option twice to also show the . and .. directories.

Long View Options

These options are available when running with --long (-l):

  • -b, --binary: list file sizes with binary prefixes

  • -B, --bytes: list file sizes in bytes, without any prefixes

  • -g, --group: list each file's group

  • -h, --header: add a header row to each column

  • -H, --links: list each file's number of hard links

  • -i, --inode: list each file's inode number

  • -m, --modified: use the modified timestamp field

  • -S, --blocks: list each file's number of file system blocks

  • -t, --time=(field): which timestamp field to use

  • -u, --accessed: use the accessed timestamp field

  • -U, --created: use the created timestamp field

  • -@, --extended: list each file's extended attributes and sizes

  • --git: list each file's Git status, if tracked or ignored

  • --time-style: how to format timestamps

  • Valid --color options are always, automatic, and never.

  • Valid sort fields are accessed, changed, created, extension, Extension, inode, modified, name, Name, size, type, and none. Fields starting with a capital letter sort uppercase before lowercase. The modified field has the aliases date, time, and newest, while its reverse has the aliases age and oldest.

  • Valid time fields are modified, changed, accessed, and created.

  • Valid time styles are default, iso, long-iso, and full-iso.

Installation

exa is written in Rust. You will need rustc version 1.17.0 or higher. The recommended way to install Rust is from the official download page. Once you have it set up, a simple make install will compile exa and install it into /usr/local/bin.

exa depends on libgit2 for certain features. If youre unable to compile libgit2, you can opt out of Git support by running cargo build --release --no-default-features.

If you intend to compile for musl you will need to use the flag vendored-openssl if you want to get the Git feature working: cargo build --release --target=x86_64-unknown-linux-musl --features vendored-openssl,git

Cargo Install

If youre using a recent version of Cargo (0.5.0 or higher), you can use the cargo install command:

cargo install exa

or:

cargo install --no-default-features exa

Cargo will build the exa binary and place it in $HOME/.cargo (this location can be overridden by setting the --root option).

Homebrew

If you're using homebrew, you can use the brew install command:

brew install exa

or:

brew install exa --without-git

Formulae

Nix

exa is also installable through the derivation using the nix package manager by running:

nix-env -i exa

Testing with Vagrant

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, its impossible to do a complete end-to-end test without mandating the current users 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 more than one 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 users 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, exas dependencies, configures the environment, and generates some awkward files and folders to use as test cases. This takes some time, but it does write to output occasionally. 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!

Running without Vagrant

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 isnt a necessary development step — its there if youd 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 cargo build and cargo test.