Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls.

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.

If you're interested in learning Rust by watching someone work, the author did several long screencasts of himself working on exa: https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w

It is great to scratch an itch and make something behave exactly as you want it to be - kudos.

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.

I just noticed the tests and the incredible lengths the author went to in order to effectively test exa. It's really impressive. GNU coreutils ls has a pretty good test suite, too ( http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls ), but this goes well above and beyond the call for something so new.

This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.

I set up $LS_COLORS like 15 years sgo in my .zshrc… and haven't had to touch it since. Doesn't seem like a huge deal worth replacing it over.

> For example, exa prints human-readable file sizes by default (when would you not want that?)

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.

It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'.

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.

This is cool, but it doesn't solve (in fact, exacerbates) my usual complaint with `ls` - I don't know what the arguments are. The example on the site is:

    exa -bghHliS

I love it, but it's also kinda angry fruit salad.

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.

exa is hard to type, bad choice of name for something I'd be typing many times a day

There's only one problem with this thing: all the characters are on one hand with a qwerty keyboard! A bit more annoying than ls, where you can practically hit the keys simultaneously. (You want to nitpick the colors, do you? I'll show you what real bikeshedding is...) In all seriousness, though, it looks good.

I find quite funny that the author is so convinced that the use of colors is the "right default". 1) I'm colorblind so my view of colors is different from yours. 2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, one for - and a third one for the rest, nice!).

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.

The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa

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)

The feature I'd be most interested in here is the integration with git, but I don't see an example on the site that demonstrates that. If the author is reading this, could you please add one? (Or maybe point it out, if I'm just missing it?)

>although Rust is cross-platform, I don’t have a Windows machine to develop on...

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.

This is really cool - bringing the great treatment of `ack` to ls. And can confirm how fast it is!

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`

Does it take into account the background color of my xterm so things do not become unreadable?

> exa is written in Rust, so it’s small

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.

What do all the colors mean? I wish he would make a little page explaining what I'm looking at and what each color means.

Receive the feedback, but ignore the haters and do what you feel is right for your brainchild.

I've learned some commandline tricks just from reading the comments!

Very interesting - thanks.

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

so whats the replacement for sl in that case? can't live without it

Looks very nice, I've been using K, which has some other cute features (https://github.com/supercrabtree/k), but I'll definitely add this to my arsenal.

This is cool, I was having trouble with libraries, so I'm switching my main Linux to Arch.

A multi-threaded program to list files. The times we are living in...

I'll give it a try for a few weeks.

I've been using k [1] to get pretty much the same functionalities but, being written in zsh, it's terribly slow. Your program looks nice but I would love to have an output closer to k in term of colour [2], at the moment it feels way to noisy to me.

[1] https://github.com/supercrabtree/k

[2] https://raw.githubusercontent.com/supercrabtree/k/gh-pages/f...

./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory

Couldnt all the dependencies be statically linked for max portability?

This is great. I'm switching to exa!

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

so... a mix up of the following:

which ls alias ls='ls --color=auto' /bin/ls

tree -L 2

git diff --stat

git status

Is this intended as a full on ls replacement? As in, does it respect the envvars such as lscolors? Will it silently ignore -h, or will it die violently?

My first thought is that "exa" has all three letters in the left hand. Not nearly as easy to type as "ls".

I really dig the very useful output, but I'd also muchly appreciate an `ls` compatibility mode. Thus, one could put something like `alias ls='axa --compat'` into .profile and wouldn't have to re-train their muscle memory. F.e., I'm personally using `ls -altr` very often, and `axa -altr` will yield me an error.

Very cool project, will replace ls for exa :)

If you want colors, you can use grc to colorize command outputs not just ls, even MySQL terminal.

Some old HN thread. https://news.ycombinator.com/item?id=3858954

I used it now for a year (maybe more, I can't remember) and I find it fantastic. It's great, and I can't imagine using plain old ls any more. No matter what people say, I love it.

I already installed & replaced my ls config. Thanks for making it!

Interesting that they chose to keep the file name on the right-hand side like ls, and unlike every graphical file manager.

The name is the key field and so it should generally be the left-most column.

For a command that gets typed as often as 'ls', choosing 'exa', which is typed with one hand only, even worse, with a repeated finger, is kind of a poor choice.

i know this may sound trivial, but I'd probably never use this just because typing exa is a lot more annoying than typing ls. The three letters are on the left side of the keyboard and on the three rows. Sure I could rename it to something I like, but then I won't be able to get used to it, because I won't be able to find it when I log on to other computers. It's a silly thing that has a serious impact on usability...

No one invented anything better than Commander-type UI for dealing with files. For non-trivial tasks I'd fire up vifm.

This is amazing! Now:

* can you use unicode icons to replace `d` and others with icons of folders and such?

* where are the color signification explained?

Surprised no one has suggested replacing permissions display with emoticons.

What does "exa" stand for? That's what I want to know.

What is the usefulness/learning_effort ratio of this tool?

I honestly just like it, colors make it easier on my eyes

$ exa -bghHliS ????

How about: $ exa . -- with the same outcome? :)

The last thing I want in terminal is colours.

Why do you want to replace ls?

Nice, I like the -T option.

exa is harder to type than ls, but this looks really cool.

The name is too long.

cool. i feel like this whole thread is the epitome of hacker news comments

This looks awesome. Anyone's gonna make a PR for ubuntu to add this?

Wow I’m quite overwhelmed by the colors

ohh i thought exa was a replacement for the word 'is'. i was like damn.... that's fucking cool.

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

i'm not going to be rude or hate exa, it looks really cool actually. I, for one, love the color coding. But trying to replace something as old and known as 'ls' probably isn't a realistic goal. I think talents would much better geared towards something missing, instead. Either way, keep up the good work.

> Git support: View the staged and unstaged status of every file, right there in the standard view. Also works in tree view.

This is nearly impossible to implement securely.

Better don't run exa against untrusted directories.

To the author: As you are already making a much more user and human friendly version of ls (like making ls -h the default behavior) please consider placing the name of the file on the left most column

   inode Permissions Links  Size Blocks User Group Date Modified Name

As 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

Color is one of the first things I turn off. So many tools color files in ways that are very difficult to read (dark blue against a black background, really?)

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