
Exa, a modern replacement for ls - r0muald
https://the.exa.website/
======
krat0sprakhar
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.

~~~
userbinator
_Wow, the comments in this thread are quite harsh._

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.

~~~
SmirkingRevenge
Maybe. Whether the term "modern" was used or not, my hunch is that the
response would be the same, for it is forbidden for one to deign to make these
kinds of changes to fundamental Unix commands, and is tantamount to a kind of
heresy (never mind that GNU implementations did this all the time wrt.
original Unix implementations).

Religion... never cared for it. Re-invent the whole crappy (though still less
crappy than alternatives) Unix command line, I say.

~~~
wvh
A lot of stuff depends on the basic Unix commmands though. It might be better
to invent a new command name if the output differs in ways that would break
both human and machine expectations. The difference between BSD and GNU
versions of some commands is already enough to trip me up even after all these
years. You expect `ls` to be `ls` on anything remotely POSIX/Unix-y.

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

------
Perceptes
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](https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w)

~~~
copperx
Is this a trend? Learning by seeing someone write a program? Because I find it
neat.

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

~~~
cytzol
Thanks for the kudos! It's absolutely mindboggling how many times I've decided
to deviate from one of ls's default settings -- certain that the old way was
inferior and outdated, and that the new way will be obvious and immensely
popular -- only to find people have no idea why I'm doing things this way! I
need the colours to help me scan the output; if I don't see human-readable
units, I curse myself for forgetting the flag. But thousands of people don't
like this, and it's usually a different set of features with each person, too.
I would never have guessed I was so 'out there'!

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 :)

~~~
hosh
I use colorized ls by default and get a bit peeved by how I have to jump
through hoops to get that on OSX by default. If it works out. i'll probably
alias "ls" to "exa" in the future.

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.

~~~
cytzol
> That said, the binary isn't self-contained (I know, I know)

It wouldn't be right if something didn't go badly wrong at the worst possible
moment!

~~~
samstave
exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open
shared object file: No such file or directory

~~~
TeMPOraL
Interesting. Why does it need an HTTP parser?! Some accidental dependency
maybe?

~~~
singingboyo
Looks like it has some form of git support, via libgit2. Dependency chain for
that is probably where it came from.

------
SwellJoe
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](http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls)
), but this goes well above and beyond the call for something so new.

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

~~~
arkitaip
The more design elements you add - colors, type, graphics etc - the more
distracting the design get and the more conflict there is between the design
elements. By colorizing everything here, nothing is important anymore. It's
just poor usability and design.

~~~
cytzol
(author here)

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)

~~~
kbenson
> 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 "-".

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

~~~
dfc
I really like a lot of the extra colors but I was also overwhelmed by the
rainbow permissions. User, group, world are the organizing principle for me.
World writeable is something I never want to have in my mind as similar to
user writeable.

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

~~~
laurent123456
It's not exactly the same though. LS_COLORS only colours file types (whether
it's a file, dir or symlink) and permissions, while exa appears to also set
the colours based on the mime type (text, image, etc.).

~~~
vanjoe
I'm pretty sure ls does this as well. At least for images and archives

~~~
DonaldPShimoda
Specifically, you list which extensions should get what colors. So it's more
like telling ls "Color anything ending in .jpg or .gif in red", as opposed to
"Color all images red".

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

~~~
Symbiote
I'll repeat this here:

    
    
      export TIME_STYLE=long-iso
      export BLOCK_SIZE="'1"
    

The first option gives ISO dates, the second the thousands separator. You need
a locale for a thousands separator, en_GB here:

    
    
      $ 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
    

Block size:
[https://www.gnu.org/software/coreutils/manual/html_node/Bloc...](https://www.gnu.org/software/coreutils/manual/html_node/Block-
size.html)

Time style:
[https://www.gnu.org/software/coreutils/manual/html_node/Form...](https://www.gnu.org/software/coreutils/manual/html_node/Formatting-
file-timestamps.html)

~~~
masklinn
Sadly not supported by BSD ls.

~~~
fnj
True, but if you "pkg install gnuls" and set up an alias, you can get gnu ls
transparently.

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

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

~~~
prewett
In my case the problem is I'm running out of disk space and need to find stuff
to delete. So, `du -csh _`. Wow, three huge directories. `cd dir1; du -csh_ `.
Repeat. `du -d 3` would seem to be the solution, but it is pretty noisy. I
really want something that prints all the "big" stuff in a tree, nicely
indented and sorted by size. I end up using a KDE app ported to macOS that
shows all the big files in packed rectangles, but can't remember the name.

