111–120 of 420 posts
> Git support: View the staged and unstaged status of every file, right there in the standard view. Also works in tree view. This is nearly impossible to implement securely. Better don't run exa against untrusted directories.
It uses libgit2 for this; I don't know what specific attack vector you're thinking about though.
./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory Couldnt all the dependencies be statically linked for max portability?
Is there a reason it has an http parser?
> For example, exa prints human-readable file sizes by default (when would you not want that?) When I've got two similar but non-identical files, and I think that the difference between their sizes might be important. That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.
If it turns out you like it, you can use it as a direct replacement for ls by using alias: alias ls=exa If you put that in your bash profile, it will be permanent (until you remove it from your bash profile, of course).
command lsI set up $LS_COLORS like 15 years sgo in my .zshrc… and haven't had to touch it since. Doesn't seem like a huge deal worth replacing it over.
It's not exactly the same though. LS_COLORS only colours file types (whether it's a file, dir or symlink) and permissions, while exa appears to also set the colours based on the mime type (text, image, etc.).
Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes coughMacOScough)
A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies against the pain of using it.
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.
The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.
You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".
Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.
That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)
>although Rust is cross-platform, I don’t have a Windows machine to develop on... Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes cough MacOS cough ) A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies ag…
Earlier quoted context omitted.
I thought the same at first. ls is good mnemonic for list, but what exa stands for and why three letters? "gf" for example would be better. neighbor characters on the keyboard, could stand for get files.
Furthermore, l and s are typed with different hands, which makes it quite fast to type. Exa is all left-handed, so it takes even longer.
> For example, exa prints human-readable file sizes by default (when would you not want that?) When I've got two similar but non-identical files, and I think that the difference between their sizes might be important. That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.
Earlier quoted context omitted.
> I hate using 'du' Why? On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.
hmm, but is it important that the small tools are actually developed separately? or just that you can call them separately? An example would be busybox, which can decide which executable to pretend to be by the target name.