Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exa, a modern replacement for ls

the.exa.website

Post reply on HN
Print view View original

181–190 of 420 posts

Re: Exa, a modern replacement for ls

#181

Post by cytzol »

kbenson wrote: post #176
khedoros1 wrote: post #154

Earlier quoted context omitted.

Well, right, 180cm would be a customary way to show that (probably wouldn't be shot for saying 1.8m either). And 32GB for an SD card, or whatever. But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes…

I think what's really in discussion here is what the default should be. ls was originally conceived and implemented in a period when all the files you would be dealing with could be measured in bytes easily, and would almost never be over four digits. Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits, and at that level it's very ea…

You hit the nail on the head!

Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.

People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.

Re: Exa, a modern replacement for ls

#182

Post by jayvanguard »

yegle wrote: post #178
krat0sprakhar wrote: post #148

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.

Hah, interesting! Mine is writing a simple web server (sockets, IO, string handling) and an ultra-simple command line browser (args handling, 3rd party libs for URLs, HTML parsing, etc.)

Re: Exa, a modern replacement for ls

#183

Post by cytzol »

SrslyJosh wrote: post #179
cytzol wrote: 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…

I like the colors, but I'd like to be able to configure what's colored and, more importantly, what gets bolded. For me, the bold stuff jumps out and can kind of push the non-bold stuff into the background, which makes scanning that stuff a bit harder. (In case you're wondering, I think I'd skip bolding the username and the owner perms.) Also, I think that setuid bits are probably worth bolding, because you probably s…

Thanks! Configurable colours are something I'd like to get done, too. About half the work has been done to achieve this -- none of the colours are hard-coded, they're all looked up from a big Colours value that gets passed around internally. This value just needs an interface so it's configurable by the user. I've been meaning to open it up to the community instead of just defining an ad-hoc EXA_COLO[U]RS environment variable, but y'know, time.

Re: Exa, a modern replacement for ls

#184

Post by kibwen »

cytzol wrote: post #166
steveklabnik wrote: post #76

Earlier quoted context omitted.

This binds to libgit2, which binds to curl. I believe that brings it in.

You are correct. exa uses libgit2 for its Git column, and the library's networking parts must still be included when they aren't even being used anyway. I can see how it looks VERY SUSPICIOUS for a file lister to be parsing HTTP headers! I'm not going to sell your directory entries to advertisers, I promise.

For more paranoid folks, it would be nice to have a configuration option to forego the git features and thereby remove the need for linking in any networking code. :)

Re: Exa, a modern replacement for ls

#185

Post by dilap »

otterpro wrote: post #32

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…

ripgrep is amazing. people are starting to do really cool stuff in rust (alacritty also comes to mind) -- it definitely makes me feel optimistic about the language. (i've never done more than just poke at it.)

Re: Exa, a modern replacement for ls

#186

Post by renox »

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 +, one for - and a third one for the rest, nice!).

Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!

So colors by default? Thanks but no thanks.

Re: Exa, a modern replacement for ls

#187

Post by cytzol »

dozzie wrote: post #174
cytzol wrote: post #165

Earlier quoted context omitted.

grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not. exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had. Yeah, it'…

>> grep doesn't have the --colour option ternary for nothing. > grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not. Didn't I say that? Ternary . On, off, detect.

Oh, I completely missed that word. My bad.

Re: Exa, a modern replacement for ls

#188

Post by dilap »

ordu wrote: post #118
Denvercoder9 wrote: post #44

Earlier quoted context omitted.

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.

exa can be typed by using three different fingers. Its not any significantly longer then ls which use two finger movement. Maybe even faster: I dont know what science tells us about such motions, but at my opinion fingers of one hand can be more precisely synchronized, so you really can do faster movements and lower delays between keypresses. Just try to use fingers 2-1-4 (index finger, than thumb, than ring finger)…

maybe i'm typing wrong, but i want to hit "e" and "x" with the same finger, which makes it way slower to type than ls.

things that can't be typed w/o moving your fingers from the home row are really easy to type.

Re: Exa, a modern replacement for ls

#190

Post by PaulHoule »

renox wrote: 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…

My trouble is that most terminals have color settings such that colored text is not very visible. I really wish I could have a large number of different-colored terminals for different tasks, and that is easy if I turn off color, as designing a whole color set that always works is a bigger job.

What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.

Post reply on HN