~~~
kbenson
What you're looking for is

    
    
      du -hc | sort -hn | tail
    

No need to visit subdirectories. Throw in a tee /tmp/du.out before the tail to
make your life easier.

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

Argh! I want to be able to say `ls --size` to get the file sizes. I don't want
to remember a million arguments.

~~~
solomatov
Completely agree. If the author wants it to be a better alternative to ls, it
should have better default. I.e. -bghHliS should be the default options.

~~~
Touche
I guess everyone has their preferences. exa -bghHliS is too much info for me.
I agree there should be a shorthand for "give me everything" though.

~~~
solomatov
Yes, it's probably too much. But what's shown by default is too little for me.

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

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

~~~
kowdermeister
I thought the same at first. ls is good mnemonic for list, but what exa stands
for and why three letters?

"gf" for example would be better. neighbor characters on the keyboard, could
stand for get files.

~~~
Denvercoder9
Furthermore, l and s are typed with different hands, which makes it quite fast
to type. Exa is all left-handed, so it takes even longer.

~~~
ordu
exa can be typed by using three different fingers. Its not any significantly
longer then ls which use two finger movement. Maybe even faster: I dont know
what science tells us about such motions, but at my opinion fingers of one
hand can be more precisely synchronized, so you really can do faster movements
and lower delays between keypresses. Just try to use fingers 2-1-4 (index
finger, than thumb, than ring finger) in that order, and you'll see. Or, when
typing exa as part of larger text, you can use 3-1-4 sequence of fingers it
allows to place palm in a way that allows fast movement into "exa" or out of
it, keeping index finger free.

~~~
mcbits
Is that how you actually type, or are you speculating? With regular home row
typing, e-x-a is 3-4-5, which are the hardest fingers to "drum", and even
harder on three different rows. I've tried micro-optimizing special cases like
this before, but then I have to think as much about typing as what I'm typing.
On the other hand, I know I've hit "sl" by mistake more than a few times.

~~~
ordu
> e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on
> three different rows.

Its because of the rules of blind typeing courses that says thumb should be
used only for space? If you got such a courses more than a year before and
already mastered blind typeing, than stop worrying. Just use thumb for `x`.

> I've tried micro-optimizing special cases like this before, but then I have
> to think as much about typing as what I'm typing.

It got better with practice. Like blind typeing. All you need is to train you
fingers for they do it without conscious effort of thinking. Are you play on
some musical instrument? Try it, it teaches how to train your fingers.

~~~
mcbits
My fingers are pretty well trained for typing - around 100 WPM, 120 on a good
day. As I say, I've tried tweaking my technique for special cases, but it just
makes typing more laborious for little or no gain.

It could be different for others. I saw a guy who could do 100 WPM with
literally two fingers, although it looked exhausting. A year of waking up with
my fingers locked, simultaneously numb and throbbing in pain, taught me that
maintaining a relaxed flow is more important than those last 10 WPM. But that
means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.

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

~~~
mmarx
> There's only one problem with this thing: all the characters are on one hand
> with a qwerty keyboard!

They are also all on the left hand in both Dvorak and Neo.

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

~~~
PaulHoule
My trouble is that most terminals have color settings such that colored text
is not very visible. I really wish I could have a large number of different-
colored terminals for different tasks, and that is easy if I turn off color,
as designing a whole color set that always works is a bigger job.

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.

~~~
vacri
Another tricky thing is finding a colour set that works against various
backgrounds. A ton of people use either black _or_ white backgrounds.
Occasionally you come across a different colour (eg: some people use red
backgrounds for 'root' or 'production'), but even if you exclude these folks,
getting something that works with both black and white backgrounds is a
minimum requirement.

------
assafmo
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)

~~~
erichurkman
Why does a directory lister need an HTTP parser?

~~~
steveklabnik
This binds to libgit2, which binds to curl. I believe that brings it in.

~~~
cytzol
You are correct. exa uses libgit2 for its Git column, and the library's
networking parts must still be included when they aren't even being used
anyway.

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.

~~~
kibwen
For more paranoid folks, it would be nice to have a configuration option to
forego the git features and thereby remove the need for linking in any
networking code. :)

~~~
steveklabnik
There is one already; it's a cargo feature.

~~~
Pewqazz
I wrote the original Homebrew formula for exa and remembered adding support
for the Git-less install, so I was surprised to see it wasn't there anymore!
Seems like it was removed in this version bump [1] — I'll open a PR adding it
back in.

[1]: [https://github.com/Homebrew/homebrew-
core/pull/13676](https://github.com/Homebrew/homebrew-core/pull/13676)

------
swift
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?)

