51–60 of 420 posts
> exa is written in Rust, so it’s small I suspected this would be total bullshit, and it is. Its small binary is a mere 3.4 megabytes. I wonder if I misinterpreted the "small" part.
Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949
This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.
Just clicked-through to see what you meant about `exa -l` and I agree. When individual characters have different colors that's just way too much.
> exa is written in Rust, so it’s small I suspected this would be total bullshit, and it is. Its small binary is a mere 3.4 megabytes. I wonder if I misinterpreted the "small" part.
It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'. I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24' Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandli…
Earlier quoted context omitted.
I almost never use the human-readable file sizes. For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal…
> I almost never use the human-readable file sizes. Same here. I love the idea, and i keep trying to use human-readable sizes in every command which supports them. But it turns out they're much less scannable than numbers in a common unit. How long does it take you to see which of these files is biggest: 13k potatoes.txt 7M tomatoes.txt 128 recipe_ideas.txt 1G hot_sauce_formula.txt How about now: 13093 potatoes.txt 7…
.. 13k potatoes.txt
.... 7M tomatoes.txt
128 recipe_ideas.txt
........ 1G hot_sauce_formula.txtEarlier quoted context omitted.
I almost never use the human-readable file sizes. For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal…
We shouldn't need complete backwards compatibility on a command that is completely new, surely? That would limit the amount of improvement that could be made dramatically. Also, as a side note, why do you enjoy using machine readable file sizes over human readable? The latter, as chosen by their name, are meant to be easier to use for humans.
I would also like to add to the case twic showed that often I am using ls to see if a file is growing. In human-readable format hides the actual size and rounds -- it could move 200 megs or more before the human-readable output is updated from 1G to 1.2G.
To address why backwards comparability is needed is because of muscle memory. Its not likely that this tool will be on every system I use. I don't want to have to think about what system I am on and what command I need to run. It would be nice to also be able to alias it to 'ls' as ls is way faster to type than eax -- all on the left hand makes it MUCH slower -- although I am sure there will be those who say different -- but they are wrong.
The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa EDIT: "exa prints human-readable file sizes by default (when would you not want that?)" I actually use bytes a lot for certain progress calculations. Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory"…
The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa EDIT: "exa prints human-readable file sizes by default (when would you not want that?)" I actually use bytes a lot for certain progress calculations. Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory"…
Why does a directory lister need an HTTP parser?
The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa EDIT: "exa prints human-readable file sizes by default (when would you not want that?)" I actually use bytes a lot for certain progress calculations. Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory"…
⋊> ~/Downloads ./exa-linux-x86_64 --version 15:26:40 ./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
...yup.
This is nearly impossible to implement securely.
Better don't run exa against untrusted directories.