Exa, a modern replacement for ls
the.exa.website
the.exa.website
I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!
Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.
I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.
Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.
Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.
I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.
I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think
As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.
Why not? I would.
For me, when I see people waxing poetically about the unix way and the old, crufty, POSIX userland, it's all about cargo cult, "that's how things have always been", minimum viable progress while keeping compatibility, and heritage-over-substance.
`grunt test`.. ooh, so pretty and creative! `grunt test > test.out`, wtf, why is my file full of control character bullshit?
exa was my first Rust project and it just grew and grew.
It would also be nice to see files owned by different users and some of the git functionality.
ls is a gold standard but that doesn't mean alternatives aren't interesting. Especially as a FOSS project in rust I find it fascinating.
Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.
#!/usr/bin/env ruby
`ls`Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.
oh wait, I know what behaves exactly the same way: ls
That said, this is very much not for me. Default-colorized is something I emphatically do not want; defaulting to relative units, ditto. It it were me, the first thing I would do is get rid of 'grid' display entirely - reading across just doesn't work for me. Etc.
More prosaically, `ls` is sort of like breathing for me - I do it so much during the average day that I don't even think about it. Can't say I immediately know every one of the switches, but probably 10 or so variants I use daily are pure muscle memory, and less frequently used things (extended attributes, symlink-deref options, etc.) I can remember without the man page.
So in that sense, `ls` is well into the same category as vi for me - I'm so accustomed to whatever warts there may be that switching would be much more painful than any efficiency gain.
ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.
(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)
That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.
It wouldn't be right if something didn't go badly wrong at the worst possible moment!
One thing I always wanted to remove from `ls` is the default "human-like" display of dates and times (which `exa`, unfortunately, seems to inherit). This is IMO just annoying (and replacing time with year, if it differs from current, just plain stupid; and don't get me started about the "bright" idea of using locales there!). We have ISO-8601 for a reason. It's readable and universal. 2017-06-17 is easier to parse than "cze 17" (hello, locales).
export TIME_STYLE=long-iso
I also have this, for the thousands-comma display:
export BLOCK_SIZE="'1"
$ ls -on i*
-rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg
-rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
-rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...
If I want something fancy, I will use emacs dired mode as a filesystem navigator and magit for git repos.
And cynically, if this wasn't written in Rust I don't think it's on the front page.
You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".
Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.
That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)
I think the coloration is good, but I would have defaulted a bit differently in the permissions. I would have made all user bits green, all group bits orange, and all other bits red. Not only does this denote the possible security implications of the permissions, but it also maps well to what I'm usually looking for - what are my permissions, and being able to see all those quickly with green would be useful. As an added benefit, there wouldn't be as many per-character color changes in that section, so it would be less busy.
Awesome work, BTW. I love seeing interesting re-imaginings of old standby utils. I was actually thinking of doing my first real Rust project as a cat replacement. I was thinking of calling it calico. ;)
Don't feel too let down by the comments on HN. Awesome work!
Just some ideas, maybe you like some of them :)
Seems to be the case that there is no modern text editor that doesn't color every single word. Must be so hard for you now that you're forced to use these tools with such "poor usability and design". How do you even manage?
Related: http://www.linusakesson.net/programming/syntaxhighlighting/
Just clicked-through to see what you meant about `exa -l` and I agree. When individual characters have different colors that's just way too much.
It's not "the sane thing" to differentiate output on STDOUT's attributes. grep doesn't have the --colour option ternary for nothing.
When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.
That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.
HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.
> HN is so predictable that I knew someone would complain about this the second I read it
And I considered there'd be a pretty good chance that I'd get a reply like this.
Doesn't sound like a default case to me.
Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
In a program that natively makes strong use of colour, though, here's an option: print exact file sizes, but in two related colours (say, bright yellow and dark yellow/brown), as follows: the first colour for the first 1, 2, or 3 digits, and the other for the remaining $n$ digits where $n$ is divisible by 3. That way the first colour will represent a whole number of KB, MB, GB, etc—and which of these it is will be very clear as it's easier to get that rough-count size—and the fainter/darker colour would give the full exact number of bytes. Best of both worlds!
export TIME_STYLE=long-iso
export BLOCK_SIZE="'1"
$ ls -on i*
-rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg
-rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
-rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...
The rendering of time in any format other than ISO-8601 is a pet peeve of mine. It always baffles me why people do it.
alias ls=exa
command ls \lsIf they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
I disagree; what's easier, spotting the biggest and smallest of these at a glance:
6,677,967
5,916,109
7,164,551
3,745,059,597
3,175
4,194,304
3,550,137
6.37M
5.64M
6.83M
3.49G
3.10k
4.00M
3.39M
But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.
I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.
Seriously, "du -h | sort -h" is a regular command for me.
At least I learned that ls had a -h option. I don't know why I should use it on files but I routinely do df -h to check the size of file systems. That's a place where it is useful.
I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24'
Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandline tool, as I'm a big fan of 'ripgrep', another popular tool written in Rust.
'ls' (and 'exa') is nice because it's pretty fast. If I'm going to use 'du', I'm wading in with the assumption that it'll take a while. It'd be a cool option to add, but I don't think it should do it by default.
Why?
On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.
du -hc | sort -hn | tail
An example would be busybox, which can decide which executable to pretend to be by the target name.
exa -bghHliS
alias exa-size='exa -bghHliS'Colors are good...too many colors is overwhelming. It might be that I'd come to recognize what the colors mean if I work with it every day, in the same way that I begin to recognize the flow of a program and when a color is "wrong" after using the same syntax highlighting in an editor for a long time. But, I couldn't tell you what any of the colors mean in my favorite editors.
It's more about recognizing when something has the wrong color compared to everything else with that "shape". e.g. a good example is that in shell scripts, I often put space between the var name, '=', and the value. That's not an assignment and can lead to subtle bugs (shellcheck will catch it, too, but I see it clearly in the editor because it doesn't highlight as a variable declaration).
So, what I'm getting at is that I'm pretty sure I'll always have to read the actual text to make any sense out of this output; the huge number of colors may just hinder readability. I don't know this for sure, but it's pretty jarring to look at even with a nice muted color scheme. I love colors in terminals, though, so I'll give it a go.
I don't think it's too much of an ask for people to define their own aliases for it, though. The overlap between people who install custom command-line tools and people who know how to edit their shell config can't be small.
alias asd=exa
alias h=ls
alias hh='ls -l'
alias lrt='ls -lrt'
alias lrta='ls -lrta'
"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.
Also I've noticed terminal emulators (like terminator) recognize output and sprinkle in formatting on the display.
iirc, if your terminal emulator is doing something funny with the output of `ls` it's because they've re-implemented it as a function and are intercepting the call to ls and running their function instead, not because they're recognizing the output.
But yeah, alias ls=exa also works.
It's top row, bottom row, middle row, and the 'x' on a normal keyboard is half way to being directly under the 'e'. Very awkward and antithetical to the ideas of people who have designed keyboard layouts specifically for efficiency and ergonomics.
The only demographic that comes to mind which would find that hand position "natural" would be guitarists and other string players.
export pls=exaThey are also all on the left hand in both Dvorak and Neo.
Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!
So colors by default? Thanks but no thanks.
Speaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).
* http://invisible-island.net/xterm/xterm.faq.html#dont_like_b...
Is the problem really that there are colors, or that the colors used don't work well for colorblindness? Do you find coloring that doesn't go afoul of your particular type of colorblindness still less useful than no coloring, or is it just that so often little attention is paid and an assumption is made that it's no worse than monochrome when in actuality it sometimes is?
I guess my real question boils down to if whether the author tried to make the default color profile at least not horrible in some respects for most colorblind users, would you still think defaulting to color is the wrong default?
1. It improves the presentation of information. The vast majority of colorblind can still see color. In this respect, we are no different from people who have normal color vision.
2. It has no impact upon the presentation of information. In these cases, the colors may not be distinguishable but there are other cues that convey information. I typically think of these cues as context. An example of context relevant to to exa is the column or character used to represent the information.
3. It degrades the information being presented. In addition to there being different types of colorblindness, each type seems to be variable. That is to say that most colorblind persons aren't actually blind to a particular color, they are simply less sensitive to that color. This means that they may be able to see a color if it is intense. Using colored text is really bad in this respect since it is typically less intense, likely due to a small number of pixels being illuminated. This reduces the legibility of text to varying degrees.
4. It makes information illegible. This is essentially the extreme version of case 3. This happens when the contrast is so low that color is the main distinguishing factor, so it may be nearly impossible to distinguish two adjacent colors (such as foreground and background colors for text).
Take anything that I say at face value. It is largely based upon personal experience. The only thing that I can say with certainty is that colorblind people see color differently. I suspect that people with normal color vision suffer from similar issues to colorblind individuals. It simply manifests itself in a standard way so that there are standard design methods to avoid it. Of course colorblind people throw a wrench into the works because their vision is calibrate in different ways due to their sensitivity to each color.
I don't think it's colourblindness, but I have trouble reading ANSI blue, which xterm defaults to rgb(0, 0, 238). I've changed it to be a roughly Persian green colour rgb(0, 166, 147).
If I had the most common male colourblindness, I'd probably add some orange to the default reds.
I understand that the answer may be different for different people in somewhat non-subjective ways, since there are different types of colorblindness.
Applying your physical shortcomings to a project when you are by and large the minority makes very little sense.
If `ls` is better for you, use `ls`.
If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.
For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor), because it makes sharing easier, or anything which I need to work with as part of a team (version control).
This is not that. File listing programs are local and isolated. My experience using some file listing program does not improve if more people use the one that I am using. In this case, it makes more sense to have exa or ls or whatever be the software that addresses 99% of use cases for the average user. Then, for the portions of the population with particular needs, you make software that is particularly tooled towards them.I am not colorblind, so having support for colorblindness just makes software more bloated.
tl;dr - I agree with your sentiment when it comes to programs that need/want "universality". This is not one of those programs and doesn't need to be.
I know that Gnome Terminal supports[1] different colour schemes which you can customise, and I think this is the point where it should be implemented at.
What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.
If your machine uses termcap/terminfo, type this to see how many yours supports.
tput colorsWhat I did was make sure the background colors were always dark, and set the first 16 terminal colors to be light. I randomized the background color by specifing it to the terminal via a command line option as the output of this 10-line script[1] that takes an HSV Value as an argument and returns an RGB with randomized Hue.
It's nice for terminals to be differently colored when you have many of them open. It helps one to realize when you've switched to the right one.
From https://www.iterm2.com/documentation-highlights.html:
> Sometimes an application will display text with a color combination that is hard to read. Colorblind users in particular may find certain combinations hard to see if the colors differ only in hue and not brightness. If you enable minimum contrast (under Preferences > Profiles > Colors > Minimum contrast, then iTerm2 will guarantee a minimum level of brightness difference between the foreground and background color of every character. If you set this to its maximum value, then all text will be black or white.
BTW, I actually like having the git hashes almost invisible. I don't need to see the hash, I just want to double-click to copy it.
EDIT:
"exa prints human-readable file sizes by default (when would you not want that?)"
I actually use bytes a lot for certain progress calculations.
Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory" (Ubuntu 17.04)
I can see how it looks VERY SUSPICIOUS for a file lister to be parsing HTTP headers! I'm not going to sell your directory entries to advertisers, I promise.
⋊> ~/Downloads ./exa-linux-x86_64 --version 15:26:40 ./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
...yup.
Are you really sure you want to replace ls with exa? I can think of a dozen reasons it could cause trouble.
Actually replacing the binary? That would cause so many problems!
In any case, I've been working on a new site for exa, with much better documentation and actual explanations for what the features are, and that has one in it. So you'll have to wait a bit longer I'm afraid. (I could link a screenshot here if you'd like one)
using color to show git status in normal view would be much more interesting to me.
Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes coughMacOScough)
A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies against the pain of using it.
I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows 10 laptop to test on as well.
PS: I develop on Windows
The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools!
Oh, and It's in homebrew already: `brew install exa`
It's the slowest file copy mechanism I've ever used!
Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll Mr Hyde :)
Bit ironical, as ls already is pretty "non-unixy" and has way too many features tacked into it.
From purism point of view it would make more sense that ls would be just a list of files and let other utilities (stat, sort, etc) handle the rest.
But there is a great joy in being able to release a new utility and say about it, "This is how it should work." It reflects your own desires, you understand it, you made the decisions that went into it and have actually thought about the alternatives. There's a delight there. It could be a sign of a piddling egotist, or of a developer who is excited about what real users get to see.
(I did this sort of thing once -- reimplementation of commonly-used, if more niche, thing + manifesto -- from more than 20 years ago: http://all-day-breakfast.com/wm2/)
My main hope for anyone doing this kind of thing is that not too many people actually use it. You don't want to get stuck supporting a tool like this for the world and its dog.
Nothing is more human readable than "123,456,789", so I think the problem is just the way you go about making them human readable. I couldn't agree more that lurching between B, kB, MB, and GB just because the file size changes it extremely jarring and disconcerting, and actually makes comparing the size much more difficult.
Tilting my head every time I wanted to read a title, I didn't fancy though :)
What would people think if all web pages on the internet had ugly black backgrounds?
From the doc, it doesn't appear that colors are customizable, yet. Pull request? :)
Worthy start for a default and you might want to contribute an exa config / env variable setting to solarized.
Shame, the idea is pretty neat. If you can solve that issue, OP, I'd love to give it a proper try.
If your blue doesn't look right on your dark background, why are you using that blue?
If your yellow doesn't look right on your light background, why are you using that yellow?
I mean i get how this can be a problem with hard-coded arbitrary values — you can't ever guarantee that e.g. #ff6600 will go with anyone's particular colour scheme. But these 8 or 16 standard colours are not hard-coded, they're configurable in every terminal i've ever used, including Windows's shitty command prompt. They can and should be set to a value that's appropriate for your background and text colours.
Maybe this is more a fault of the terminal/theme developers for providing unusable defaults. idk.
I suspected this would be total bullshit, and it is. Its small binary is a mere 3.4 megabytes. I wonder if I misinterpreted the "small" part.
38 kilobytes of executable isn't small, it's tiny; there's no way exa could get to that level without compromising its featureset or development, and even if you did, you'd just have another ls, and we already have ls.
If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter files all over your computer" to me, and exa's smaller than that.
Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949
I've learned some commandline tricks just from reading the comments!
/exa/src $ cloc .
41 text files.
41 unique files.
0 files ignored.
http://cloc.sourceforge.net v 1.60 T=0.10 s (423.5 files/s, 64346.3 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Rust 41 1152 929 4149
-------------------------------------------------------------------------------
SUM: 41 1152 929 4149
-------------------------------------------------------------------------------I'll give it a try for a few weeks.
[1] https://github.com/supercrabtree/k
[2] https://raw.githubusercontent.com/supercrabtree/k/gh-pages/f...
You can't grey out the columns in exa until I land configurable colours, which I hope to get done relatively soonish. But you can use the --colour-scale (or --color-scale) option to colour file sizes based on how big they are. The person who submitted the feature request (https://github.com/ogham/exa/issues/65) used k as a direct example.
Couldnt all the dependencies be statically linked for max portability?
The GitHub issue offers a fix for Ubuntu: https://github.com/ogham/exa/issues/194
I had high hopes with this command but found the git features missing: exa -l --git --time-style=long-iso -T
Nonetheless, this displays
Hopefully, the author finds this worth the time to support..
which ls alias ls='ls --color=auto' /bin/ls
tree -L 2
git diff --stat
git status
Certainly not life changing, but after using it for a while, I can tell you that every time I'm on a machine that doesn't have exa, I feel so frustrated ls doesn't give me everything exa has. I often end up downloading exa on any machine that doesn't have it
The problem I see with these "modern" command replacements is 1) muscle memory and 2) I have to log into some old systems that simply will not have anything this "modern".
test -f /usr/bin/exa && alias ls='/usr/bin/exa'
If you want, you can alias it to `ls` so you don't lose muscle memory.
>Is this a drop-in replacement for ls? No — exa has, in my opinion, much saner defaults than ls, so while the available command-line options are similar, they are not exactly the same. Most of the common options will work consistently, though. For example, exa prints human-readable file sizes by default (when would you not want that?) so ls -h no longer applies.
When doing automated text-processing and wanting to easily do precise calculations, without having to deal with different units.
For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal breaker for many.
When its being used as part of a script.
Some old HN thread. https://news.ycombinator.com/item?id=3858954
The name is the key field and so it should generally be the left-most column.
It makes sense to list the filename last IMHO.
#!/bin/bash
alias lse = exa* can you use unicode icons to replace `d` and others with icons of folders and such?
* where are the color signification explained?
It was originally going to be a command-line "file explorer" like ranger, and exa is kind of short for explorer, but I like this quote too.
How about: $ exa . -- with the same outcome? :)
Even just with PATHs or aliases, or a new binary entirely.
And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), https://github.com/rupa/z.
A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.
The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.
Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.
In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, The Tao of tmux [2] (available free to read online).
So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:
export EDITOR=vim
Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:
export GIT_EDITOR=vim
Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:
http://man7.org/linux/man-pages/man5/dir_colors.5.html
edit: actually, BSD's ls(1) seems to be $LSCOLORS (https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1):
[1] http://www.jedsoft.org/most/
[2] https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-t...
This is nearly impossible to implement securely.
Better don't run exa against untrusted directories.
inode Permissions Links Size Blocks User Group Date Modified NameAs a human I first care for the name, Currently I'm forced to scan the right most column (which position varies) and then travel back to the beginning of the line and read the rest of the metadata
And when the terminal is on the left, you don't have to move your eyes so much away from the middle of the screen.
I'm colorblind, too, so your red/orange/green distinctions are utterly wasted on me. Raw color is a very flaky and low fidelity way to communicate to a user.
Animation, on the other hand: Give that super important file that's somehow busted or very active some kind of blink or a meaningful animation and you'll have my attention. I may hate the tool for it, but you'll have my attention...