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

271–280 of 420 posts

Re: Exa, a modern replacement for ls

#271

Post by burntsushi »

flukus wrote: post #261
burntsushi wrote: post #208

Earlier quoted context omitted.

> Another one is ripgrep, weighing in at 5MB compared to greps 204kb. Did you strip both binaries? If I strip rg after compiling it, it shrinks to 2.7MB on Linux. If I strip the distributed binary on Github (which is statically linked with musl), then it shrinks to 2.4MB. > Imagine what life will be like when we have UI toolkits like QT statically compiled into everything I imagine Qt will be dynamically linked, so I…

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

Re: Exa, a modern replacement for ls

#272

Post by Houshalter »

khedoros1 wrote: post #154
Houshalter wrote: post #82

Earlier quoted context omitted.

You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.

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…

Well all of that is just a matter of how many significant digits to print. You can print "1.873554727 GB". Its ugly as hell. But at least I can mentally truncate everything after the period without having to count the digits.

Re: Exa, a modern replacement for ls

#274

Post by dmckeon »

omribahumi wrote: post #96
kbutler wrote: post #93

Interesting that they chose to keep the file name on the right-hand side like ls, and unlike every graphical file manager. The name is the key field and so it should generally be the left-most column.

I guess that's because you can't resize columns interactively on the console, and the other columns are relatively short (and pretty much static length). It makes sense to list the filename last IMHO.

The file name (or entire path) should be where-ever the user expects to find it. Having fixed width columns makes using sort(1) trivial.

For the "all the information" part, I've been using something like this:

  fn () { 
    find "${@:-.}" -printf "%TY %Tm %Td %TH:%TM:%2.2TS %1y %4m %3n %4U:%-3G %8s %p\n"; }

Re: Exa, a modern replacement for ls

#275

Post by turnspike »

cytzol wrote: post #183
SrslyJosh wrote: post #179

Earlier quoted context omitted.

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…

I'd settle for a flag that disables the rainbow perms, it seems to be a common gripe. It's nearly a dealbreaker for me. But, that's personal preference - congrats on a great util.

Re: Exa, a modern replacement for ls

#276

Post by ams6110 »

_jal wrote: post #125

It is great to scratch an itch and make something behave exactly as you want it to be - kudos. That said, this is very much not for me. Default-colorized is something I emphatically do not want; defaulting to relative units, ditto. It it were me, the first thing I would do is get rid of 'grid' display entirely - reading across just doesn't work for me. Etc. More prosaically, `ls` is sort of like breathing for me - I…

I am pretty much in agreement. I have no complaint about anyone who likes this and wants to use this, but it's not for me. I like utilities that do one thing. ls for listing files. find for finding files and traversing hierarchies. git for dealing with git repos. xargs and pipes and maybe other utilities if I need to glue things together.

If I want something fancy, I will use emacs dired mode as a filesystem navigator and magit for git repos.

And cynically, if this wasn't written in Rust I don't think it's on the front page.

Re: Exa, a modern replacement for ls

#277

Post by flukus »

saagarjha wrote: post #225
flukus wrote: post #169

Earlier quoted context omitted.

> 38 kilobytes of executable isn't small, it's tiny; there's no way exa could get to that level without compromising its featureset or development I'd be willing to bet dynamic linking would get it much closer to that ballpark and wouldn't compromise the feature set or development.

Dynamic linking to what , though? The features you're looking for have to available in a library for you to be able to link to it.

Dynamic linking to the standard library + the projects dependencies, from the cargo file:

ansi_term = "0.8.0"

datetime = "0.4.3"

getopts = "0.2.14"

glob = "0.2"

lazy_static = "0.2"

libc = "0.2.9"

locale = "0.2.1"

natord = "1.0.7"

num_cpus = "1.3.0"

number_prefix = "0.2.3"

scoped_threadpool = "0.1.*"

term_grid = "0.1.2"

unicode-width = "0.1.4"

users = "0.5.2"

Re: Exa, a modern replacement for ls

#278

Post by Houshalter »

userbinator wrote: post #249
Houshalter wrote: post #82

Earlier quoted context omitted.

You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.

If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. I disagree; what's easier, spotting the biggest and smallest of these at a glance: 6,677,967 5,916,109 7,164,551 3,745,059,597 3,175 4,194,304 3,550,137 or these: 6.37M 5.64M 6.83M 3.49G 3.10k 4.00M 3.39M If they differ by orders of magnitude…

That only works when the files you want to compare are in the same folder and next to each other. If you just want to know how big a given file is, then you have to count the digits. And IIRC ls doesn't even print commas like that to make it human readable. It's just a blob of digits with more precision than is reasonably necessary for the vast majority of uses.

Re: Exa, a modern replacement for ls

#280

Post by okdana »

mcjiggerlog wrote: post #172
amelius wrote: post #8

Does it take into account the background color of my xterm so things do not become unreadable?

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's particular colour scheme. But these 8 or 16 standard colours are not hard-coded, they're configurable in every terminal i've ever used, including Windows's shitty command prompt. They can and should be set to a value that's appropriate for your background and text colours.

Maybe this is more a fault of the terminal/theme developers for providing unusable defaults. idk.

Post reply on HN