Live data from Hacker News

Exa, a modern replacement for ls

the.exa.website

291–300 of 420 posts

Re: Exa, a modern replacement for ls

#291
post #37

Earlier quoted context omitted.

> 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…

If you want to see the largest file, wouldn't you want to sort it by size anyway?

You would, but you would have to run `man ls` to figure out how to do that. That's a showstopper.

Re: Exa, a modern replacement for ls

#293
post #261

Earlier quoted context omitted.

> Did you strip both binaries? No, should I have to? I'm just looking at the published binary sizes. > I imagine Qt will be dynamically linked, so I'm not sure why you'd say that. I said like Qt, as in something similar written in rust. The Qt5 GUI module weighs in at about 10MB, if every gui program included it plus all the other libs then the bloat quickly adds up. > But that has nothing to do with Rust. Until rust…

> No, should I have to? You don't have to do anything, including publishing misleading comparisons. > Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem. Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64.

I'm comparing the file size of one tool to the published sized of a similar tool, how is that misleading? If the size can be reduced then why isn't it done when you publish it? Considering one is on disk size and the other is zipped I think I'm being more than fair.

>Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64

Again, it was an example. Show me a similar rust library that can be dynamically linked to like this? A rust equivalent will have to either use a c interface or be statically compiled.

Re: Exa, a modern replacement for ls

#294
post #178

Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls. I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again! Thanks for sharing this and also for your screencasts. I'd definitely spend a laz…

Writing `ls` is the first thing I do when learning a new language.

You must have had an easy time with Ruby, then.

  #!/usr/bin/env ruby
  `ls`

Re: Exa, a modern replacement for ls

#295
post #248
post #116

Earlier quoted context omitted.

(author here) 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 expec…

Ignore what they all said. It's proven that adding 3 dimensions of color means the information entropy is at least trippled. If you think about the terminal as a computer interface, then it's pretty obvious that we're bandwidth limited by how much information you can fit onto the page. Any amount of improvement in that bandwidth are certainly welcome changes. Niceties like having color-coded file sizes and filetypes…

I agree with your main thesis that colour adds information.

But not with your reaction to colourblindness - it's surprisingly common. We changed a grid of clickable red/green squares to add crosses and ticks after a chance comment, and several more users bothered to contact us about how much easier it made the UI.

So please DO give a... fig... about colourblindness - if it's worth adding colour to help users, surely it's also worth a little thought about how to cater for colourblind people. In this case, a grey-scale palette perhaps?

Re: Exa, a modern replacement for ls

#296
post #186

I find quite funny that the author is so convinced that the use of colors is the "right default". 1) I'm colorblind so my view of colors is different from yours. 2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, on…

iTerm2 lets you force a minimum contrast, which solves the contrast problem while still letting you use colors. Lots of programs display hard-to-see colors (red-on-black for me too), so it makes sense to address this problem at the terminal level.

From https://www.iterm2.com/documentation-highlights.html:

> Sometimes an application will display text with a color combination that is hard to read. Colorblind users in particular may find certain combinations hard to see if the colors differ only in hue and not brightness. If you enable minimum contrast (under Preferences > Profiles > Colors > Minimum contrast, then iTerm2 will guarantee a minimum level of brightness difference between the foreground and background color of every character. If you set this to its maximum value, then all text will be black or white.

BTW, I actually like having the git hashes almost invisible. I don't need to see the hash, I just want to double-click to copy it.

Re: Exa, a modern replacement for ls

#298
post #199

Earlier quoted context omitted.

> That said, the binary isn't self-contained (I know, I know) It wouldn't be right if something didn't go badly wrong at the worst possible moment!

exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory

[deleted]

Re: Exa, a modern replacement for ls

#299
post #294
post #178

Earlier quoted context omitted.

Writing `ls` is the first thing I do when learning a new language.

You must have had an easy time with Ruby, then. #!/usr/bin/env ruby `ls`

You haven't written ls in Ruby, you've called ls with Ruby. Big difference!

Re: Exa, a modern replacement for ls

#300
post #280

Earlier quoted context omitted.

Nope - it's pretty unreadable in iterm2 for me - http://i.imgur.com/bKQwIdJ.jpg Shame, the idea is pretty neat. If you can solve that issue, OP, I'd love to give it a proper try.

The question i have is why do users configure their terminals to use colours that are unreadable to them? If your blue doesn't look right on your dark background, why are you using that blue? If your yellow doesn't look right on your light background, why are you using that yellow? I mean i get how this can be a problem with hard-coded arbitrary values — you can't ever guarantee that e.g. #ff6600 will go with anyone'…

Personally, I didn't want to invest the time in color schemes when I was trying out a new terminal... however many years later, I like the terminal, but never cared enough. Most of the colors that show up are fine I guess (except the helpful serial over lan controller that manages to set the background and the foreground to the same color :( )
Post reply on HN