3 ms·
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 fast
by robbedpeter 5y ago
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.
- coldtea 5y ago>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.
- vidarh 5y agoScripts 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.
- bin_bash 5y agoEven 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.