Introduction
exa is a modern replacement for the command-line program ls that ships with Unix and Linux operating systems.
This command is used by terminal users, administrators, and developers hundreds of times daily, as well as being useful when writing automated scripts.
Unfortunately, these two uses are at odds with each other. While users want new features and customisation, administrators would prefer the stability of a long-lived and ubiquitous tool.
By deliberately making some decisions differently, exa attempts to be a more featureful, more user-friendly version of ls.
Now that ls has been around for over forty-five years, exa can be developed under a different set of assumptions than were around in the 1970s:
The computer is no longer the bottleneck.
A developer working on Unix in the 1970s would have interacted with it using a teletype: a machine with a keyboard and printer that could talk to a Unix computer remotely.
Every keypress was sent over a physical wire, and the computer would then process it and send back some characters for the teletype to print out.
The operating system’s short command names reflected this: commands such as ls, mv, and cp would be quick to transmit, even compared to list, move, and copy.
This isn’t the case anymore — thanks to faster computers, disk drives, and network connections, displaying more information is almost always preferable to spending a few extra fractions of a second waiting for that information to come in.
Here’s an example.
exa, by default, runs the stat system call on every file it encounters.
This requires communicating with the storage device or hard disk to get that file’s type and permissions, which determine how that file gets coloured and displayed on screen.
The system call, which may have been expensive in the days of time-shared computers and slow connections, is still not free, but is extremely cheap.
The extra information is worth the minuscule increase in processing time.
256-colour terminals are everywhere.
Not only has the teletype’s hardware — an input device and an output device — been integrated into the computer, but its software has as well. Whenever you open a new terminal window, it asks the OS for the connection to a new pty, also known as pseudo-tty, or pseudo-teletype.
Your terminal application (also known as a “terminal emulator”) is responsible for converting the stream of characters it gets from the connection into a grid of characters to be displayed on screen. It handles things like choosing and rendering fonts, scrolling, converting keypresses into bytes to be sent to the terminal, and also handling codes for colours and styles.
These terminals (and their emulators) could understand escape codes that changed the style or colour of the output, such as “make the text blue”, or “make the background red and the foreground white”, or “start underlining everything”.
Support for these escape codes has now become commonplace. exa makes heavy use of colours, treating them as opt-out rather than opt-in: it will highlight files and data differently based on their type or meaning.
ls is still there if you need it.
Of course these assumptions will not always hold.
You may be examining a broken hard drive, and cannot afford to make any unnecessary stat calls.
Or you might have an extremely slow network connection, and the overhead of ANSI colour codes makes your terminal lag.
exa gets to make some of its more drastic backwards-incompatible changes because the venerable, predictable ls program is not going away.
Scripts that require a particular quirk that exa can’t quite replicate will all still continue to run.
It’ll still be there in /bin if your connection suddenly starts to lag, and automated scripts will still use ls by default.