I wonder if it's a good thing or a bad thing that I've never considered, even for a moment, replacing a tool like ls. My first reaction was that it's hubris to think "ls isn't good enough for me, I'll make something better." A bit more reflection has almost convinced me that it's a very good thing that people are always thinking and working on ways to improve things, even something that's taken for granted.
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'm not sure about ls. As for this tool all it seems to add is git status, but it's not working for me for some reason (not sure why) so I can't comment on the usefulness of this.
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.
A similar, but more broadly scoped project is uutils/coreutils [0], which is a cross-platform re-write of the GNU coreutils in Rust.
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.
I find it interesting that so many are disparaging this for not being backwards compatible, etc., when there is simply no need. The title of the post clearly states it's a replacement for ls, so why should it be backwards compatible?
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.
I think people were in general quite nice to him, understanding the scope of the project. Who uses ls in scripts anyway...? :-)
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.
> ...so many are disparaging this for not being backwards compatible...there is simply no need...it's a replacement for ls, so why should it be backwards compatible?
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.
This would make some sense if it were backward-compatible with normal "ls" for basic things like "ls -l". That way, people could alias "ls" to "exa" and not break too many things. But it drops the group and adds Git markers (which are only occasionally relevant), so I don't see myself trying this.
I would not joy until exa is tried over a fs with more than a million files. Huge file numbers are a thing now and it is becoming to be an engineering challenge.
exa can certainly handle a million files. Try running "exa -lRT ~" and watch it produce a tree view of your entire home directory!
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.
Works pretty good! I really like the symbolic-link-preview.
But I think it would be better when you just add -l when you enter things like -h, -T, -b, ... or allow an option for that.
Thanks! Years ago I wrote a wrapper for ls that just added colours and did highlighting - but not only was it much slower, I couldn't do things like preview a symlink's path because that information wasn't available in ls's output. So exa was born.
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.
Not tried yet. Wonder if it's got the option to display the size of directories. On the screenshots, the directories are shown with '-' just like the case with the ls.
Do you mean recursing into a directory and summing the file sizes of its contents? exa doesn't do this, sorry, but it's something I've been thinking of adding.
ls actually displays the 'file size' of the directory, which I've left out, as that number has never benefitted me, ever.
I am using it right now and it is great! My only complaint is that it is a lot easier to type `ls` than `exa` :) (all the letters are on different key rows with the same hand)
If `e` isn't already used by another command or function in your environment, you could do something like this in .bashrc, .zshrc, or wherever you put your aliases:
alias e='exa -1'
alias ea='exa -a1'
alias ee='exa -hla'
Note, that's a number "1" in the first two, and -h here includes the headers, which is different from ls -h, which exa appears to do by default. Other than the one entry per line printing, it's similar to the ubuntu default aliases for ls.
I think this is actually most interesting as a demonstration of Cargo's support for "features" (http://doc.crates.io/manifest.html#the-%5Bfeatures%5D-sectio...), which is a concept I haven't encountered in other package managers before. Is it something that Cargo inherited from Bundler?
Though it's not a package manager, configure scripts have had this for a while -- e.g. ./configure --no-git. Still, it's certainly cool to have it built into Cargo!
It would be useful to re-implement the basic UNIX utilities (at least the ones in BusyBox) in Rust. But without all the extra bells and whistles this program has. Lots of embedded systems need a reliable set of tools.
An exploit was discovered in "files" recently. Somebody put a decoder for Linux executable files in it, creating a security hole.
You don't need to be a Rust enthusiast to install it if it enters to a repository for the package manager/distro you're using. However, we need an enthusiast (or maybe author) to do that first. It is as if I don't need to be a perl programmer to use ack over grep.
Mozilla plans to use rust for parts of its code by the end of this year.
This isn't set in stone yet, but I'd expect rust code to be pretty standard soon.
How do you pick the colours? The website uses a dark background. If I ran this tool on my terminal (with a white background), would the colours still be readable?
It uses the colours you pick in your terminal. I made the website dark because I like that colour scheme, and it's what I look at all day, so copying it for the website was a natural fit :)
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.
It seems awesome, specially the --tree option.
I would love to try it, but
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.
But what? This is some code that some dude wrote and published courteously open-source, it's written in a rather-newborn language and it is for computer-savvy users. Were you expecting a binary installer?
Actually, I just updated the repo and rebuilt exa and this issue is gone.
As soon as the integration with gitlib2 becomes fast enough, this will be a perfect ls replacement.
[+] [-] zedpm|11 years ago|reply
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]
[0] https://en.wiktionary.org/wiki/licence
[+] [-] igravious|11 years ago|reply
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.
[+] [-] Touche|11 years ago|reply
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.
[+] [-] indiv0|11 years ago|reply
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.
[0]: https://github.com/uutils/coreutils
[+] [-] 59nadir|11 years ago|reply
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.
[+] [-] MrQuincle|11 years ago|reply
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.
[+] [-] cogburnd02|11 years ago|reply
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.
[+] [-] username223|11 years ago|reply
[+] [-] fsniper|11 years ago|reply
[+] [-] cytzol|11 years ago|reply
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.
[+] [-] TN1ck|11 years ago|reply
[+] [-] cytzol|11 years ago|reply
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.
[+] [-] aurora72|11 years ago|reply
[+] [-] cytzol|11 years ago|reply
ls actually displays the 'file size' of the directory, which I've left out, as that number has never benefitted me, ever.
[+] [-] EpicDavi|11 years ago|reply
[+] [-] _-_-_-_|11 years ago|reply
[+] [-] kibwen|11 years ago|reply
[+] [-] jmgrosen|11 years ago|reply
[+] [-] comex|11 years ago|reply
[+] [-] nathan7|11 years ago|reply
[+] [-] Animats|11 years ago|reply
An exploit was discovered in "files" recently. Somebody put a decoder for Linux executable files in it, creating a security hole.
[+] [-] whyever|11 years ago|reply
[1] https://github.com/uutils/coreutils
[+] [-] dbaupp|11 years ago|reply
[+] [-] zkanda|11 years ago|reply
[+] [-] whyever|11 years ago|reply
[+] [-] knowledgesale|11 years ago|reply
Unlike exa it fully supports Windows and does not have any external dependancies (as it is written in Go, everything is included already).
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] desireco42|11 years ago|reply
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.
[+] [-] brson|11 years ago|reply
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.
[+] [-] maemre|11 years ago|reply
[+] [-] wtetzner|11 years ago|reply
[+] [-] hannob|11 years ago|reply
[+] [-] joosters|11 years ago|reply
[+] [-] cytzol|11 years ago|reply
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.
[+] [-] hlieberman|11 years ago|reply
[+] [-] krick|11 years ago|reply
[+] [-] threeseed|11 years ago|reply
People said Go was just a systems language and we've seen it being used for lots of different use cases.
[+] [-] fiatjaf|11 years ago|reply
[+] [-] gkya|11 years ago|reply
[+] [-] spullara|11 years ago|reply
[+] [-] zeekay|11 years ago|reply
[+] [-] on_and_off|11 years ago|reply
[+] [-] on_and_off|11 years ago|reply
[+] [-] zobzu|11 years ago|reply
[+] [-] Rosales|11 years ago|reply
[deleted]