A modern replacement for ‘ls’.
Go to file
Benjamin Sago 3419afa7cf Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.

The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.

This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.

The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.

There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.

Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 22:34:00 +01:00
.github Use issue templates 2020-10-21 16:59:44 +01:00
completions Convert manual pages to Markdown 2020-10-13 20:19:00 +01:00
devtools Make Vagrant provisioning quieter and faster 2020-10-18 01:19:43 +01:00
man Convert manual pages to Markdown 2020-10-13 20:19:00 +01:00
snap Add snap support for ease of deployment 2017-08-12 22:22:22 -04:00
src Massive theming and view options refactor 2020-10-22 22:34:00 +01:00
xtests More git-ignore xtests 2020-10-17 21:59:15 +01:00
.gitignore Merge branch 'master' of https://github.com/willdeberry/exa into willdeberry-master 2020-01-18 22:04:44 +00:00
.rustfmt.toml Batch source formatting 2020-10-10 20:02:55 +01:00
.travis.yml Travis changes 2020-10-13 21:49:00 +01:00
build.rs IO import changes 2020-10-13 00:54:06 +01:00
Cargo.lock Use Specsheet for the extended tests 2020-10-17 21:12:18 +01:00
Cargo.toml Mass version upgrade 2020-10-10 02:14:35 +01:00
Justfile Use Specsheet for the extended tests 2020-10-17 21:12:18 +01:00
LICENCE Update LICENCE 2014-07-02 22:07:09 +01:00
README.md Slightly better install instructions 2020-10-14 22:20:37 +01:00
screenshots.png Update screenshots 2015-11-23 19:48:30 +00:00
Vagrantfile Make Vagrant provisioning quieter and faster 2020-10-18 01:19:43 +01:00

exa

exa is a modern replacement for ls.

README Sections: OptionsInstallationDevelopment

Build status Say thanks!

Screenshots of exa


exa is a modern replacement for the venerable file-listing command-line program ls that 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 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. For more information, see exas website.


Command-line options

exas options are almost, but not quite, entirely unlike lss.

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
  • -F, --classify: display type indicator by file names
  • --colo[u]r: when to use terminal colours
  • --colo[u]r-scale: highlight levels of file sizes distinctly
  • --icons: display icons

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 files group
  • -h, --header: add a header row to each column
  • -H, --links: list each files number of hard links
  • -i, --inode: list each files inode number
  • -m, --modified: use the modified timestamp field
  • -S, --blocks: list each files 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 files extended attributes and sizes
  • --changed: use the changed timestamp field
  • --git: list each files Git status, if tracked or ignored
  • --time-style: how to format timestamps
  • --no-permissions: suppress the permissions field
  • --no-filesize: suppress the filesize field
  • --no-user: suppress the user field
  • --no-time: suppress the time field

Some of the options accept parameters:

  • 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 available for macOS and Linux. More information on how to install exa is available on the Installation page.

Arch Linux

On Arch, install the exa package.

$ pacman -S exa

Debian

On Debian, install the exa package. For now, exa is in the unstable repository.

$ apt install exa

Fedora

On Fedora, install the exa package.

$ dnf install exa

Gentoo

On Gentoo, install the sys-apps/exa package.

$ emerge sys-apps/exa

Homebrew

If youre using Homebrew on macOS, install the exa formula.

$ brew install exa

MacPorts

If you're using MacPorts on macOS, install the exa port.

$ port install exa

Nix

On nixOS, install the exa package.

$ nix-env -i exa

openSUSE

On openSUSE, install the exa package.

$ zypper install exa

Ubuntu

On Ubuntu 20.10 (Groovy Gorilla) and later, install the exa package.

$ apt install exa

Void Linux

On Void Linux, install the exa package.

$ xbps-install -S exa

Manual installation from GitHub

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 /usr/local/bin.

For more information, see the Manual Installation page.

Cargo

If you already have a Rust environment set up, you can use the cargo install command:

$ cargo install exa

Cargo will build the exa binary and place it in $HOME/.cargo.

To build without Git support, run cargo install --no-default-features exa is also available, if the requisite dependencies are not installed.


Development Rust 1.42+ MIT Licence

exa is written in Rust. You will need rustc version 1.42.0 or higher. The recommended way to install Rust for development is from the official download page, using rustup.

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 make. Run just --tasks to get an overview of whats available.

  • If you are compiling a copy for yourself, be sure to run cargo build --release or just build-release to benefit from release-mode optimisations. Copy the resulting binary, which will be in the target/release directory, into a folder in your $PATH. /usr/local/bin is usually a good choice.

  • To compile and install the manual pages, you will need pandoc. The just man command will compile the Markdown into manual pages, which it will place in the target/man directory. To use them, copy them into a directory that man will read. /usr/local/share/man is usually a good choice.

  • exa depends on libgit2 for certain features. If youre 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-openssl if 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.

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 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 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 and exas 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 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.