Exa, a modern replacement for ls

examine?

Drives me a bit nuts too, and I would disagree with some of the other things in this page as well (e.g. the preference for "human-readable" file sizes).

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.

> I hate using 'du'

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.

For comparison, ls is 38k on macOS (edit: and coreutils’ ls is 138k).

While it's not the intention to replace the binary itself, I'm just not a fan of the idea of substituting system built-ins in everyday behavior. Stuff like cd, ls, etc. I like to keep it to the basics.

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