Show HN: Exa, a replacement for ls written in Rust
bsago.me
bsago.me
On a tangential note, I learned something new and thought that a few other folks might find this of interest: In the screenshots, we see a file with the name "Licence", which to my American eye looked like a typo. On further investigation I found out that "In British English, Canadian English, Irish English, Australian English, and New Zealand English the noun is spelt licence and the verb is license."[0]
To address your first point. If we can't even question the most basic of our tooling then we'll just inhabit a stasis that may be just a local optimum.
To address your second point. The way I think these licence/license words should go is - think of advice/advise. The verb's got the 's', the noun's got the 'c'. Am I wasting my time in actually caring about shit like that? Probably. But that's how I'm wired.
I don't think it's a waste of time, but language is fluid. Sometimes it changes very rapidly and sometimes slowly, but it's never static. Since the US uses a single spelling for both (and most of the world defaults to using US English) my guess is that the distinction will vanish eventually.
I'm slowly learning not to care about these distinctions when it comes to English, as long as the meaning is clear. The closer you look, the fuzzier language becomes - even in the UK or US alone, there are vast differences in the way it's used.
I do think some other coreutils could be replaced. cp for example, doesn't give you a progress bar so if you are copying a very large file it could take 2 minutes or 2 hours. I suppose you could create a wrapper for cp that repeatedly ls-es the destination directory to give you a progress of the copy.
IMO, both the coreutils project and Exa are interesting for the same reason: they provide an example of Rust is one of it's niche environments - low level tooling.
It's not like everything everyone ever makes has to be a perfect fit in every capacity. A guy made a replacement for 'ls' as a fun thing to do in a language he likes. We make toys all the time and if you don't you probably just don't even like programming. The fact that he'd share this with us because he thought other people might be interested is precisely why places like these are good.
We might as well just start disparaging every posted project for not being a solution to starvation around the world if we're going to condemn everything that isn't an immediate step 'forward'. Let people make things they think are neat and try to see the positive side of things instead.
If someone's selling you a product I can see this behaviour being warranted, but when someone is trying to show you something they made because they think it's neat, you don't jump on it as if he's trying to change the world with it.
Because unless someone feels like editing every script or tool that makes use of ls, then it cannot be used as a replacement, i.e. You'll have to have both ls and exa on your hard drive instead of just exa. Also, people are used to the options of ls, and backwards-compatibility (in the form of a shell alias) is one less barrier to entry.
It can be used as a replacement just fine, just not if you symlink/alias 'ls' to 'exa', which I don't see as relevant. 'fish' is a replacement for bash, but I don't remove bash because of having it and I still have plenty of scripts using bash. It's just that my personal usage is exclusively with fish.
> You'll have to have both ls and exa on your hard drive instead of just exa.
Yes. I don't think this is a problem.
> Also, people are used to the options of ls, and backwards-compatibility (in the form of a shell alias) is one less barrier to entry.
I agree that it is a barrier to entry, yes, but this is clearly a toy created just to have fun with a language and make something that also happens to be fairly useful. It's not meant to take over the world, as far as I can see.
You're not using fish as a replacement for bash.
You're using them both alongside each other. There is, of course, nothing wrong with this, but it is important to know that that's what you're doing.
Because many of the scripts on your computer depend on bash (or another shell with sh-like syntax) it would be difficult or impossible to use fish as a replacement for bash.
Similarly, it would be difficult or impossible to use exa as a replacement for ls, because ls has options that exa doesn't.
I AM USING fish as a replacement for bash. Whether or not scripts that run on my machine use bash or not is entirely irrelevant to the point.
Your reasoning is that since there are things I am interacting with that use ls I won't be able to replace it by actively exclusively using exa. This is the same reasoning that would conclude that if you compile a language to C you have not replaced your use of C by using only this compiled language, since things that you use in turn still use C. You will still need things connected to C on your machine, but to say you have not replaced C for yourself is ridiculous in this example, as it is in yours.
Take the following situation:
Person A is working on a project and says to person B that he has recently replaced the Haskell parts of it with Common Lisp. Person B takes a look at A's repository and concludes that he has not. He still has a tool made in Haskell that he uses for one thing in his project. He didn't make this himself, it's a third party tool.
Now, in this scenario, wouldn't it be fairly sane to assume that while A has not completely eradicated all traces of Haskell in his project, he has still replaced Haskell with Common Lisp? His own usage has been completely replaced with Common Lisp. I think most people would think that is the important part of the statement he made in the beginning.
No, you're using both of them. If you are using scripts which themselves use bash, then you're using bash, albeit indirectly. You may not be using it in interactive mode, but you're still using it nonetheless. If you had replaced bash with fish, then you would not need bash on your computer at all.
Replace (in the context of Unix-like software) means completely replace, as in: no longer needing the original for any purpose.
There is nothing about the context of Unix that makes this use case different than any other. If you yourself always blindly take "replace" to mean "completely replace", then that's fine. I would contend, however, that most regular people see the above scenario precisely like I outlined.
> then you're using bash, albeit indirectly.
This line, however, makes me think that you purposefully ignore the example because with your reasoning we are all using C no matter if we've never seen the language at all, if the case is that a language we use is compiled to C. By this reasoning users of Chicken Scheme and Gambit Scheme are using C, because both of these Scheme variants are compiled down to C.
I find it strange that you would be so interested in setting the limits for what other people constitute "use". I've told you several times that for personal use I've replaced bash with fish. This, apparently, is not enough for you. I made a scenario to illustrate how silly it sounds to say Person A hasn't replaced Haskell.
Someone calls you and you are in your study. Your friend Janet is in the living room downstairs. The person on the phone asks: "Is Janet there?". How would you respond to this question?
I disagree; the programs which make up a Unix-like system are designed to be modular (even extremely so, compared to {say} Windows), which greatly facilitated the development of GNU, a replacement for Unix.
"As the GNU Project's reputation grew, people began offering to donate machines running Unix to the project. These were very useful, because the easiest way to develop components of GNU was to do it on a Unix system, and replace the components of that system one by one...it was legitimate to use a proprietary package when that was crucial for developing a free replacement that would help others stop using the proprietary package...Today we no longer have any copies of Unix, because we have replaced them with free operating systems." --from https://www.gnu.org/gnu/thegnuproject.html
> With your reasoning we are all using C no matter if we've never seen the language at all
Well, we kind of are. For example: if we haven't replaced all our copies of libc by 2038 with one that supports dates after 2038, then we're all screwed. Whether or not we 'personally' use C or not.
> Janet
Well, skipping over the fact that I don't know anyone named Janet (;-D) I'd say "Janet's downstairs, let me get her for you."
On the other hand I think it would be great if together we would try to go back to the early attempts of writing utilities that do only one thing and can be chained together with pipes. If ls isn't a good utility for pipes we have to come up with an alternative. You can then pipe it into a frontend like exa and everybody is happy. :-)
I think at hackernews there are a lot of brilliant people who would definitely be able to formulate interesting goals/projects to work on (and which will be of benefit to us all). And no, that does not always need to be an idea with which you can start a new startup.
That ls is one of the utilities that needs more love from us all, I think we probably all agree on. Check your history on how often you used it in the past.
However, by 'handle', I actually mean 'run without crashing'... if you run that command, it'll be several minutes before it produces any output. exa aligns its output into a tabular format with every column having the same length, which means it actually has to stat and examine every file in the list before it's able to output the first line. This is annoying, but (as far as I know) unavoidable.
more information about the getdents buffer issue: https://www.olark.com/developers-corner/you-can-list-a-direc...
Again, beware before downvoting me to oblivion I have not yet looked into the code.
Seemingly on unix types of OSes exa uses std::old_fs::readdir, it uses sys::unix::readdir and it uses libc::readdir_r Which would also have the suboptimal getdents buffer issue.
I was unaware of the getdents issue - thanks. However, it is most definitely slower than ls, because I've only tested it on large directories, rather than using it with large directories daily, so I haven't found places to optimise it quite yet. I'm not sure if using Rust will let me avoid that buffer issue, as right now I'm just using the function provided in its standard library.
I do wonder if it's worth it eventually for libstd to speak the syscall interface directly, instead of going through another language's standard library (and whatever bugs or design decisions that standard library might have).
And as for automatically adding --long when you use --tree or similar: this is something I've hummed and haahed about, and I'm still not confident that I've done it the best way, so I'm open to suggestions here. It seems that most tools just seem to ignore it if you pass in two conflicting options, or redundant options, and personally I'd much rather have the user always give correct behaviour than potentially get it wrong without knowing. But I'll just have to see how people end up using it.
ls actually displays the 'file size' of the directory, which I've left out, as that number has never benefitted me, ever.
alias e='exa -1'
alias ea='exa -a1'
alias ee='exa -hla'
An exploit was discovered in "files" recently. Somebody put a decoder for Linux executable files in it, creating a security hole.
Unlike exa it fully supports Windows and does not have any external dependancies (as it is written in Go, everything is included already).
I think there is a need for such utility, if it could be made in more portable fashion. I am not installing rust just for this.
One catch is that (especially if you're using C libraries other than libc, but sometimes with libc) you'll need to worry a little bit about forwards- and backwards-compatibility of those libraries. It's somewhat safer to find a semi-old distro like Ubuntu 12.04, build there, and see if it works everywhere newer.
This is kind of a pain, and the long-term answer is to get Rust into the distros so that they can build software written in Rust. (This doesn't require rustc being installed on any machine other than the builders.) In the short term, a cross-distro package generator for binary crates sounds like a maybe-fun project....
It installs Cargo applications without requiring an existing Rust install. Instructions for installing exa are on the README.
Since I wrote it in a few hours, using it may set your hard drive on fire.
A few of the filetypes use colours in the 256-colour range, but these should work well too - the grey colour you see for non-existent '-' table cells in the columns view is the exact middle grey value (colour #244) because it's the only one that's guaranteed to work with light-backgrounded terminals.
People said Go was just a systems language and we've seen it being used for lots of different use cases.
In Go, the GC is opaque and non-optional. In rust it's the opposite. Go fails at one of the fundamental requirements of a systems language.
I have not heard many people claim that it really is one.
The problem may be large binary size (mostly due to the runtime size and static linking). But I don't see why using a garbage collector is a problem for plain UNIX utilities like ls-replacements.
In fact, if you are running a Debian or Ubuntu system, a lot of utilities are written in Perl or Python.
Download and install Rust Nightly for your platform.
Install libgit2 and cmake using your favourite package
management system (or pass --no-default-features to the
next step)
Run git clone https://github.com/ogham/exa.git to download
the latest version of exa.
Run cargo build in the new directory to compile exa.
Move the resulting target/exa executable into a directory
in your $PATH, or add an alias for it in your shell.