In Operation
Here’s the output generated running exa with the long view, showing the files, metadata, including permission bits, file sizes, and timestamps.
You’ll notice the software offers an attractive color scheme, helpfully making sense of the information you’re presented with. The screen image only shows some of the goodness available. For example, it doesn’t show that exa highlights different file types such as image files, video files, documents, music, archives, cryptography, and much more.
exa lists file sizes using decimal prefixes by default: bytes, kilobytes, megabytes, gigabytes, and so on. Having human readable sizes by default is one of the many differences between exa and ls. The only (initial) downsize is that you need to inspect the suffix to interpret the file size.
One of the tool’s strengths is its long grid view making optimum full use of your monitor. The software displays as many columns as possible with full permissions information.

As an aside, you’ll notice the README and README.md files are coloured differently. These are known as ‘immediate’ files. ‘Immediate’ files are files that are useful files to read or run first. Think of them as your starting point.
You can have directories displayed first with the long ISO time style with the command:
There’s also a useful tree view available which is analogous to the tree command. The tree displays sub-directories inside the listing of their parent directories, helping visualize the directory structure and see which files are where.

Pages in this article:
Page 1 – Introduction / Installation
Page 2 – In Operation
Page 3 – Summary
Complete list of articles in this series:
Excellent Utilities | |
---|---|
tmux | A terminal multiplexer that offers a massive boost to your workflow |
lnav | Advanced log file viewer for the small-scale; great for troubleshooting |
Paperwork | Designed to simplify the management of your paperwork |
Abricotine | Markdown editor with inline preview functionality |
mdless | Formatted and highlighted view of Markdown files |
fkill | Kill processes quick and easy |
Tusk | An unofficial Evernote client with bags of potential |
Ulauncher | Sublime application launcher |
McFly | Navigate through your bash shell history |
LanguageTool | Style and grammar checker for 30+ languages |
peco | Simple interactive filtering tool that's remarkably useful |
Liquid Prompt | Adaptive prompt for Bash & Zsh |
Ananicy | Shell daemon created to manage processes’ IO and CPU priorities |
cheat.sh | Community driven unified cheat sheet |
ripgrep | Recursively search directories for a regex pattern |
exa | A turbo-charged alternative to the venerable ls command |
OCRmyPDF | Add OCR text layer to scanned PDFs |
Watson | Track the time spent on projects |
fontpreview | Quickly search and preview fonts |
fd | Wonderful alternative to the venerable find |
I cringe when I read about CLI utilities written in Rust. That exa binary is over 800KB! (see the exa debian amd64 package)
You make it sound like you’ve made a discovery. Next you’ll be telling us Firefox is a memory hog.
And you should remember that “software bloat always expands to make use of all the memory available” ;+}
It is not a discovery for me, but will be for some, as there are deliberate attempts to cover up how bloated rust-created binaries are. For example, the description here packages.debian.org/sid/exa: “and it is small, fast, and one single binary”. of course, “small” is relative. ‘ls’ is about 145KB. Does some colour-coding, extra columns and git compatibility justify the extra 600KB? I am old-school, probably these days the younger generation of programmers don’t care about the bloat, just the coding conveniences — I have to have a bit of a grumble about it though.