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

381–390 of 420 posts

Re: Exa, a modern replacement for ls

#381

Post by yAnonymous »

tariandbari wrote: post #305

To the author: As you are already making a much more user and human friendly version of ls (like making ls -h the default behavior) please consider placing the name of the file on the left most column inode Permissions Links Size Blocks User Group Date Modified Name 21214836 .rw-r--r-- 1 9.4Ki 24 ben staff 29 Jun 16:16 Cargo.lock As a human I first care for the name , Currently I'm forced to scan the right most colum…

It's much easier to deal with line breaks. File names first would break the entire layout when one of them is too long.

And when the terminal is on the left, you don't have to move your eyes so much away from the middle of the screen.

Re: Exa, a modern replacement for ls

#382

Post by yAnonymous »

fnj wrote: post #375
kabdib wrote: post #212

Color is one of the first things I turn off. So many tools color files in ways that are very difficult to read (dark blue against a black background, really?) I'm colorblind, too, so your red/orange/green distinctions are utterly wasted on me. Raw color is a very flaky and low fidelity way to communicate to a user. Animation, on the other hand: Give that super important file that's somehow busted or very active some…

No idea on earth why you are downvoted. My sympathies for your challenged vision. Your objection is well founded, and your suggestion has merit.

Judging the use of colors in software as a colorblind person is like rating shoes when you have no legs. He's coming across whiny and pretentious.

Sorry it doesn't work for him, but colors are generally useful when working with lots of text.

Re: Exa, a modern replacement for ls

#384

Post by graysonk »

thecrazyone wrote: post #360
graysonk wrote: post #161

Earlier quoted context omitted.

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.

That's got UX backwards. You'd want to minimize the effort user has to make, no?

I don't really think that minimizing user efffort was part of the Unix philosophy, but rather to have tools do one thing well and be able to become input to another program that does something else well.

Re: Exa, a modern replacement for ls

#385

Post by Dowwie »

cytzol wrote: post #369
Dowwie wrote: post #349

This is great. I'm switching to exa! I had high hopes with this command but found the git features missing: exa -l --git --time-style=long-iso -T Nonetheless, this displays Hopefully, the author finds this worth the time to support..

Yo. What's it display? Feel free to raise a bug if something doesn't look right. I know it's not the fastest-moving open-source project, but I'll still read everything that people submit.

the output is missing the git modification flags

issue: https://github.com/ogham/exa/issues/183

Re: Exa, a modern replacement for ls

#386

Post by wvh »

SmirkingRevenge wrote: post #269
userbinator wrote: post #244

Earlier quoted context omitted.

Wow, the comments in this thread are quite harsh. I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to…

Maybe. Whether the term "modern" was used or not, my hunch is that the response would be the same, for it is forbidden for one to deign to make these kinds of changes to fundamental Unix commands, and is tantamount to a kind of heresy (never mind that GNU implementations did this all the time wrt. original Unix implementations). Religion... never cared for it. Re-invent the whole crappy (though still less crappy than…

A lot of stuff depends on the basic Unix commmands though. It might be better to invent a new command name if the output differs in ways that would break both human and machine expectations. The difference between BSD and GNU versions of some commands is already enough to trip me up even after all these years. You expect `ls` to be `ls` on anything remotely POSIX/Unix-y.

I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.

Re: Exa, a modern replacement for ls

#387

Post by lobster_johnson »

git-pull wrote: post #238
lobster_johnson wrote: post #83

Earlier quoted context omitted.

It's not overriding anything, so you're ranting against a faulty premise. The command is called "exa", not "ls", and it isn't even a drop-in replacement -- it doesn't have the same flags. You can't alias "ls" to it.

I don't see it that way. The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice? Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" in front of /bin/ls in their shell for convenience.

So? Nobody is going to use this to replace "ls" in scripts. Are you really arguing against the creation of competing tools? "ack" shouldn't exist because "grep" already exists? "htop" shouldn't exist because there's "top"?

Re: Exa, a modern replacement for ls

#388

Post by burntsushi »

flukus wrote: post #293
burntsushi wrote: post #271

Earlier quoted context omitted.

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

> how is that misleading?

I explained how. Take it or leave it.

> If the size can be reduced then why isn't it done when you publish it?

Because it's not a big deal? The only people who complain about this are people debating holy wars on HN, as if the static vs dynamic trade offs haven't been well understood by now.

> Again, it was an example. Show me a similar rust library that can be dynamically linked to like this?

Rust's standard library.

Re: Exa, a modern replacement for ls

#389

Post by burntsushi »

thecrazyone wrote: post #358
burntsushi wrote: post #145

Earlier quoted context omitted.

As a maintainer of a CLI program in Rust that runs on Windows, it is mostly a pretty nice experience. The only painful part was getting colors working in both MSYS terminals and cmd/PowerShell based terminals. I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows 10 laptop to test on as well.

You should probably write to exa developer, no? Perhaps, help out a fellow tool developer to bring the goodness of your tools to us devs on Windows? :)

It's available as a library: https://docs.rs/termcolor/0.3.2/termcolor/

Re: Exa, a modern replacement for ls

#390

Post by tym0 »

cytzol wrote: post #354
tym0 wrote: post #350

I've been using k [1] to get pretty much the same functionalities but, being written in zsh, it's terribly slow. Your program looks nice but I would love to have an output closer to k in term of colour [2], at the moment it feels way to noisy to me. [1] https://github.com/supercrabtree/k [2] https://raw.githubusercontent.com/supercrabtree/k/gh-pages/f...

I've seen k before, it's pretty neat. You can't grey out the columns in exa until I land configurable colours, which I hope to get done relatively soonish. But you can use the --colour-scale (or --color-scale) option to colour file sizes based on how big they are. The person who submitted the feature request ( https://github.com/ogham/exa/issues/65 ) used k as a direct example.

Nice, looking forward to the configurable colours, I feel when everything is in bright colour it makes hierarchy much harder to read.
Post reply on HN