~~~
hgdsraj
Yah there's git integration, re read site ctrl+f "git"

~~~
bowmessage
swift knows that. They're asking for an example of the output of exa in a git
repo.

------
pierrec
>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 _cough_ MacOS _cough_ )

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.

~~~
burntsushi
As a maintainer of a CLI program in Rust that runs on Windows, it is mostly a
pretty nice experience. The only painful part was getting colors working in
both MSYS terminals and cmd/PowerShell based terminals.

I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows
10 laptop to test on as well.

~~~
thecrazyone
You should probably write to exa developer, no? Perhaps, help out a fellow
tool developer to bring the goodness of your tools to us devs on Windows? :)

~~~
burntsushi
It's available as a library:
[https://docs.rs/termcolor/0.3.2/termcolor/](https://docs.rs/termcolor/0.3.2/termcolor/)

------
pbiggar
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`

~~~
cytzol
When I release a new version of exa, I upload the code and binaries to GitHub,
and then someone else whom I have never met but very much appreciate takes it
and publishes it to Homebrew, then a few days later I download and start using
it.

It's the slowest file copy mechanism I've ever used!

~~~
thecrazyone
You should buy that person a beer if you ever find out who it is.

Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll
Mr Hyde :)

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

~~~
twic
I have an unreasonable and unquenchable hatred for developers who assume that
their users have dark-background terminals. Honestly, the most insanely
passionate contempt.

~~~
cannam
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/](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.

~~~
fnj
> "human-readable" file sizes).

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.

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

~~~
cytzol
I wouldn't say it's bullshit, just a difference of opinion.

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.

~~~
flukus
> 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

I'd be willing to bet dynamic linking would get it much closer to that
ballpark and wouldn't compromise the feature set or development.

~~~
saagarjha
Dynamic linking to _what_ , though? The features you're looking for have to
available in a library for you to be able to link to it.

~~~
steveklabnik
The standard library for one; many C programs have libc dynamically linked.
Rust's stdlib isn't.

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

~~~
cytzol
I know the documentation is currently lacking -- I've been working on a better
website that explains all the options and colours for a while now. It should
be done Soon™

------
pmarreck
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!

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

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

~~~
zeptomu
Asking the important questions. Maybe exa could show a flying axe?

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

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

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

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

------
tym0
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](https://github.com/supercrabtree/k)

[2] [https://raw.githubusercontent.com/supercrabtree/k/gh-
pages/f...](https://raw.githubusercontent.com/supercrabtree/k/gh-pages/file-
size-colors.jpg)

~~~
cytzol
I've seen k before, it's pretty neat.

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](https://github.com/ogham/exa/issues/65))
used k as a direct example.

~~~
tym0
Nice, looking forward to the configurable colours, I feel when everything is
in bright colour it makes hierarchy much harder to read.

------
hepek
./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?

~~~
ktRolster
Is there a reason it has an http parser?

~~~
steveklabnik
[https://news.ycombinator.com/item?id=14924128](https://news.ycombinator.com/item?id=14924128)

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

~~~
cytzol
Yo. What's it display? Feel free to raise a bug if something doesn't look
right. I know it's not the fastest-moving open-source project, but I'll still
read everything that people submit.

~~~
Dowwie
the output is missing the git modification flags

issue:
[https://github.com/ogham/exa/issues/183](https://github.com/ogham/exa/issues/183)

------
sethammons
so... a mix up of the following:

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

tree -L 2

git diff --stat

git status

~~~
JustSomeNobody
But this is "Modern".

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

~~~
Karunamon
An alias in your favorite shell's .rc file solves the first problem. Better
yet, you can throw it behind a test block to ensure you never get a command
not found error:

    
    
        test -f /usr/bin/exa && alias ls='/usr/bin/exa'
    

The second problem is solved by configuration management tools pushing out
your desired tools to your entire environment.

~~~
mmirate
> configuration management tools

Which work well until your "entire environment" is some new-fangled
ARM/SuperH/(etc.) board, and your configuration management tool is x86_64-only
and/or not-in-the-repo of the only distro specialized enough to support that
new-fangled board.

------
steventhedev
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?

~~~
djm_
From the FAQ:

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

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

When its being used as part of a script.

~~~
icebraining
Parsing ls is a pain anyway, using "stat --printf=%s" is much better in
scripts, in my opinion.

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

------
yosoyalejandro
Very cool project, will replace ls for exa :)

------
h1d
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](https://news.ycombinator.com/item?id=3858954)

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

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

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

~~~
omribahumi
I guess that's because you can't resize columns interactively on the console,
and the other columns are relatively short (and pretty much static length).

It makes sense to list the filename last IMHO.

~~~
dmckeon
The file name (or entire path) should be where-ever the user expects to find
it. Having fixed width columns makes using sort(1) trivial.

For the "all the information" part, I've been using something like this:

    
    
      fn () { 
        find "${@:-.}" -printf "%TY %Tm %Td %TH:%TM:%2.2TS %1y %4m %3n %4U:%-3G %8s %p\n"; }

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

~~~
runeks

        #!/bin/bash
        alias lse = exa

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

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

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

------
baby
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?

------
TedHerman
Surprised no one has suggested replacing permissions display with emoticons.

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

~~~
cytzol
"Like an engineer deeply in tune with his machine, Exa feels the world's
component error deep in his bones, fractionally before anything has literally
gone wrong." — from Sam Hughes's Ra
([https://qntm.org/ra](https://qntm.org/ra))

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.

------
amelius
What is the usefulness/learning_effort ratio of this tool?

~~~
Touche
You can pretty much use it like ls for most things, so I'd say very little
investment needed.

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

------
gesman
$ exa -bghHliS ????

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

------
rv77ax
The last thing I want in terminal is colours.

------
polote
Why do you want to replace ls?

------
torus
Nice, I like the -T option.

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

~~~
ams6110
You could alias it to ls.

~~~
yAnonymous
Or e.

------
dan-compton
The name is too long.

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

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

------
Froyoh
Wow I’m quite overwhelmed by the colors

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

------
git-pull
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](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](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](https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1)):

[1] [http://www.jedsoft.org/most/](http://www.jedsoft.org/most/)

[2] [https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-
read-t...](https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-the-
tmux-manual-in-style)

~~~
lobster_johnson
It's not overriding anything, so you're ranting against a faulty premise. The
command is called "exa", not "ls", and it isn't even a drop-in replacement --
it doesn't have the same flags. You can't alias "ls" to it.

~~~
git-pull
I don't see it that way.

The focus over the qualifier of whether it's "drop-in" misses the point. How
else are people going to interpret and use "a modern replacement for ls", in
practice?

Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in
as "ls" _in front_ of /bin/ls in their shell for convenience.

~~~
lobster_johnson
So? Nobody is going to use this to replace "ls" in scripts. Are you really
arguing against the creation of competing tools? "ack" shouldn't exist because
"grep" already exists? "htop" shouldn't exist because there's "top"?

~~~
git-pull
Correct, you don't need this tool.

Put it this way: Think of it like a Socratic dialog. Just because a
replacement for ls(1) may not be beneficial due to configuration and
customization already being commonplace, isn't the same as saying the mere
notion of a competing unix CLI tool is bad.

top(1) doesn't allow color configuration. I use htop(1), and like it.

ls(1) already has color customization via LS_COLORS and long-list format via
-l in ls. And about 10+ other output options. It's quite flexible.

git status can be shown via `git status`, and via the PS1 in oh-my-zsh/pure.

> Nobody is going to use this to replace "ls" in scripts.

I'm concerned they will, and not recognize it. To beginner and novice shell
users, it's easier to cargo cult stuff in and not know what's happening. And
things will break in ways that's a nightmare for them to troubleshoot.

My gut instinct is being verified by comments in this thread mentioning
alias'ing in exa as ls.

~~~
chris_wot
If anyone is silly enough to alias to exa, then their scripts will fail. A
replacement doesn't have to be a drop in. Server admins who alias it will pay
the price, so they won't do it.

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

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

~~~
steveklabnik
It uses libgit2 for this; I don't know what specific attack vector you're
thinking about though.

~~~
lima
Git's on disk format has a massive attack surface.

Do not run "git" in untrusted directories. It is not hardened against that (as
opposed to the network protocol).

That probably includes libgit2 unless it explicitly states the opposite.

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

21214836 .rw-r--r-- 1 9.4Ki 24 ben staff 29 Jun 16:16 Cargo.lock

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

~~~
yAnonymous
It's much easier to deal with line breaks. File names first would break the
entire layout when one of them is too long.

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.

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

~~~
fnj
No idea on earth why you are downvoted. My sympathies for your challenged
vision. Your objection is well founded, and your suggestion has merit.

~~~
yAnonymous
Judging the use of colors in software as a colorblind person is like rating
shoes when you have no legs. He's coming across whiny and pretentious.

Sorry it doesn't work for him, but colors are generally useful when working
with lots of text.

