Exa - A Modern Replacement for ls(the.exa.website)
the.exa.website
Exa - A Modern Replacement for ls
https://the.exa.website/
154 comments
That is not at all the behavior that I am observing on my system:
"time command ls -lR -color=always": 898 millis
"time command exa -lhgR --icons": 638 millis
This is in a directory of roughly 17k files of varying filetypes. Exa also outputs underlines and icons.
---
Admittedly if I create 80000 arbitrary extensionless files "ls" takes around 700 millis while exa takes around 1000 millis, but still the performance difference is nowhere near what you demonstrated.
I don't know what job you're doing that requires "ls"-ing >20k files, but on my system there seems to be no performance penalty before an uncertain, unachievable threshold.
"time command ls -lR -color=always": 898 millis
"time command exa -lhgR --icons": 638 millis
This is in a directory of roughly 17k files of varying filetypes. Exa also outputs underlines and icons.
---
Admittedly if I create 80000 arbitrary extensionless files "ls" takes around 700 millis while exa takes around 1000 millis, but still the performance difference is nowhere near what you demonstrated.
I don't know what job you're doing that requires "ls"-ing >20k files, but on my system there seems to be no performance penalty before an uncertain, unachievable threshold.
The stat() results are going to be cached.
What is fair for a test like this? SSD or rotational media?
At least clear the caches between runs, or give them the same cache.
https://www.thegeekdiary.com/how-to-clear-the-buffer-pagecac...
What is fair for a test like this? SSD or rotational media?
At least clear the caches between runs, or give them the same cache.
https://www.thegeekdiary.com/how-to-clear-the-buffer-pagecac...
Okay, updated results (cleared all the caches and restarted shell/terminal between runs):
"time command ls -lR --color=always": 12.31 secs
"time command exa -lgR --icons": 11.32 secs
Still, no performance difference on my system. In fact exa seems to be slightly faster (I did the test multiple times and it was alwasy ~1 second faster). This is on a physical HDD and I could hear it churning equivalently on both of the runs.
"time command ls -lR --color=always": 12.31 secs
"time command exa -lgR --icons": 11.32 secs
Still, no performance difference on my system. In fact exa seems to be slightly faster (I did the test multiple times and it was alwasy ~1 second faster). This is on a physical HDD and I could hear it churning equivalently on both of the runs.
The fair test is the hardware you’re going to be running it on
I'd say this is a situation where you should use a tool that's appropriate for the job.
Listing 70k files without greping or piping into another process is something you are probably not going to ever do. exa seems very good for the average case.
Listing 70k files without greping or piping into another process is something you are probably not going to ever do. exa seems very good for the average case.
I'm not sure I'm following. Listing 70k files was a benchmark. It would take you 10x the time to use 'exa | grep' but grep might just filter out the item you're looking for during execution (not certain if grep is reading the pipe as it is output or waits for execution to complete first). exa still needs 7 seconds to check all files. ls only needed a tenth of that
The point is that exa is a tool for listing files in a more human readable way. In what situation would you ever need to manually read (with your eyes) a list of 70k files? For this use case you should just use ls.
I'm saying you would use `ls | grep ...` in situations where you're transforming the output but use `exa` when you specifically care about the files or their metadata.
That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.
That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.
> (not certain if grep is reading the pipe as it is output or waits for execution to complete first)
Commands to the left of the pipe block upon writing to the pipe, and commands to the right of the pipe block upon reading. As something is written to the pipe, it gets read by the next process in the pipeline.
Data flows through Unix pipelines as it is written, and data flow is not dependent on completed execution.
Commands to the left of the pipe block upon writing to the pipe, and commands to the right of the pipe block upon reading. As something is written to the pipe, it gets read by the next process in the pipeline.
Data flows through Unix pipelines as it is written, and data flow is not dependent on completed execution.
Wow. This is very slow. If the only feature here is that it supports colors (so does ls, by the way) or extra information (so does ls, by the way), all while being much slower, then I do not see the point in replacing ls with this.
Someone mentioned that you can just do:
Someone mentioned that you can just do:
alias ll='ls -lahF --color=auto'exa does (or can do) more than that. Git information, for example; and more fine-grained output control.
Does the slowness really matter for most use cases though?
Yes, it matters a lot. These tools are supposed to be fast. I use them all the time, and if there is a tool that does the same but one takes 1 sec and the other one takes 30 seconds, then of course I am going to pick the faster one.
>Yes, it matters a lot.
No, not at all.
>These tools are supposed to be fast.
And they are. Just not faster than ls, which is already fast itself.
>I use them all the time, and if there is a tool that does the same but one takes 1 sec and the other one takes 30 seconds, then of course I am going to pick the faster one.
Only if it matters.
If it takes 200ms and the other 250ms nobody's going to care. Especially if the second tool does more, and especially if the use case is "listing of regular dirs where better human-readability matters" (not 20K+ file dirs).
The same way we also program Python or JS or Lisp and not just C and Rust, even though the latter are faster.
No, not at all.
>These tools are supposed to be fast.
And they are. Just not faster than ls, which is already fast itself.
>I use them all the time, and if there is a tool that does the same but one takes 1 sec and the other one takes 30 seconds, then of course I am going to pick the faster one.
Only if it matters.
If it takes 200ms and the other 250ms nobody's going to care. Especially if the second tool does more, and especially if the use case is "listing of regular dirs where better human-readability matters" (not 20K+ file dirs).
The same way we also program Python or JS or Lisp and not just C and Rust, even though the latter are faster.
Yes, it matters to me because I use it often, and many directories have lots of files in them.
I do not care if the difference is 200 ms vs 250 ms, but if it is 1 sec vs 10 seconds, then yeah, it is a deal-breaker.
I did not try exa, so I cannot speak against it, nor in favor of it. It would only be fair if I used it and noticed that there are significant performance issues with it.
I do not care if the difference is 200 ms vs 250 ms, but if it is 1 sec vs 10 seconds, then yeah, it is a deal-breaker.
I did not try exa, so I cannot speak against it, nor in favor of it. It would only be fair if I used it and noticed that there are significant performance issues with it.
I don't think anyone would use a tool if it were 180x slower than the alternative. I strongly doubt that's the case here.
(to clarify the "180x" math: (10s - 1s) / (250ms - 200ms) = 9s / 50ms = 180)
(to clarify the "180x" math: (10s - 1s) / (250ms - 200ms) = 9s / 50ms = 180)
I only took a quick glance at the OP's https://asciinema.org stuff. Exa seemed way slower in comparison to ls. Again, I would have to test it myself and see how much it affects me if at all. That said, I do not see a reason to switch to it because ls supports colors as well, and I do not need the added extra information. Welp.
I do as well, but I guess none of my use cases have involved either listing absurd amounts of files nor have I used ls or exa in any scripts. I do use exa and ls (usually on systems where I don't have exa installed or when I forget to type "sl" instead)
The difference has been barely noticeable for me
From what I have read here, it diesnt look loke anyone dislikes exa. The only thing I'd change is the messaging.
Instead of saying modern replacement to ls, I'd rather we be more specific and say "a modern replacement to ls for some interactive workloads" or something like that. This makes it clear that the ask is not that we remove the ls binary and put exa alias.
Instead of saying modern replacement to ls, I'd rather we be more specific and say "a modern replacement to ls for some interactive workloads" or something like that. This makes it clear that the ask is not that we remove the ls binary and put exa alias.
I've been using exa for the better part of a decade and never noticed any delay whatsoever.
I suppose it depends on a person and situation. Significant amount of my lists end up an overfull directory of logs or traces or whatevers. Basic utilities used daily (hourly? Minutely?) need every inch of speed eeked out.
Many of the interactive tools you use are bash scripts so I seriously doubt that the above benchmark is meaningful for normal use cases. Whether you see that 4 files in 0.01 or 0.05s is basically the exact same and this wait time doesn’t accumulate.
Helper scripts using ls can involve lots of items and recursion, so the slowness can go exponential. A serious replacement candidate needs to be as fast or faster.
Maybe a performance based execution of exa could be crafted that ignores some of the eye candy or whatever is sucking up the cycles.
Maybe a performance based execution of exa could be crafted that ignores some of the eye candy or whatever is sucking up the cycles.
>Helper scripts using ls can involve lots of items and recursion, so the slowness can go exponential.
It can't go exponential. Recursion or not, you did N passes with ls, and you'll do N passes with exa.
Unless exa is exponentially (not by a linear factor) slower than ls, the slowness can't go exponential.
It can't go exponential. Recursion or not, you did N passes with ls, and you'll do N passes with exa.
Unless exa is exponentially (not by a linear factor) slower than ls, the slowness can't go exponential.
Scripts using ls should keep using ls whatever you use for interactive use. Though more often than not such scripts ought to use something else like find to begin with.
Even the most strident fans of exa wouldn't advocate replacing ls with exa. We just set it as an alias which won't affect script execution.
No it doesn't but you will get people who like to nitpick speed and forget about all the other advantages that other users find useful and appreciate them. Most people will never notice the speed difference.
ls is probably one of the most used command line utilities, up there with `cd` and `echo`. It will be very easy to notice performance degradation.
I find comments like "I've been using <the tool> forever and never noticed <this> problem" a little annoying. But, I fall into this camp here. I'm not trying to dismiss other people's criticism that the slowness has had a negative effect on their workflow. But, here it goes, I use exa as my ls replacement and I've never even noticed it was slow. And, for me, the chief value really comes down to exa's color coding of results. It helps me see the information more easily which I feel has a cumulative effect of speeding up my workflow.
That does seem rather bad, I wonder what is causing such shitty performance?
From the documentation
> Here’s an example. exa, by default, runs the stat system call on every file it encounters. This requires communicating with the storage device or hard disk to get that file’s type and permissions, which determine how that file gets coloured and displayed on screen. The system call, which may have been expensive in the days of time-shared computers and slow connections, is still not free, but is extremely cheap. The extra information is worth the minuscule increase in processing time.
For 100% - ~3 use cases the performance difference does nit matter as a human is unable to react in milliseconds. You can always fallback to ls.
> Here’s an example. exa, by default, runs the stat system call on every file it encounters. This requires communicating with the storage device or hard disk to get that file’s type and permissions, which determine how that file gets coloured and displayed on screen. The system call, which may have been expensive in the days of time-shared computers and slow connections, is still not free, but is extremely cheap. The extra information is worth the minuscule increase in processing time.
For 100% - ~3 use cases the performance difference does nit matter as a human is unable to react in milliseconds. You can always fallback to ls.
But you have to run stat to get the details, like permissions, dates and size, whether your name is "exa" or "ls".
[deleted]
I'm willing to bet it's the fact that they're in a git repo. exa checks git status iirc, and of course ls doesn't. I'll try to repro it.
Edit:
Hmm, interesting. Certainly a lot slower, but not enough that I'd really notice unless I was doing this constantly:
time ls
real 0m0.228s
user 0m0.145s
sys 0m0.082s
time exa
real 0m1.209s
user 0m1.124s
sys 0m0.084s
Edit:
Hmm, interesting. Certainly a lot slower, but not enough that I'd really notice unless I was doing this constantly:
time ls
real 0m0.228s
user 0m0.145s
sys 0m0.082s
time exa
real 0m1.209s
user 0m1.124s
sys 0m0.084s
Yeah at first I thought maybe the git feature but in the demo they're not passing --git. See also:
https://github.com/ogham/exa/issues/367#issuecomment-4285909...
ls taking seconds and exa taking 13 minutes :(
Their website says it's as fast as ls because they do things in parallel but it doesn't seem to actually be as fast as ls in small or large usage.
I'd also say 200ms -> 1.2 seconds is very noticable.
ls taking seconds and exa taking 13 minutes :(
Their website says it's as fast as ls because they do things in parallel but it doesn't seem to actually be as fast as ls in small or large usage.
I'd also say 200ms -> 1.2 seconds is very noticable.
Based on perf report, the latest stable version of exa is spending >99% of its time doing grid stuff. I pulled the repo from git, and using the latest master commit, it appears to have a huristic to not bother with the grid when you have lots of files. Now the times are a lot closer. (redirected stdout to /dev/null since otherwise the vast majority of the time would simply be outputting to the shell)
[user@anarchy:~/exa_test]$ time ../exa/target/release/exa >/dev/null
../exa/target/release/exa > /dev/null 0.05s user 0.07s system 99% cpu 0.122 total
[user@anarchy:~/exa_test]$ time /bin/ls >/dev/null
/bin/ls > /dev/null 0.03s user 0.01s system 99% cpu 0.048 totalExa does colors and other stuff by default. I would wager it’s stat()ing every file and ls isn’t.
>I'd also say 200ms -> 1.2 seconds is very noticable.
One of those things that if I'm looking for it, I'd notice but otherwise...
I deal with so many slow CLI tools daily that it wouldn't even register.
One of those things that if I'm looking for it, I'd notice but otherwise...
I deal with so many slow CLI tools daily that it wouldn't even register.
There seem to be an issue reported about this (although when passing -l): https://github.com/ogham/exa/issues/141
I once experimented with a design that ended up with 30,000 files in a single directory. (It was a dumb experiment.)
I discovered that the ls I as using used a polynomial-time algorithm for sorting the output. Like, it would lock up the machine for ten minutes... Told ls not to sort, and boom... fast.
This was almost 20 years ago. And I don't recall if it was GNU ls or FreeBSD.
There may be some performance improvement opportunities out there for exa.
I discovered that the ls I as using used a polynomial-time algorithm for sorting the output. Like, it would lock up the machine for ten minutes... Told ls not to sort, and boom... fast.
This was almost 20 years ago. And I don't recall if it was GNU ls or FreeBSD.
There may be some performance improvement opportunities out there for exa.
[deleted]
For a counter anecdote, I've been using it for years on a few systems and never had any speed issues at all.
A lot of people will time things down to the microsecond and complain about a 0.1% difference and proclaim "this tool is garbage". I expect that sort of thing on reddit but not on HN.
the --tree feature is incredibly slow
Comparing tree to exa --tree, they're not that different in total runtime, it's just that exa doesn't print till it's done while tree prints as it goes and it feels so much worse (to use exa)
Non-positive opinion ahead.
Personally I can’t find a use for it. Colors are so vast that I can’t figure out which means what (and they rarely play nice with a custom bg color). And then, all I have to know is whether a file is “->”, “*”, “/“ or “”. Tree+git view could be useful, if not node_modules, .git and other tree spammers. Of course there is an option to ignore, but then my .bashrc grows again while all I need in a project dir is covered by git status -s (yes I can read these capital letters since svn).
It is modern in a sense of presentation, and I see how it may appeal to someone, but not in a sense of ls being old or something. It feels to me like a strange tool that does everything but nothing specifically, as if someone always wanted a nice gui file explorer, but had no courage to admit this “lameness”.
Why spend your time squinting at black and white text?*
I usually spend time on colored output trying to read blue/lightgreen/etc on #444, and because my b/w tools are separated by colored PS1, which emphasizes important* things like hostname, user, cwd, exitcode and puts a newline so that each command is lined up and ends with an additional \n. File being a green file or a blue dir is not as important as me patching a wrong instance.
Personally I can’t find a use for it. Colors are so vast that I can’t figure out which means what (and they rarely play nice with a custom bg color). And then, all I have to know is whether a file is “->”, “*”, “/“ or “”. Tree+git view could be useful, if not node_modules, .git and other tree spammers. Of course there is an option to ignore, but then my .bashrc grows again while all I need in a project dir is covered by git status -s (yes I can read these capital letters since svn).
It is modern in a sense of presentation, and I see how it may appeal to someone, but not in a sense of ls being old or something. It feels to me like a strange tool that does everything but nothing specifically, as if someone always wanted a nice gui file explorer, but had no courage to admit this “lameness”.
Why spend your time squinting at black and white text?*
I usually spend time on colored output trying to read blue/lightgreen/etc on #444, and because my b/w tools are separated by colored PS1, which emphasizes important* things like hostname, user, cwd, exitcode and puts a newline so that each command is lined up and ends with an additional \n. File being a green file or a blue dir is not as important as me patching a wrong instance.
I'm going to tack on my non-positive and potentially nonconstructive opinion here.
This is absolutely frivolous and a problem looking for a solution. It _is_ a modern replacement for `ls` in that it fulfills the creator's aesthetic desires for the program and solves none of the issues present with the original (in which there are close to zero).
This is absolutely frivolous and a problem looking for a solution. It _is_ a modern replacement for `ls` in that it fulfills the creator's aesthetic desires for the program and solves none of the issues present with the original (in which there are close to zero).
>problem looking for a solution
solution looking for a problem
solution looking for a problem
I always find pitches like this a little obnoxious:
> You list files hundreds of times a day. Why spend your time squinting at black and white text?
Uh, `ls` has colors, if you know how or some benevolent distro-maintainer did.
Now there's a ton of value in sane defaults and cutting out cruft and targeting specific use-cases, so not here to criticize the tool, at all. Just the marketing. Why not talk about what's actually special and different about it?
> You list files hundreds of times a day. Why spend your time squinting at black and white text?
Uh, `ls` has colors, if you know how or some benevolent distro-maintainer did.
Now there's a ton of value in sane defaults and cutting out cruft and targeting specific use-cases, so not here to criticize the tool, at all. Just the marketing. Why not talk about what's actually special and different about it?
When the motivation about replacing something is just colors/icons and other fluff, I just don't consider the tool worth it.
Also, changing default tools are fine for a single system, but when you're managing many, and with a team, that's a big no no.
Also, changing default tools are fine for a single system, but when you're managing many, and with a team, that's a big no no.
I actually prefer my ls output to be monochrome, and the first time I encountered a coloured one I turned it off since some of the colours were nearly unreadable (who thought dark blue and gray on black was a good idea?)
That’s not ls’s fault. That’s just your terminal's colour scheme.
Thanks for writing the bulk of my comment for me. :)
The thing I would add is that tools like this cater to introductory users, not power users. They're for the person who tweaks every cosmetic default to the point where they need a setup of "dotfiles" to be functional.
Meanwhile, tools like this often skip over important implementation details like extended file-system attributes.
The thing I would add is that tools like this cater to introductory users, not power users. They're for the person who tweaks every cosmetic default to the point where they need a setup of "dotfiles" to be functional.
Meanwhile, tools like this often skip over important implementation details like extended file-system attributes.
There is a cohort of “replacements” to traditional tools.
Check here: https://github.com/ibraheemdev/modern-unix
Some of them are great, some are opinionated.
Check here: https://github.com/ibraheemdev/modern-unix
Some of them are great, some are opinionated.
I wrote an interactive sed replacement: https://github.com/typon/tabdeeli
Both exa and lsd[1] are amazing ls replacements. I personally stuck with lsd as it was easier to alias to ls but great work by exa.
1. https://github.com/Peltoche/lsd
1. https://github.com/Peltoche/lsd
I prefer lsd over exa because the flags are more compatible with standard ls
Agreed. I gave up on exa because `ls -tr` doesn’t work.
You mean like this? https://i.imgur.com/g4hl1Rg.png
alias ls="exa -h --group-directories-first --icons -g $@ --git --color always"
alias ls="exa -h --group-directories-first --icons -g $@ --git --color always"
That seems different than sorting by time?
My minor exa gripe is described here: https://github.com/ogham/exa/issues/519
Lots of workarounds, even more available now, but I ended up switching to lsd and love it. I like the file type icons.
My minor exa gripe is described here: https://github.com/ogham/exa/issues/519
Lots of workarounds, even more available now, but I ended up switching to lsd and love it. I like the file type icons.
I think that's what OP means by “easier to alias”
I tried both and ended up with lsd, but both have my favourite feature which is the icons via Nerd Fonts.
This looks great, I submitted a feature request to also show permissions in Octal, which is one of the 'missing features' I've always considered to be present in ls.
It's always bugged me that chmod takes octal, but all of the other tools output a more human readable format, and its up to me to do the mental math in my head to convert - I dont know about you, but I'm bad at doing octal in my head ;-)
It's always bugged me that chmod takes octal, but all of the other tools output a more human readable format, and its up to me to do the mental math in my head to convert - I dont know about you, but I'm bad at doing octal in my head ;-)
I may just work with file permissions more than most, but I prefer the octal for its density. It's easy to tell my coworker the permissions are wrong, it should be 755 not 644. It's a lot harder to convey that they should be rwxr-xr-x instead of rw-r--r--.
I also find diffing easier. 767 is different from 777, which is easy to see. It's harder to scroll in ls and find the one that's rwxrw-rwx rather than rwxrwxrwx.
The last one is that the human format is legitimately awful at calling out setuid/setgid, and those are really important to notice. How many people are going to notice that 'rwxr-sr-x' is different than 'rwxr-xr-x'? The equivalent octal is 2755, which is very noticeably different from 755 (or 0755 if you prefer).
I'm not opposed to having the option, but I do think there are advantages to octal. Those advantages do probably wane if you don't have to deal with some of the more arcane permission sets.
I also find diffing easier. 767 is different from 777, which is easy to see. It's harder to scroll in ls and find the one that's rwxrw-rwx rather than rwxrwxrwx.
The last one is that the human format is legitimately awful at calling out setuid/setgid, and those are really important to notice. How many people are going to notice that 'rwxr-sr-x' is different than 'rwxr-xr-x'? The equivalent octal is 2755, which is very noticeably different from 755 (or 0755 if you prefer).
I'm not opposed to having the option, but I do think there are advantages to octal. Those advantages do probably wane if you don't have to deal with some of the more arcane permission sets.
I agree, broadly. I'd rather have the option to have both if I could pick.
One octal digit comprises three bits: read, write and execute, with values 4, 2, and 1. Add them and you get the octal digit: 7 is everything permitted, 4 is read-only. The three octal digits represent permission for owner, group and the rest. So stay way from 777.
I set permissions on something just infrequently enough that I dont have that as muscle memory, and often I need to match permissions on something already there, so I'm trying to go "uhhh, its, rwxr-xr-x what does that translate to again?"
Also, frankly, the computer is a calculator, why not have it act as the calculator for me, and tell me what the permissions already are, I can read the octal permissions and know what they mean.
Also, frankly, the computer is a calculator, why not have it act as the calculator for me, and tell me what the permissions already are, I can read the octal permissions and know what they mean.
chmod --reference=file_with_permissions_i_want.txt file_whose_permissions_i_want_To_change.txt
They're bits, in groups of three. rwxr-xrwx would be "111, 101, 111", so 7, 5, 7.
I may be odd, but I don't find reading "small numbers" in binary to be much harder than reading "small numbers" in decimal, or hex. Up to about 15-or-so... Maybe as far as 31.
But get to six bits, and it's time to actually start doing multiplications and additions, for me.
I may be odd, but I don't find reading "small numbers" in binary to be much harder than reading "small numbers" in decimal, or hex. Up to about 15-or-so... Maybe as far as 31.
But get to six bits, and it's time to actually start doing multiplications and additions, for me.
[deleted]
My chmod usage generally looks like this:
chmod a-rwx,u+rw,g+r,o+r filename
a/u/g/o is all, user, group, other. - removes, + adds. r/w/x is read, write, execute (of course).
chmod a-rwx,u+rw,g+r,o+r filename
a/u/g/o is all, user, group, other. - removes, + adds. r/w/x is read, write, execute (of course).
That’s what GUIs are for, this exact use case.
The sibling with the reference param is a great option as well, if you can remember it.
The sibling with the reference param is a great option as well, if you can remember it.
once — exactly once — i heard from down the hall in the dorm “oh fuck this, file permissions are bullshit it’s a single user machine! i’m going to chmod -R 777 / and be done with it”
(clicking and the whack of an enter key)
(time passes)
“oh what th… oh, fuck ME!”
(clicking and the whack of an enter key)
(time passes)
“oh what th… oh, fuck ME!”
I use the idea of the binary numbers from 1 to 7 as an aide memoire:
1 001
2 010
3 011 --> -wx
4 100
5 101
6 110
7 111
rwx
1 001
2 010
3 011 --> -wx
4 100
5 101
6 110
7 111
chmod also takes human readable notation as input, as in
chmod g+w,o-rx …Pro tip: if you use fish, don’t alias ls=exa, instead set an abbreviation (abbr). This way you can keep typing ls at the command line and it will turn into exa, but it won’t interfere with other functions.
I’m not sure if there’s an equivalent for bash/zsh.
I’m not sure if there’s an equivalent for bash/zsh.
The tree feature itself is worth it: https://the.exa.website/features/tree-view
I always install tree on a new nix machine, might try this one out.
I always install tree on a new nix machine, might try this one out.
What about a tree which automatically fills the available height of the console, while staying balance ? Look at https://dystroy.org/broot/tricks/
Wow, I haven't heard of this one, thanks for the suggestion gonna try this out tomorrow. I usually pipe to less but this could be nicer.
It's the tree feature that made me investigate the speed of exa (see my other comment in this thread) because it was very slow. Otherwise I agree, exa is neat.
<<exa queries files in parallel, giving you performance on par with ls.>>
I think that this is bullshit! Maybe the author thinks that it is really the case, probably tricked by the language, because using async, but in the end, the syscall to read folders is synchronous...
I think that this is bullshit! Maybe the author thinks that it is really the case, probably tricked by the language, because using async, but in the end, the syscall to read folders is synchronous...
The syscall to list a directory is synchronous, but the follow-up stat calls to read file attributes (type, permission, attributes, size) are done one file at a time, so there are opportunities for parallelization.
Incidentally, this is why ls without colors or type symbols (-l, -F, --color, and so forth) is a lot faster: it doesn't have to query every file to find out what it is in order to display the color/symbol/permissions/etc. Handy if you're on a slow networked file system and just need to see names.
Incidentally, this is why ls without colors or type symbols (-l, -F, --color, and so forth) is a lot faster: it doesn't have to query every file to find out what it is in order to display the color/symbol/permissions/etc. Handy if you're on a slow networked file system and just need to see names.
It would be better if it used fstatat instead of regular stat calls. On a deeply nested directory it can make a difference (e.g. a single-threaded 'find' easily beats a parallel 'fd' with warm caches on my machine, 'exa' could similarly benefit)
> but the follow-up stat calls to read file attributes (type, permission, attributes, size) are done one file at a time, so there are opportunities for parallelization.
You may expect so but this is usually not the case. Multiple threads submitting stat or other fs ioctl commands to the disk driver are going to be sequenced and may not be threaded.
This is definitely how it works on Windows. Linux is better, but a lot of disk IO is behind the times. io_uring only has read/write so far.
You may expect so but this is usually not the case. Multiple threads submitting stat or other fs ioctl commands to the disk driver are going to be sequenced and may not be threaded.
This is definitely how it works on Windows. Linux is better, but a lot of disk IO is behind the times. io_uring only has read/write so far.
I don't see how parallelism could work with stat() in general, since the OS has to keep the FS structures consistent and ultimately there is only one disk to read from, unless you have RAID.
Filling the disk queue usually helps with the IO throughout part, sequential stats not attempting to queue requests will never saturate the bandwidth of a modern device.
There's also the page cache involved for reads, so it can be read while actual IO is queued.
There's also the page cache involved for reads, so it can be read while actual IO is queued.
Depends how much of the overhead is context switches vs. the disk IO. Really something that needs benchmarking.
It's not reading the folders that is the main slowdown in ls (and exa and similar) for more complex lists, but all the extra work done per file.
ls and similar can (and do) requests the files in batches, so if the directory has enough files for speed to matter you can request one and then asynchronously query whatever additional information you need.
If you only want the filename and whether it's a directory, device or file, then you won't do much better than ls, but you also likely won't do much worse.
But the moment you want e.g. filesize you need to stat() files. That too will be the same whether or not it's ls. But exa also does things like check git and that will add significant overhead that they may or may not alleviate by doing it in parallel.
ls and similar can (and do) requests the files in batches, so if the directory has enough files for speed to matter you can request one and then asynchronously query whatever additional information you need.
If you only want the filename and whether it's a directory, device or file, then you won't do much better than ls, but you also likely won't do much worse.
But the moment you want e.g. filesize you need to stat() files. That too will be the same whether or not it's ls. But exa also does things like check git and that will add significant overhead that they may or may not alleviate by doing it in parallel.
Similarly, i'm really enjoying broot recently, which isn't quite just a replacement of ls which I still use, but it's a great way of getting directory listings / file listings in one shot, and to be able to launch other stuff form there.
I used to use nerdtree in vim, now I just launch vim from broot, which feels like the right way around, because I can use broot for lots of different things.
I looks like exa has more colour capabilities though.
I used to use nerdtree in vim, now I just launch vim from broot, which feels like the right way around, because I can use broot for lots of different things.
I looks like exa has more colour capabilities though.
I think that fuzzy finding is a much better way to open files than browsing a directory tree.
fzf is an amazing tool for this.
fzf is an amazing tool for this.
if some color and additional hints is all you need, this may be a competitor:
alias ll='ls -lahF --color=auto'
alias ll='ls -lahF --color=auto'
This is the first alias I create on any os I use daily.
Although I order the switches as `halF` as it's easier to remember for quick one-off use on servers (and containers). It's practically muscle memory for me now.
Although I order the switches as `halF` as it's easier to remember for quick one-off use on servers (and containers). It's practically muscle memory for me now.
I must be one of the few, but I rarely like color output. And then some throw in underline or bold, but in e.g. ls (or exa) almost none of the make-up adds information, yet everything shouts for attention. I turn most of it off, rather than on.
I think the most important feature of `exa` is not what additional information it could show, but rather what it does not show. It makes moden ergonomic choices presenting directory information using omissions, abbreviations, and colours.
If all the coreutils on Linux and Mac had color coding and used more “sane defaults”… I’d be so happy.
I find that if there is even a hint of latency with these types of tools it puts me in a foul mood
It's always nice to have more alternatives to traditional unix tools/commands, especially these new tools written in Rust that are popping up.
The website claims exa is a "modern replacement for ls", but unlike ls it doesn't seem to follow the "do one thing" unix concept - the git integration is one reason why. I'm not sure the git integration is a good idea.
The website claims exa is a "modern replacement for ls", but unlike ls it doesn't seem to follow the "do one thing" unix concept - the git integration is one reason why. I'm not sure the git integration is a good idea.
Does ls really follow the unix philosophy though? GNU ls can show file permissions, modification timestamp, author, size, sort the listing etc. It does a lot more than a simple directory listing. We've just gotten used to its current extra functionality.
File permissions, inode number, dates associated with a file are all features of the files, and it's natural to be a part of a directory/file lister.
One can always create separate tools for all the extra functionality in ls, however without the file name, associating all the information would be hard, so if these properties need a file name to be meaningful, why not add it into a single tool?
It's not like ls is changing group/owner, mode, or modifying timestamps or doing filesystem dependent things. It just lists files, with a bunch of extra information, if you want.
One can always create separate tools for all the extra functionality in ls, however without the file name, associating all the information would be hard, so if these properties need a file name to be meaningful, why not add it into a single tool?
It's not like ls is changing group/owner, mode, or modifying timestamps or doing filesystem dependent things. It just lists files, with a bunch of extra information, if you want.
File permission, timestamps and other stuff are things that a directory listing program should show you.
Regarding sorting, one can say that you can pipe the output to sort. True, but less efficient. Most filesystem implementation already give you the directory listing sorted in alphabetical order. So ls can be aware of that cases and simply give you the sorted list as returned by the operating system, in case one of that filesystem is used, without wasting time sorting an already sorted list.
Regarding sorting, one can say that you can pipe the output to sort. True, but less efficient. Most filesystem implementation already give you the directory listing sorted in alphabetical order. So ls can be aware of that cases and simply give you the sorted list as returned by the operating system, in case one of that filesystem is used, without wasting time sorting an already sorted list.
Sorted in _some_ order that may be similar to that of the current locale, but isn’t necessarily exactly the same.
I think it is highly likely they will be somewhat different because file systems that order directory entries alphabetically (1) either
- can’t keep track of Unicode version updates (if they did, old disks could end up having entries stored out of order), so they have to guess how entries for Unicode code points assigned at some future time will sort. I don’t think that can be reliably done.
or
- have to store some data on disk to tell users what the ordering is (original Mac HFS did something like that by storing the code page to be used to interpret the byte sequences of file names as characters on disk). That would mean ls would have to get that data from disk, and only if it matches the current locale, could skip the sorting step.
There also is the risk of bugs in the implementation that can’t be fixed once millions of disks exist (the original Apple HFS file system had a bug there).
There’s also the possibility of traversing mount points during a recursive ls or even of union mounts (https://en.wikipedia.org/wiki/Union_mount) during non-recursive listings, which means the on-disk order can change during listing.
⇒ I doubt ls uses this trick (I haven’t checked any ls sources, though, so corrections welcome)
(1) that in itself is a weird idea, as, on Unix, file names are byte sequences, not character strings. That’s a different subject, though.
I think it is highly likely they will be somewhat different because file systems that order directory entries alphabetically (1) either
- can’t keep track of Unicode version updates (if they did, old disks could end up having entries stored out of order), so they have to guess how entries for Unicode code points assigned at some future time will sort. I don’t think that can be reliably done.
or
- have to store some data on disk to tell users what the ordering is (original Mac HFS did something like that by storing the code page to be used to interpret the byte sequences of file names as characters on disk). That would mean ls would have to get that data from disk, and only if it matches the current locale, could skip the sorting step.
There also is the risk of bugs in the implementation that can’t be fixed once millions of disks exist (the original Apple HFS file system had a bug there).
There’s also the possibility of traversing mount points during a recursive ls or even of union mounts (https://en.wikipedia.org/wiki/Union_mount) during non-recursive listings, which means the on-disk order can change during listing.
⇒ I doubt ls uses this trick (I haven’t checked any ls sources, though, so corrections welcome)
(1) that in itself is a weird idea, as, on Unix, file names are byte sequences, not character strings. That’s a different subject, though.
Of course with alphabetical I really meant in the order considering the name as a byte string (that is what every UNIX filesystem does), that is if you use characters that fit in the ASCII table is alphabetical (well, not really since capital letters come first).
You can get all that info with a single stat() syscall. Looking into git for more info, is significantly more complicated.
IDE file trees these days often show git status. Why not terminal file lists?
The problem with “don’t do that” is you can’t add it on after the fact using another tool, like you can with e.g. sorting. You have to run a separate command and correlate the output yourself.
Personally I don’t rely on exa’s git support (I never even remember it’s there) but it seems potentially valuable, and now that you’ve reminded me about it I plan on looking into how to integrate it into my workflow.
The problem with “don’t do that” is you can’t add it on after the fact using another tool, like you can with e.g. sorting. You have to run a separate command and correlate the output yourself.
Personally I don’t rely on exa’s git support (I never even remember it’s there) but it seems potentially valuable, and now that you’ve reminded me about it I plan on looking into how to integrate it into my workflow.
I'm finding the website much more exciting than the tool itself. Which is not a criticism of the tool - the website is just really neat!
I'd love to use something like this, but I SSH to a LOT of different *nix systems.
My linux desktop, Linux server, Mac work laptop, work Linux servers etc..
For me, to take advantage of something like this, I'd want it everywhere. Otherwise you can't use any exa-specific stuff.
For me, to take advantage of something like this, I'd want it everywhere. Otherwise you can't use any exa-specific stuff.
I'll just drop these here as they might be useful to you
https://github.com/xxh/xxh https://github.com/intoli/exodus
https://github.com/xxh/xxh https://github.com/intoli/exodus
I recently wrote ls + cd replacement myself: https://github.com/antonmedv/llama
It’s a TUI with fuzzy searching, which helps a lot at navigating in complicated file systems.
It’s a TUI with fuzzy searching, which helps a lot at navigating in complicated file systems.
I used exa for a short while but switched back to using ls. Maybe I was using it wrong, but with my iTerm2 and ohmyzsh profile, I already had colors set the right way, and I couldn’t really see any advantage to using exa.
If all you want is colours in your `ls` output, then `ls` already has support.
1. turn on colours for ls in your shell. In your e.g. .bash_rc add:
1. turn on colours for ls in your shell. In your e.g. .bash_rc add:
alias ls='ls --color=auto
I have exa installed, but I don't use it as a ls replacement. Instead I have an alias that uses its git + tree view features as a replacement for git status.
Another pointless "replacement", that achieves what anyone with a basic knowledge of Unix and shell scripting can put together with couple of aliases and/or shell scripts. No thanks. Most of development today is basically about creating remakes/replacement of some totally perfect tool and trying to feed off of it's popularity. Developer creativity at an all time low.
It is an abstraction that can save any users from having to think about shell scripts. This is incredibly valuable. We should not waste human time on writing and thinking about shell scripts, there are much bigger problems to solve.
Are you serious? Writing a shell script or thinking about ways of tweaking stuff is not valuable but wasting time reinventing wheel is? You're the perfect example why there is a complete lack of creativity. Everyone is about making pointless abstractions no actual substance.
All software is an abstraction and that’s what makes it useful. It sounds like you have a particularly vindictive axe to grind against all the “pointless abstractions” people have poured hours of their time into so I’m sure I won’t convince you. But to other readers, it doesn’t have to be this painfully divisive.
This.
It's why I left emacs behind. I didn't want my entire life's body of work to be "a customized text editor."
It's why I left emacs behind. I didn't want my entire life's body of work to be "a customized text editor."
i did a quick test
exa -l vs ls -l
exa -l vs ls -l
./exa -l /home/_/Downloads 0.00s user 0.01s system 131% cpu 0.010 total
ls --color=tty -l /home/_/Downloads 0.00s user 0.00s system 93% cpu 0.003
Some people in the comments not understanding how alias work, If you alias ls to exa it's only going to affect the environment in your shell/prompt. If you run any command that relies on ls it's not going to be affected by the alias.
Also I prefer lsd or plain ls --color.
Also I prefer lsd or plain ls --color.
The word “modern” has been so thoroughly corrupted and overused to the point of meaninglessness as a software marketing term.
I’ve been more productive as a software user taking the term “modern” to be a signal to avoid the software in question instead of a signal to engage with it.
I’ve been more productive as a software user taking the term “modern” to be a signal to avoid the software in question instead of a signal to engage with it.
"fast" seems to be another such word, especially when not accompanied with benchmarks.
I've been using natls - has anyone compared that with exa? pros and cons?
I have been using ls-go for awhile now.
https://github.com/acarl005/ls-go
alias ls='ls-go -alkSi'
https://github.com/acarl005/ls-go
alias ls='ls-go -alkSi'
The automatic git status is the killer feature of exa for me. Makes it easy to see what files have been changed, what's ignored. etc.
While it looks good, one has to think about the cost of commands. In the same way that certain words slip off the tongue, and others don't, so too are certain words or commands easy (or not so easy) to type.
`ls` is easy, one keypress from each hand: right index, left middle.
`exa` requires three from one hand, likely left index (2), left middle, and requires three row changes.
To me, when we're going to use a command thousands of times per year, it has to be ergonomic.
`ls` is easy, one keypress from each hand: right index, left middle.
`exa` requires three from one hand, likely left index (2), left middle, and requires three row changes.
To me, when we're going to use a command thousands of times per year, it has to be ergonomic.
Uh, alias it to whatever you want?
does it have automated paging like git? doesn't look like it.
I think, except for very large volumes, automated paging is inferior to terminal scrollback. It is conditionally modal (thus conflicts with muscle memory) and you can't see previous output and the paged output at the same time (quitting the pager restores the terminal contents). I turned mine off in Git.
Can't you just do something like
if [[ -p /dev/stdout ]]; then
ls;
else
ls | less -F -R;
fiYou lose the colors by piping through less.
It depends. Most of the coreutils won't send color if you're piping unless you explicitly tell it to do so. ls is one of those; try --color=always instead of --color=auto, and be sure to use "less -R" on the other side of the pipe.
No you do not. Also, unless I'm mistaken, git uses the system pager for pagination and that happens to be less on almost all modern Linux systems (and many others).
Cool project but no real world use case.
IMO if you want to replace ls it has to be a 2 character command. I can type ls super fast with two hands. exa is really awkward to type.
I have 'lsd -al' aliased as 'l', it works fantastic.
I aliased `ls` to it… I don’t know how long ago. It’s been great.
what can break when you alias standard system command name to some random program downloaded from the internet.
one-liners you copy and paste!
no seriously, when you properly alias something in your .bashrc, they only take effect in an interactive shell.
ie: an `alias ll='ls -halF' in your bashrc does not work if you do `bash -c 'll' nor `./fileThatContainsll`
no seriously, when you properly alias something in your .bashrc, they only take effect in an interactive shell.
ie: an `alias ll='ls -halF' in your bashrc does not work if you do `bash -c 'll' nor `./fileThatContainsll`
alias
.. but exa is not backwards compatible with ls OOPS
Which is why I stick with ls (and grep instead of rg and coreutils instead of shiny rust equivalent), I can't deal with the cognitive dissonance that arises from these differences.
.. but exa is not backwards compatible with ls OOPS
Which is why I stick with ls (and grep instead of rg and coreutils instead of shiny rust equivalent), I can't deal with the cognitive dissonance that arises from these differences.
Sounds interesting, but the chosen name is unfortunate due to the line editor in vi (ex). Why not dr, or fz, or lsc, or dir_color? I know it isn't easy to find names that aren't already used, but if aliasing ls, name length couldn't matter less.
When a command line tool for listing filed has its own website, you know it's too much.
Seriously. All I need is a program that can tell me what files there are in a directory. That's such a trivial problem.
Seriously. All I need is a program that can tell me what files there are in a directory. That's such a trivial problem.
0: https://asciinema.org/a/454216 vs https://asciinema.org/a/454217
1: https://asciinema.org/a/454213