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.
.. 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.
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).
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.
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.
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.
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.
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.
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 think exa was a good ls replacement, but I found out that it's significantly slower than ls[0]. Heck, it's even slower than lf[1]. Quite frankly I didn't know what to think, but I removed the alias ls=exa.
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 total
> 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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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
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.
> (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.
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 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 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.
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.
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)
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.
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.
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.
exa isn't a scripting tool designed to be tied together with other scripting tools that also only do one thing. I think that it's probably better to consider the end user experience rather than the catchy parts of a design made decades ago for an entirely different context.
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.
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.
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.
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).
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.
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?
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.
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?)
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 ;-)
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.
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.
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”
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.
<<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...
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.
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)
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.
> 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.
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.
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.
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.
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).
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.
154 comments
[ 4.8 ms ] story [ 224 ms ] threadI always install tree on a new nix machine, might try this one out.
.. 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.
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`
1. https://github.com/Peltoche/lsd
alias ls="exa -h --group-directories-first --icons -g $@ --git --color always"
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.
alias ll='ls -lahF --color=auto'
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 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.
fzf is an amazing tool for this.
0: https://asciinema.org/a/454216 vs https://asciinema.org/a/454217
1: https://asciinema.org/a/454213
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
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.
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.
> 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.
Someone mentioned that you can just do:
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.
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.
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.
(to clarify the "180x" math: (10s - 1s) / (250ms - 200ms) = 9s / 50ms = 180)
Maybe a performance based execution of exa could be crafted that ignores some of the eye candy or whatever is sucking up the cycles.
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.
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.
That is, use ls when you you don't care about the direct output of the list file command, use exa when you do.
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.
"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.
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...
"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.
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.
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.
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.
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.
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.
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.
Check here: https://github.com/ibraheemdev/modern-unix
Some of them are great, some are opinionated.
> 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?
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.
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.
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 ;-)
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.
The sibling with the reference param is a great option as well, if you can remember it.
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).
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.
1 001
2 010
3 011 --> -wx
4 100
5 101
6 110
7 111
(clicking and the whack of an enter key)
(time passes)
“oh what th… oh, fuck ME!”
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 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...
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.
There's also the page cache involved for reads, so it can be read while actual IO is queued.
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.
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.
exa -l vs ls -l
exa uses +40% cpu usage and is slower.... not goodI’m not sure if there’s an equivalent for bash/zsh.
It’s a TUI with fuzzy searching, which helps a lot at navigating in complicated file systems.
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.
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).
solution looking for a problem