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

161–170 of 420 posts

Re: Exa, a modern replacement for ls

#161

Post by graysonk »

zokier wrote: post #35
pbiggar wrote: post #14

This is really cool - bringing the great treatment of `ack` to ls. And can confirm how fast it is! The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools! Oh, and It's in homebrew already: `brew install exa`

> The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools! Bit ironical, as ls already is pretty "non-unixy" and has way too many features tacked into it. From purism point of view it would make more sense that ls would be just a list of files and let other utilities (stat, sort, etc) handle the rest.

That would be great. Probably about 40% of all issues in bash scripts I see is people trying to parse ls because they don't know other tools. It would be amazing if ls reigned in the features some so people learned better tools.

Re: Exa, a modern replacement for ls

#162

Post by kbenson »

cytzol wrote: post #116
arkitaip wrote: post #36

Earlier quoted context omitted.

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.

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

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

I think the coloration is good, but I would have defaulted a bit differently in the permissions. I would have made all user bits green, all group bits orange, and all other bits red. Not only does this denote the possible security implications of the permissions, but it also maps well to what I'm usually looking for - what are my permissions, and being able to see all those quickly with green would be useful. As an added benefit, there wouldn't be as many per-character color changes in that section, so it would be less busy.

Awesome work, BTW. I love seeing interesting re-imaginings of old standby utils. I was actually thinking of doing my first real Rust project as a cat replacement. I was thinking of calling it calico. ;)

Re: Exa, a modern replacement for ls

#163

Post by bowmessage »

cytzol wrote: post #116
arkitaip wrote: post #36

Earlier quoted context omitted.

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.

(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 heavily rely on colorization to read what I need to on the terminal. I pipe almost all of my logs through ccze by default. Thanks for this great tool -- installing.

Re: Exa, a modern replacement for ls

#164

Post by flukus »

simias wrote: post #103
hk__2 wrote: post #77

Earlier quoted context omitted.

For comparison, ls is 38k on macOS (edit: and coreutils’ ls is 138k).

Rust links all its runtime statically by default. Your /bin/ls is probably dynamically linked to libc and a few others. That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary.

> That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary.

For a single app, sure it's no problem, but what about when the thousands of other programs in bin introduce similar levels of bloat? Another one is ripgrep, weighing in at 5MB compared to greps 204kb.

And this is just for fairly simple command line tools, Imagine what life will be like when we have UI toolkits like QT statically compiled into everything.

Re: Exa, a modern replacement for ls

#165

Post by cytzol »

dozzie wrote: post #142
theBaba wrote: post #126

Earlier quoted context omitted.

It does the sane thing when it detects the output is being pipped and doesn't output the color controls.

Great! Where are my colours in `foo | less -SR' on the terminal ? It's not " the sane thing" to differentiate output on STDOUT's attributes. 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.

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's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.

Re: Exa, a modern replacement for ls

#166

Post by cytzol »

steveklabnik wrote: post #76
erichurkman wrote: post #38

Earlier quoted context omitted.

Why does a directory lister need an HTTP parser?

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.

Re: Exa, a modern replacement for ls

#168

Post by kbenson »

Recursing wrote: post #121
lsiebert wrote: post #74

Earlier quoted context omitted.

I'd also consider things like piping to awk or finding the largest files in a set of directories. Human readable sorting is much more complex.

Isn't there `sort -h`?

It's almost as if people used these tools together enough, that they made an effort to make them work well together. ;)

Seriously, "du -h | sort -h" is a regular command for me.

Re: Exa, a modern replacement for ls

#169

Post by flukus »

cytzol wrote: post #138
tadzik_ wrote: post #42

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

I wouldn't say it's bullshit, just a difference of opinion. 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, and even if you did, you'd just have another ls, and we already have ls. If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter fil…

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

Post reply on HN