Someone mentioned that you can just do:
alias ll='ls -lahF --color=auto'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)
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.
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.