exa update v0.8.0

exa v0.8.0 is out! You can grab it from GitHub or from exa’s website.

Here’s a round-up of some of its features, and some notes on how I’m going to manage releases in the future.

Command-line options

A common grumble was that the options parser was too strict. ls has a philosophy of “never complain, list a directory no matter what” which I wanted to avoid, because it’s bitten me too many times before. exa, on the other hand, went a bit too far in the other direction: the options had to be specified exactly every time, meaning you couldn’t use an alias to change your own default settings, or change your mind after writing the command.

$ alias exa="exa --sort=modified"
$ exa --sort=ext
Option "sort" given more than once.

exa now uses the settings specified last, so you can change the default settings to your heart’s content:

$ alias exa="exa --sort=modified"
$ exa --sort=ext
✔︎ No problem!

Git support everywhere

When I added the Git column to exa all those years ago, I added it for the one place I needed it: when listing directories. From that point on, exa assumed that the only place a Git repository would be was if you were listing a directory, rather than listing one file, using a glob, putting everything in a tree, or anything else.

Now, Git repositories are associated with files, rather than with directories, meaning you can use it anywhere you can use --long:

$ exa --long --git pages/exa-*.html
.rw-r--r--@ 7.7k ben 30 Sep 10:07 -N pages/exa-v0.8.0.html

$ exa --long --git pages --tree
drwxr-xr-x     - ben 30 Sep 10:49 -N pages
.rw-r--r--@  354 ben 24 Sep  0:25 -M ├── 404.html
.rw-r--r--@ 7.8k ben 30 Sep 10:51 -N └── exa-v0.8.0.html

This involved a lot of internal restructuring to get it to work, and I’m real glad to have it done!

Experimental theming support

Here’s something new: exa now allows you to customise the colours of filenames, columns, and other UI elements.

ls has traditionally supported customisable colours through the LS_COLORS environment variable. Set it to a string with ANSI codes, colons, and equalses, and your files will be coloured:

$ export LS_COLORS="di=34:ln=32;*.zip=31"
$ exa
src  link_to_src   src_archive.zip

exa now obeys the LS_COLORS variable, and any colours you define in it will be applied to your files.

Now, this is fine when all you have to colour is the names of files, but exa colours the permissions, the file size, the users, dates, and other such things. With so many colours, is putting them all in one cramped environment variable really the best way to do this?

Well… it will be until I come up with a better solution!

If you want to define your own theme for exa, then you’ll have to write a really long EXA_COLORS variable that includes a lot more colour codes. File name globs specified here will override those in LS_COLORS, and you can begin the sequence with reset if you want to disable exa‘s built-in colour set.

$ export EXA_COLORS="reset;uu=32;*.zip=38;5;81"
$ exa src_archive.zip
.rw-r--r-- 567k ben 20 Aug 20:51 src_archive.zip

For the full details of which two-character codes mean which interface element, and which numbers mean which terminal colour, see exa’s man page.

What's next?

The new options parser was mostly written in the small town of Mallaig, in the Outer Hebrides — probably best known for being the destination of the Jacobite steam train. (You know, the one that goes over the Glenfinnan Viaduct in the Harry Potter films.) It’s home to just a few thousand people, but according to the ones I spoke to, a cruise ship docks nearby a couple times a year and the whole place gets flooded with over twenty thousand more.

If exa started doing release codenames, I’d pick “Mallaig” as the first one. A few weeks ago, it made it to the top of Hacker News, right when I was about to go to sleep! I was up until 3am writing comments.

Unfortunately, a bug that lots and lots of people immediately ran into was that exa didn’t actually work on a fresh Linux install. If you’ve ever seen an error about libhttp_parser.so.2.1 being missing, you know which bug I’m talking about.

The solution turned out to be fairly complicated — I had to use a dumb Cargo hack to get it to work — but that’s not the point. I still had to do the build, upload the stuff, prepare the release… all things I can do, but they’re such a pain to do manually that it’s just so much easier to put them off. It’s my fault, simple as that.

I was in a similar situation a few months ago. The solution I tried was to impose a six-week release schedule to try to get me to do these releases more often. And this worked, for a while, right up until the point it didn’t. Trying to get a handle on motivation is a tricky task, and currently I’m not aware of any solutions other than “keep trying stuff until you find a process that works”.

This time, I want to try weekly minor (or “point”) releases. These won’t have the same guarantees as the six-week regular releases, and might not be accompanied by proper release notes like you’ll find on GitHub or this site, but they’ll get me in the habit of getting code out to people and give anyone affected by a bug a chance to upgrade without having to wait.

Actually, the more immediate plan is to go to RustFest and mingle. I think I’ll do that one first.∎