Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls.
I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!
Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.
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 come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.
Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.
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 alternatives) Unix command line, I say.
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`.
I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think
I'd suggest describing it as a "colourful alternative" rather than a "modern replacement", because no-one will be removing /bin/ls with exa installed. "Replacement" strongly implies removal of the thing being replaced, as with "replacement hip", "replacement CEO" etc.
As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.
Yeah, that's the thing: built in gnu tools might be used by other tools/scripts/etc. - if you're ls isn't there or delivers unexpected output, they will fail miserably or cause havoc
The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides.
One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".
As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).
"As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space."
POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.
A shell glob cannot tell you the size, owner, permissions, timestamps of a file. For that .. oh look! There's ls(1). Which, by the way, spits out whitespace it sees just fine, unless you specified -q or implied it with output to a tty. If some code can't handle the result, it's that code that is broken. Tip: the only really problematic character is a newline; if you think you could be seeing those, you can still deal with it programatically, but I use find(1).
In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.
touch 'file with spaces'
for file in $(ls); do
rm -- "$file"
done
This will not work, because $(ls) will get expanded to three items, not one. rm will be called on the files "file", "with", and "spaces"...which is not what was intended.
Now do this:
touch 'file with spaces'
for file in *; do
rm -- "$file"
done
>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
For me, when I see people waxing poetically about the unix way and the old, crufty, POSIX userland, it's all about cargo cult, "that's how things have always been", minimum viable progress while keeping compatibility, and heritage-over-substance.
It looks neat. You should include a link to the documentation on the homepage. After I saw the screenshot I went looking to see how easy it would be to change some of the colors before I installed it. I read down below that the colors are baked in:(
It would also be nice to see files owned by different users and some of the git functionality.
Nice! I just downloaded it here ... My suggestion is to include an option to list the hidden files (dot files) as well as some file sorting options in the next version of Exa. ;-)
Hah, interesting! Mine is writing a simple web server (sockets, IO, string handling) and an ultra-simple command line browser (args handling, 3rd party libs for URLs, HTML parsing, etc.)
Mine in similar, I implement an authoritative domain name server. I've done it in something like 20-25 languages now. The only language I've learned in the last decade I didn't write one in is ARM Assembly. I am not that "dedicated" (more like masochistic) enough to try to do one in assembly.
I tend to reimplement the Linux kernel from scratch a few times in every language and go from there onto the X server, desktop environment, networking stack, etc.
It would be nice if it implemented the exact same set of command line flags as ls plus whatever else it does. That way I'd be able to use it as a replacement when I type 'ls', much as 'vi' fires up 'vim'.
Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.
oh great, but shouldn't it then also behave exactly like ls does, i.e. deliver the same output whenever a script of yours or somebody else calls ls and expects a certain output?
oh wait, I know what behaves exactly the same way: ls
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 do it so much during the average day that I don't even think about it. Can't say I immediately know every one of the switches, but probably 10 or so variants I use daily are pure muscle memory, and less frequently used things (extended attributes, symlink-deref options, etc.) I can remember without the man page.
So in that sense, `ls` is well into the same category as vi for me - I'm so accustomed to whatever warts there may be that switching would be much more painful than any efficiency gain.
Thanks for the kudos! It's absolutely mindboggling how many times I've decided to deviate from one of ls's default settings -- certain that the old way was inferior and outdated, and that the new way will be obvious and immensely popular -- only to find people have no idea why I'm doing things this way! I need the colours to help me scan the output; if I don't see human-readable units, I curse myself for forgetting the flag. But thousands of people don't like this, and it's usually a different set of features with each person, too. I would never have guessed I was so 'out there'!
ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.
(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)
I use colorized ls by default and get a bit peeved by how I have to jump through hoops to get that on OSX by default. If it works out. i'll probably alias "ls" to "exa" in the future.
That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.
Maybe make colourisation optional on either flag or as an env var. Then when you log in to a terminal and your profile loads, colourisation 'just works'.
That muscle memory must have taken quite some time to develop. Here's to a future where the legions of programmers coming down the pike don't have to spend that investment to get the same or better result.
One thing I always wanted to remove from `ls` is the default "human-like" display of dates and times (which `exa`, unfortunately, seems to inherit). This is IMO just annoying (and replacing time with year, if it differs from current, just plain stupid; and don't get me started about the "bright" idea of using locales there!). We have ISO-8601 for a reason. It's readable and universal. 2017-06-17 is easier to parse than "cze 17" (hello, locales).
I might be in his userbase part of the time. It seems exa does have some features I'd find handy once in a while in addition to ls. I think "replacement" is going too far for me. Some of the subthreads talking about actually aliasing 'ls' to 'exa' sound to me like they're going to break some little-known features on their systems. I'm in the "potential supplement" camp I guess.
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.
I just noticed the tests and the incredible lengths the author went to in order to effectively test exa. It's really impressive. GNU coreutils ls has a pretty good test suite, too ( http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls ), but this goes well above and beyond the call for something so new.
This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.
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.
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 expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".
Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.
That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)
> 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. ;)
I really like a lot of the extra colors but I was also overwhelmed by the rainbow permissions. User, group, world are the organizing principle for me. World writeable is something I never want to have in my mind as similar to user writeable.
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 shouldn't see them very often.
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 variable, but y'know, time.
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.
For me it is always difficult to see the groups in the permission groups, I would prefer the user part would have one color, the group part another... identifying if there is a r or w is not the problem. There should maybe be also between the groups a space, just to make the output more readable. Otherwise I would like to not see the file creation/change date at all, since most times it adds no valuable information. To get more verbose output - with date info, there could be something like exa -ll (make the output more verbose if there are more -l args present).
I'm a big fan of this colorization. I like that I can quickly scan permissions, take note of the user, and figure out what kind of file I'm looking at. With regular 'ls', I usually have to do a double-take on all of those.
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.
I agree with your main thesis that colour adds information.
But not with your reaction to colourblindness - it's surprisingly common. We changed a grid of clickable red/green squares to add crosses and ticks after a chance comment, and several more users bothered to contact us about how much easier it made the UI.
So please DO give a... fig... about colourblindness - if it's worth adding colour to help users, surely it's also worth a little thought about how to cater for colourblind people. In this case, a grey-scale palette perhaps?
ow my eye sockets hurt! I always love when I get punished for something of a genetic and physical nature that I had absolutely no control over whatsoever!
but in all fairness, other than what you had to say about colorblind people, I more or less agree with your other words and claims. but seriously: i didn't choose to be colorblind and I honestly do hate it sometimes.
I am mildly colorblind but fortunately this does not impact my life too much. There are exceptions though :
- when I was maybe 12 the ophtalmologist told my father in from of me that I should forget about engineering and science in general. Take it dumbass, I am an engineer and PhD in physics (I had to let this out one day :))
- I was shopping for school supplies this morning and had to ask someone to help me choose the copy books so that they are of various colors and not pink. She was surprised at first but then we ended up with a nice talk.
- I reflashed a router 5 times as the flashing was failing, the LED was red. My brother was walking by and told me it is actually green, ending my agony. The router survived.
- a support guy flew cross country once to support my switches which were failing. As you can imagine they were not, I thought that the LEDs were red but they were green (maybe the ophthalmologist was right after all. Still a dumbass for saying this in front of a pre-teen geek who could have listened and go for liberal arts)
- my boss (a lady) told me that I wear interesting color combinations. I thought I was always wearing a combinaison of beige and pale blue. I was not.
I haven't used it yet, but the colored screenshots look way more usable than standard ls. Personally I don't think it id conflicting and confusing at all.
The screenshots also show that the color palette is designed solely for black-background terminals. It will be useless on white or grey, perhaps passable on blue.
Tell me. I am curious to know if use a text editor without syntax highlighting.
Seems to be the case that there is no modern text editor that doesn't color every single word. Must be so hard for you now that you're forced to use these tools with such "poor usability and design". How do you even manage?
That's partly the reason why I tend to avoid software with "modern" in its description... but more seriously, I don't care much for syntax highlighting --- I can put up with it (unless the colours are too distracting), but I do prefer monochrome text.
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.
> 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.
I'm not certain if it's exactly what you're getting at, but less can be instructed to parse ANSI color sequences, and output them, with the -R flag. (If you forget to put -R on the command line, or some utility automatically starts less for you, you can also type "-R" while in less to trigger that behavior.) That said, less has to be fed the sequences, and most programs will not output color sequences when piped to less, as they detect that the output isn't a TTY (this is normally the right thing to do, it just kinda sucks in less's case) so you might need to, e.g., that_prog --color=always | less.
> There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
Yeah, this is the real problem. I kind of wish there was some sort of content negotiation between piped utilities, s.t. less could inform the upstream utility of "hey! I speak ANSI color codes!".
What follows is definitely well into the "WTF too clever" column and I do not recommend it, but, this is HN: I presume you could riff through /proc trying to find the other end of the pipe that you're writing to (I think /proc on Linux has that) and then, if the executable's name is "less", well, you see where I'm going…
That's where you need something like PowerShell, which pipes objects around instead of streams of bytes which are probably text.
Of course, PowerShell has its own issues, but the idea of a shell with more meaning attached to things is appealing. Rebuilding an ecosystem that can handle it all though... not so plausible!
I don't know if exa does this, but most command line tools disable colorized output automatically if they determine that stdout is not an interactive terminal.
Seems like it comes on by default in Ubuntu/Debian based systems for bash. Also, if you want to see the file sizes in MB, KB etc. then use 'ls -lh' command.
It's not exactly the same though. LS_COLORS only colours file types (whether it's a file, dir or symlink) and permissions, while exa appears to also set the colours based on the mime type (text, image, etc.).
Specifically, you list which extensions should get what colors. So it's more like telling ls "Color anything ending in .jpg or .gif in red", as opposed to "Color all images red".
> For example, exa prints human-readable file sizes by default (when would you not want that?)
When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.
That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.
To be fair, you're ignoring the "by default" part. Yes, when you want to see uniform units, you can add a command line argument.
HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.
I'm not ignoring the "by default" part; it's the crux of my complaint. There's a reason that I included that part of the text when I quoted it, after all. I perfectly understand that exa has a "-B" option.
> HN is so predictable that I knew someone would complain about this the second I read it
And I considered there'd be a pretty good chance that I'd get a reply like this.
I think it's obvious that you're bikeshedding minor parts of my comments. As I originally stated, the whole thing is a "silly nitpick" about something that I (quite honestly) only have a weak preference toward.
So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.
My problem is that I like having full and exact file sizes, and I like that they really make order-of-magnitude differences stand out in a listing (by taking up an extra column); but if I look at a number longer than five or so digits it's difficult to quickly see how many digits it is, and hence my quick glance can be off by an order of magnitude.
In a program that natively makes strong use of colour, though, here's an option: print exact file sizes, but in two related colours (say, bright yellow and dark yellow/brown), as follows: the first colour for the first 1, 2, or 3 digits, and the other for the remaining $n$ digits where $n$ is divisible by 3. That way the first colour will represent a whole number of KB, MB, GB, etc—and which of these it is will be very clear as it's easier to get that rough-count size—and the fainter/darker colour would give the full exact number of bytes. Best of both worlds!
Or just use ls -l --block-size=\'1 (make sure your locale is set properly). This way not only your interactive output is fixed, but also any place where it's redirected to text.
Thank you! I couldn't live without the alias I use for ls, which specifies BLOCKSIZE with the tick. Now I am going to add TIME_STYLE, which I didn't know about but I love already.
The rendering of time in any format other than ISO-8601 is a pet peeve of mine. It always baffles me why people do it.
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:
If they differ by orders of magnitude, then the difference is visually obvious when the full digits are printed out --- sticking out like the proverbial sore thumb. If they're compressed into units, you have to do some more mental multiplication and comparison.
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.
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 to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.
I think what's really in discussion here is what the default should be. ls was originally conceived and implemented in a period when all the files you would be dealing with could be measured in bytes easily, and would almost never be over four digits. Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits, and at that level it's very easy to lose track of a digit or two, which is misjudging by an order of magnitude or two.
Human readable units helps quite a bit with this, and I think that makes it a sane default. As long as you can specify you want to see bytes, and the sorting is done on the actual byte value, there's little lost because the majority of the time it will help rather than hurt.
Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.
People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.
> People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly.
Actually, many of the utilities that output in human readable format do so in a way that's also sortable through sort's -h option. It might be worth making sure you have a mode that outputs the same way so people can easily utilize sort. That is, K/M/G instead of Ki,Mi, Gi. Unless sort ignores the second alpha character when using -h and it still works, then no problem. :)
Edit: Actually, I just tested, and at least as of the sort in coreutils 8.4, it recognizes both forms, and actually dies with a warning if you mix them, so you're all good!
# echo -e "100Mi\n100Ki\n10Mi\n10Ki" | sort -h
10Ki
100Ki
10Mi
100Mi
# echo -e "100Mi\n100Ki\n10Mi\n10K" | sort -h
sort: both SI and IEC prefixes present on units
Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits
I think your perception of filesizes is slightly skewed; "nine or more digits" means roughly >=100MB. Disk images, software, and videos would be in that range, but probably not the average MP3 (100MB of 320k MP3 is over 40 minutes), and I don't think I've ever handled a "word processing document" more than a few dozen MB --- and even that would already be many hundreds of pages.
Of the files sitting on my desktop at the moment, which is not necessarily representative nor typical but covers a wide range of types (pdf, mp3, zip, exe, jpg, mp4, ...), slightly more than 10% are 10MB or more (8 digits), ~15% have 7 digits (1-9MB), and the rest are below 1MB (<= 6 digits).
You're right. I was off by an order of magnitude or two. Not that I planned it, but I just illustrated my point with sizes of seven digits or more with myself as the subject.
Seven digits isn't quite as bad, but without thousands separators it's bad enough.
I think you mean 6 or more digits? I have yet to see a multigigabyte document. Even mp3s that size are extremely rare.
Even then, most of my documents are quite a bit smaller, as I have a tendency to write my documents in wordpad instead of office, and then save as rtf or txt.
I meant seven or more, see the sibling comment. Seven digits is a megabyte or more. That encompasses most single song mp3s, some medium to large size documents, etc.
I'm not sure why I said nine, seven is what I was thinking of.
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.
But unless they are differently colored, if you are looking at a column of 50 numbers, all 100-500 except only two of them have an "M" suffix and the rest have "K", it is very easy to miss. From experience with "du -h" which I rarely use anymore because of this,
Indeed, but you are speaking of relativity on a smaller scale. The problem is, at a glance, seeing 990KB flash by next to 1MB, you will mentally categorize them very differently.
I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
> You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important.
Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.
I came here to make exactly this comment but you read the post much sooner than me.
At least I learned that ls had a -h option. I don't know why I should use it on files but I routinely do df -h to check the size of file systems. That's a place where it is useful.
also, human readable is sort of a misnomer here. it's not that hard for me to count digits, and that gives a much better sense of scale than having to scan manually for Ms and Gs
It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'.
I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24'
Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandline tool, as I'm a big fan of 'ripgrep', another popular tool written in Rust.
> such as showing directory size, which would be a killer feature.
'ls' (and 'exa') is nice because it's pretty fast. If I'm going to use 'du', I'm wading in with the assumption that it'll take a while. It'd be a cool option to add, but I don't think it should do it by default.
On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.
In my case the problem is I'm running out of disk space and need to find stuff to delete. So, `du -csh `. Wow, three huge directories. `cd dir1; du -csh `. Repeat. `du -d 3` would seem to be the solution, but it is pretty noisy. I really want something that prints all the "big" stuff in a tree, nicely indented and sorted by size. I end up using a KDE app ported to macOS that shows all the big files in packed rectangles, but can't remember the name.
Rust is my favourite language for code that has to run on end-users' computers. It's also my favourite language in general, but for that specific usecase it's leagues ahead of the competition in my opinion.
ripgrep is amazing. people are starting to do really cool stuff in rust (alacritty also comes to mind) -- it definitely makes me feel optimistic about the language. (i've never done more than just poke at it.)
This is cool, but it doesn't solve (in fact, exacerbates) my usual complaint with `ls` - I don't know what the arguments are. The example on the site is:
exa -bghHliS
Argh! I want to be able to say `ls --size` to get the file sizes. I don't want to remember a million arguments.
Colors are good...too many colors is overwhelming. It might be that I'd come to recognize what the colors mean if I work with it every day, in the same way that I begin to recognize the flow of a program and when a color is "wrong" after using the same syntax highlighting in an editor for a long time. But, I couldn't tell you what any of the colors mean in my favorite editors.
It's more about recognizing when something has the wrong color compared to everything else with that "shape". e.g. a good example is that in shell scripts, I often put space between the var name, '=', and the value. That's not an assignment and can lead to subtle bugs (shellcheck will catch it, too, but I see it clearly in the editor because it doesn't highlight as a variable declaration).
So, what I'm getting at is that I'm pretty sure I'll always have to read the actual text to make any sense out of this output; the huge number of colors may just hinder readability. I don't know this for sure, but it's pretty jarring to look at even with a nice muted color scheme. I love colors in terminals, though, so I'll give it a go.
Well it's too late to change now! It's one-handed, even on Dvorak, which is a bit annoying.
I don't think it's too much of an ask for people to define their own aliases for it, though. The overlap between people who install custom command-line tools and people who know how to edit their shell config can't be small.
If it was for the sake of usability, "asd" was far easier to type than "exa" where my fingers have to dance around when the name doesn't mean anything anyway.
annoyingly, on dvorak ls is typed with the pinky of the right hand for both characters, and then I usually use the same finger to press enter again after
exa can be typed by using three different fingers. Its not any significantly longer then ls which use two finger movement. Maybe even faster: I dont know what science tells us about such motions, but at my opinion fingers of one hand can be more precisely synchronized, so you really can do faster movements and lower delays between keypresses. Just try to use fingers 2-1-4 (index finger, than thumb, than ring finger) in that order, and you'll see. Or, when typing exa as part of larger text, you can use 3-1-4 sequence of fingers it allows to place palm in a way that allows fast movement into "exa" or out of it, keeping index finger free.
Is that how you actually type, or are you speculating? With regular home row typing, e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on three different rows. I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing. On the other hand, I know I've hit "sl" by mistake more than a few times.
> e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on three different rows.
Its because of the rules of blind typeing courses that says thumb should be used only for space? If you got such a courses more than a year before and already mastered blind typeing, than stop worrying. Just use thumb for `x`.
> I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing.
It got better with practice. Like blind typeing. All you need is to train you fingers for they do it without conscious effort of thinking. Are you play on some musical instrument? Try it, it teaches how to train your fingers.
My fingers are pretty well trained for typing - around 100 WPM, 120 on a good day. As I say, I've tried tweaking my technique for special cases, but it just makes typing more laborious for little or no gain.
It could be different for others. I saw a guy who could do 100 WPM with literally two fingers, although it looked exhausting. A year of waking up with my fingers locked, simultaneously numb and throbbing in pain, taught me that maintaining a relaxed flow is more important than those last 10 WPM. But that means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.
> things that can't be typed w/o moving your fingers from the home row are really easy to type.
That's why some people (like me) switched to Dvorak.
Your sentence on Qwerty was 43 top, 21 middle and 12 bottom row keypresses.
On Dvorak, it's 24 top, 45 middle and just 7 bottom row characters, twice as good!
"ithout" is also entirely home-row, so you wouldn't need to bother with "w/o". The word demonstrates Dvorak's other feature nicely, hand alternation and outward-to-inwards flow:
without
,gkjsfk (Qwerty equivalent)
RLRRLLR
The letter pairs typed with the same hand go smaller-to-big finger, since "th" (Qwerty "kj") is much easier to type than "ht" ("jk") -- and "th" occurs about 7x as often in English as "ht".
I tried colemack for a little while, and was able get to up to a slowish but bearable speed (I think around 65wpm iirc) for English sentences. And it definitely felt better and was tempting to keep going.
But I ran into a few things thay ultimately made me give it up.
Oke was emacs shortcuts — it turns out I mostly don’thave these memorized as letters, but just locations. So then trying to translate from location to querty to colemack was pretty brutal.
The other big problem is you’re instantly less efficient using anyone elses computer.
And a final one was programs that chose shortcuts thoughtfully for qwerty suddenly had really randomly chosen shortcuts.
I do kind of want to give it another shot though....
iirc, if your terminal emulator is doing something funny with the output of `ls` it's because they've re-implemented it as a function and are intercepting the call to ls and running their function instead, not because they're recognizing the output.
It's top row, bottom row, middle row, and the 'x' on a normal keyboard is half way to being directly under the 'e'. Very awkward and antithetical to the ideas of people who have designed keyboard layouts specifically for efficiency and ergonomics.
The only demographic that comes to mind which would find that hand position "natural" would be guitarists and other string players.
I've been playing stringed instruments for more than 10 years. The 'e' 'x' combination is probably the most spastic and slowest key combination on a qwerty keyboard. I type about 100 WPM, so typing exa doesn't take _that_ long. But it feels like it's at least 5 times slower than typing ls. Which would be really annoying for a command that you'd be typing all day.
There's only one problem with this thing: all the characters are on one hand with a qwerty keyboard! A bit more annoying than ls, where you can practically hit the keys simultaneously. (You want to nitpick the colors, do you? I'll show you what real bikeshedding is...) In all seriousness, though, it looks good.
I find quite funny that the author is so convinced that the use of colors is the "right default".
1) I'm colorblind so my view of colors is different from yours.
2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, one for - and a third one for the rest, nice!).
Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!
Sorry the colours aren't working out. One of the feature requests in exa's pipeline is the ability to customise the colours, so you could make everything use bold colours if it's too dark, or make more things the same colour if it's too garish. Would something like this make it usable?
Speaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).
Is the problem really that there are colors, or that the colors used don't work well for colorblindness? Do you find coloring that doesn't go afoul of your particular type of colorblindness still less useful than no coloring, or is it just that so often little attention is paid and an assumption is made that it's no worse than monochrome when in actuality it sometimes is?
I guess my real question boils down to if whether the author tried to make the default color profile at least not horrible in some respects for most colorblind users, would you still think defaulting to color is the wrong default?
From my experience as a colorblind person, the use of color to convey information falls into several categories.
1. It improves the presentation of information. The vast majority of colorblind can still see color. In this respect, we are no different from people who have normal color vision.
2. It has no impact upon the presentation of information. In these cases, the colors may not be distinguishable but there are other cues that convey information. I typically think of these cues as context. An example of context relevant to to exa is the column or character used to represent the information.
3. It degrades the information being presented. In addition to there being different types of colorblindness, each type seems to be variable. That is to say that most colorblind persons aren't actually blind to a particular color, they are simply less sensitive to that color. This means that they may be able to see a color if it is intense. Using colored text is really bad in this respect since it is typically less intense, likely due to a small number of pixels being illuminated. This reduces the legibility of text to varying degrees.
4. It makes information illegible. This is essentially the extreme version of case 3. This happens when the contrast is so low that color is the main distinguishing factor, so it may be nearly impossible to distinguish two adjacent colors (such as foreground and background colors for text).
Take anything that I say at face value. It is largely based upon personal experience. The only thing that I can say with certainty is that colorblind people see color differently. I suspect that people with normal color vision suffer from similar issues to colorblind individuals. It simply manifests itself in a standard way so that there are standard design methods to avoid it. Of course colorblind people throw a wrench into the works because their vision is calibrate in different ways due to their sensitivity to each color.
Does it not make sense for the colourblind person to adjust the colour definitions for their terminal, so all programs give acceptable output? Just as a myopic person may increase the font size.
I don't think it's colourblindness, but I have trouble reading ANSI blue, which xterm defaults to rgb(0, 0, 238). I've changed it to be a roughly Persian green colour rgb(0, 166, 147).
If I had the most common male colourblindness, I'd probably add some orange to the default reds.
Sure, I'm largely aware of how colorblindness works (my father is colorblind and my friend is colorblind and I've discussed it multiple times with each). I'm really looking for whether experiencially you, or the root comment, have experienced good color schemes that work well within the constraints you impose, and whether that alters the statement slightly from "it should not default to color" to "it should not default to color unless done well".
I understand that the answer may be different for different people in somewhat non-subjective ways, since there are different types of colorblindness.
In the case of text that means asking the question: does removing all color remove any information? If the answer is no, then a colorblind individual can use other cues. (While my prior post focused upon legibility, two different colors may look like the same color to me even when the text is perfectly legible.)
I would also suggest keeping the number of colors used to a minimum. More color combinations means more opportunities for problems and more difficulty in resolving those problems by setting a custom palette.
Finally, only use color when it adds value. The use of color to highlight different file types was useful. (The file extension still existed as a cue, which is great.) The use of color to highlight columns is just asking for trouble without adding value. It is not adding value because all of the elements in a column are the same color anyhow, so it adds the risk of reduced legibility without highlighting anything in particular.
Point 4 is the overriding problem. I have never been able to find a color scheme that works acceptable for text on light background and for text on dark background. It is virtually impossible to find a good pleasing and legible color scheme that works just on text on a light background.
I do not like this attitude one bit. exa isn't here to make money, it's here to list files; if somebody can't use the software, then that's one less member of the community and one less person who can offer suggestions, rather than a resource who wouldn't give me a return on my investment.
If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.
I see where you are coming from (you want your software to be used by as many people as possible), but this really isn't the pragmatic approach to this type of software.
For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor), because it makes sharing easier, or anything which I need to work with as part of a team (version control).
This is not that. File listing programs are local and isolated. My experience using some file listing program does not improve if more people use the one that I am using. In this case, it makes more sense to have exa or ls or whatever be the software that addresses 99% of use cases for the average user. Then, for the portions of the population with particular needs, you make software that is particularly tooled towards them.I am not colorblind, so having support for colorblindness just makes software more bloated.
tl;dr - I agree with your sentiment when it comes to programs that need/want "universality". This is not one of those programs and doesn't need to be.
Ah, I'm with you now. And yeah, I do agree that a line has to be drawn somewhere. exa would probably fail if used with a screen reader, or heck, it doesn't even work properly under Windows right now. That's a huge market I'm ignoring!
What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.
For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.
Expecting every single command-line application to support different colour schemes for colorblind people is insane, not because the effort it worthless, but you are asking it to be spent on the wrong level of abstraction.
I know that Gnome Terminal supports[1] different colour schemes which you can customise, and I think this is the point where it should be implemented at.
My trouble is that most terminals have color settings such that colored text is not very visible. I really wish I could have a large number of different-colored terminals for different tasks, and that is easy if I turn off color, as designing a whole color set that always works is a bigger job.
What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.
Another tricky thing is finding a colour set that works against various backgrounds. A ton of people use either black or white backgrounds. Occasionally you come across a different colour (eg: some people use red backgrounds for 'root' or 'production'), but even if you exclude these folks, getting something that works with both black and white backgrounds is a minimum requirement.
Every new terminal I open uses a random background color. All colored text is always readable.
What I did was make sure the background colors were always dark, and set the first 16 terminal colors to be light. I randomized the background color by specifing it to the terminal via a command line option as the output of this 10-line script[1] that takes an HSV Value as an argument and returns an RGB with randomized Hue.
It's nice for terminals to be differently colored when you have many of them open. It helps one to realize when you've switched to the right one.
iTerm2 lets you force a minimum contrast, which solves the contrast problem while still letting you use colors. Lots of programs display hard-to-see colors (red-on-black for me too), so it makes sense to address this problem at the terminal level.
> Sometimes an application will display text with a color combination that is hard to read. Colorblind users in particular may find certain combinations hard to see if the colors differ only in hue and not brightness. If you enable minimum contrast (under Preferences > Profiles > Colors > Minimum contrast, then iTerm2 will guarantee a minimum level of brightness difference between the foreground and background color of every character. If you set this to its maximum value, then all text will be black or white.
BTW, I actually like having the git hashes almost invisible. I don't need to see the hash, I just want to double-click to copy it.
The main problem I can think of is that I'm so used to type cd and then ls... But OTOH it's as simple to fix as alias ls=exa
EDIT:
"exa prints human-readable file sizes by default (when would you not want that?)"
I actually use bytes a lot for certain progress calculations.
Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory" (Ubuntu 17.04)
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.
For more paranoid folks, it would be nice to have a configuration option to forego the git features and thereby remove the need for linking in any networking code. :)
I wrote the original Homebrew formula for exa and remembered adding support for the Git-less install, so I was surprised to see it wasn't there anymore! Seems like it was removed in this version bump [1] — I'll open a PR adding it back in.
⋊> ~/Downloads ./exa-linux-x86_64 --version 15:26:40
./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
I've been aliasing "l" and "ls" to "exa" for years now. Aliases in your shell won't cause any problems, because any scripts you run won't follow the aliases and will just use ls normally.
Actually replacing the binary? That would cause so many problems!
Yeah, the 'cd' and 'ls' combo is so easy to type too. 'exa' feels more difficult since my left middle finger has to contort a little going from e to x.
The feature I'd be most interested in here is the integration with git, but I don't see an example on the site that demonstrates that. If the author is reading this, could you please add one? (Or maybe point it out, if I'm just missing it?)
You're right -- I missed it out! Could have sworn I put one in one of the screenshots, too...
In any case, I've been working on a new site for exa, with much better documentation and actual explanations for what the features are, and that has one in it. So you'll have to wait a bit longer I'm afraid. (I could link a screenshot here if you'd like one)
>although Rust is cross-platform, I don’t have a Windows machine to develop on...
Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes coughMacOScough)
A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies against the pain of using it.
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? :)
The developer in me jumps with joy when the existence of (us poor) devs on Windows is acknowledged and gosh, even prioritized ("no v1.0 before windows"). I'm a fan for you just saying that!
When I release a new version of exa, I upload the code and binaries to GitHub, and then someone else whom I have never met but very much appreciate takes it and publishes it to Homebrew, then a few days later I download and start using it.
It's the slowest file copy mechanism I've ever used!
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.
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.
I have an unreasonable and unquenchable hatred for developers who assume that their users have dark-background terminals. Honestly, the most insanely passionate contempt.
Drives me a bit nuts too, and I would disagree with some of the other things in this page as well (e.g. the preference for "human-readable" file sizes).
But there is a great joy in being able to release a new utility and say about it, "This is how it should work." It reflects your own desires, you understand it, you made the decisions that went into it and have actually thought about the alternatives. There's a delight there. It could be a sign of a piddling egotist, or of a developer who is excited about what real users get to see.
(I did this sort of thing once -- reimplementation of commonly-used, if more niche, thing + manifesto -- from more than 20 years ago: http://all-day-breakfast.com/wm2/)
My main hope for anyone doing this kind of thing is that not too many people actually use it. You don't want to get stuck supporting a tool like this for the world and its dog.
Nothing is more human readable than "123,456,789", so I think the problem is just the way you go about making them human readable. I couldn't agree more that lurching between B, kB, MB, and GB just because the file size changes it extremely jarring and disconcerting, and actually makes comparing the size much more difficult.
Doesn't look like it, but the github page [1] has screenshots on both light and dark backgrounds, and the colors appear to have been selected to work well on both light and dark backgrounds (like the Solarized color theme).
From the doc, it doesn't appear that colors are customizable, yet. Pull request? :)
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.
Personally, I didn't want to invest the time in color schemes when I was trying out a new terminal... however many years later, I like the terminal, but never cared enough. Most of the colors that show up are fine I guess (except the helpful serial over lan controller that manages to set the background and the foreground to the same color :( )
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 files all over your computer" to me, and exa's smaller than that.
Self-contained, portable, featureful, etc. There are plenty of other adjectives to say it's not huge or "download tens of megabytes of runtime and scatter files all over your computer".
For me, <64KB is small and <4KB is tiny. But then again, being aware of the demoscene, I've seen what can be done in those size categories... ;-)
> 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.
> 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'm not sure why you'd say that.
Of course, if you want to statically link something like Qt because it makes distribution easier for $reasons, then that's a different story. But that has nothing to do with Rust.
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 has a stable ABI that doesn't require everything be statically linked it's a rust problem.
Love the brigading the rust community always does btw. Apparently someone was triggered enough to go through my comment history downvoting.
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. Show me a similar rust library that can be dynamically linked to like this? A rust equivalent will have to either use a c interface or be statically compiled.
> 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?
Small correction: the performance difference between ripgrep and GNU grep on single large files isn't that great for common use cases. For some more complex cases involving Unicode (and specifically, predominantly non-ASCII files), ripgrep can do a lot better.
(That statement changes a lot if you're looking at another grep like BSD grep, or if you're directly comparing `grep -r pattern` with `rg pattern`, which is always subject to caveats, because the latter is doing some guesswork and parallelism where the former isn't.)
Well, I have to admit, it is smaller than a docker container of alpine Linux containing the ls binary! Still doesn't mean it's monstrously large for no good reason.
Why would I want to compare apples to oranges? Though admittedly in this crazy day and age someone has probably already reimplemented coreutils in node.js just because.
I have seen my fair share of javascript-based console applications. My guess is that the author tries to assure us that exa is no such thing but behaves reasonably for a console application (not gigantic, not incredibly slow) and makes his statements in that light.
I know the documentation is currently lacking -- I've been working on a better website that explains all the options and colours for a while now. It should be done Soon™
Looks very nice, I've been using K, which has some other cute features (https://github.com/supercrabtree/k), but I'll definitely add this to my arsenal.
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.
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.
This took me by surprise too. For some reason it isn't happening in the Vagrant VM I develop on, but now I've run it on my VPS, it's totally there! exa uses libgit2 which must be requiring it somehow.
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.
Right but with more colors (e.g. you can get small files to have their file size be in green and large files have their filesize in yellow - the scale of color tells you how big a file is) and the summary from git-diff --stat is nicely fitted into a single, small column.
Certainly not life changing, but after using it for a while, I can tell you that every time I'm on a machine that doesn't have exa, I feel so frustrated ls doesn't give me everything exa has. I often end up downloading exa on any machine that doesn't have it
The problem I see with these "modern" command replacements is 1) muscle memory and 2) I have to log into some old systems that simply will not have anything this "modern".
An alias in your favorite shell's .rc file solves the first problem. Better yet, you can throw it behind a test block to ensure you never get a command not found error:
test -f /usr/bin/exa && alias ls='/usr/bin/exa'
The second problem is solved by configuration management tools pushing out your desired tools to your entire environment.
Which work well until your "entire environment" is some new-fangled ARM/SuperH/(etc.) board, and your configuration management tool is x86_64-only and/or not-in-the-repo of the only distro specialized enough to support that new-fangled board.
Is this intended as a full on ls replacement? As in, does it respect the envvars such as lscolors? Will it silently ignore -h, or will it die violently?
>Is this a drop-in replacement for ls? No — exa has, in my opinion, much saner defaults than ls, so while the available command-line options are similar, they are not exactly the same. Most of the common options will work consistently, though. For example, exa prints human-readable file sizes by default (when would you not want that?) so ls -h no longer applies.
For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal breaker for many.
> I almost never use the human-readable file sizes.
Same here. I love the idea, and i keep trying to use human-readable sizes in every command which supports them. But it turns out they're much less scannable than numbers in a common unit. How long does it take you to see which of these files is biggest:
Human-readable numbers also break all sorts of useful things like sorting (unless you have some fancypants sort which understands them), calculating totals with awk, sedding them into an expression to evaluate with $(()), etc.
While there has been a influx in command line usage due to mac adoption (has actually been flat for a few years now) most people who find their way to a terminal at some point or another will find their way to ssh.
Also just because you have access to many systems it does not make you a server administrator. I have access to tens of thousands and I am not a system administrator.
Over the years of working with Linux the one thing I have learned that saved me many times and made me productive was to learn the defaults and use the tools that you will most likely find on all systems. If you don't you will find your self bumbling around and feeling lost if you ever log into a system that is missing your favorite modification / customization.
This is the exact reason I have held off on fully switching to something like zsh or fish as well. I have a few thousand servers and basically the only guaranteed thing is that they will have some version of bash or at least sh installed.
We shouldn't need complete backwards compatibility on a command that is completely new, surely? That would limit the amount of improvement that could be made dramatically.
Also, as a side note, why do you enjoy using machine readable file sizes over human readable? The latter, as chosen by their name, are meant to be easier to use for humans.
twic, replied to my original post and I think he does a good job of showing why the machine readable is preferred -- and why human-readable is not actually easier for humans.
I would also like to add to the case twic showed that often I am using ls to see if a file is growing. In human-readable format hides the actual size and rounds -- it could move 200 megs or more before the human-readable output is updated from 1G to 1.2G.
To address why backwards comparability is needed is because of muscle memory. Its not likely that this tool will be on every system I use. I don't want to have to think about what system I am on and what command I need to run. It would be nice to also be able to alias it to 'ls' as ls is way faster to type than eax -- all on the left hand makes it MUCH slower -- although I am sure there will be those who say different -- but they are wrong.
I think for scripting just using stat makes lot more sense than exa (or ls).
Of course alternatively exa could aim for that lovely ls-style experience and vary its output depending on isatty(), switching between human-readable and absolute numbers.
But a length in bytes is even better than human-readable: it's a graph (technically a histogram), so it can be scanned, which is even faster than reading. It's far faster to identify the smallest or largest file in a directory with standard ls. There are some times when I do want human readable, but then I typically want to specify the units, so I see everything in megabytes.
I really dig the very useful output, but I'd also muchly appreciate an `ls` compatibility mode. Thus, one could put something like `alias ls='axa --compat'` into .profile and wouldn't have to re-train their muscle memory. F.e., I'm personally using `ls -altr` very often, and `axa -altr` will yield me an error.
I used it now for a year (maybe more, I can't remember) and I find it fantastic. It's great, and I can't imagine using plain old ls any more. No matter what people say, I love it.
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).
For a command that gets typed as often as 'ls', choosing 'exa', which is typed with one hand only, even worse, with a repeated finger, is kind of a poor choice.
i know this may sound trivial, but I'd probably never use this just because typing exa is a lot more annoying than typing ls. The three letters are on the left side of the keyboard and on the three rows. Sure I could rename it to something I like, but then I won't be able to get used to it, because I won't be able to find it when I log on to other computers. It's a silly thing that has a serious impact on usability...
"Like an engineer deeply in tune with his machine, Exa feels the world's component error deep in his bones, fractionally before anything has literally gone wrong." — from Sam Hughes's Ra (https://qntm.org/ra)
It was originally going to be a command-line "file explorer" like ranger, and exa is kind of short for explorer, but I like this quote too.
While it's not the intention to replace the binary itself, I'm just not a fan of the idea of substituting system built-ins in everyday behavior. Stuff like cd, ls, etc. I like to keep it to the basics.
Even just with PATHs or aliases, or a new binary entirely.
And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), https://github.com/rupa/z.
A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.
The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.
Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.
In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, The Tao of tmux [2] (available free to read online).
So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:
export EDITOR=vim
Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:
export GIT_EDITOR=vim
Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:
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.
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"?
Put it this way: Think of it like a Socratic dialog. Just because a replacement for ls(1) may not be beneficial due to configuration and customization already being commonplace, isn't the same as saying the mere notion of a competing unix CLI tool is bad.
top(1) doesn't allow color configuration. I use htop(1), and like it.
ls(1) already has color customization via LS_COLORS and long-list format via -l in ls. And about 10+ other output options. It's quite flexible.
git status can be shown via `git status`, and via the PS1 in oh-my-zsh/pure.
> Nobody is going to use this to replace "ls" in scripts.
I'm concerned they will, and not recognize it. To beginner and novice shell users, it's easier to cargo cult stuff in and not know what's happening. And things will break in ways that's a nightmare for them to troubleshoot.
My gut instinct is being verified by comments in this thread mentioning alias'ing in exa as ls.
If anyone is silly enough to alias to exa, then their scripts will fail. A replacement doesn't have to be a drop in. Server admins who alias it will pay the price, so they won't do it.
Shell scripts break. If it's not a parity with ls(1), the output and arguments won't be compatible.
I forgot to add: Having colors / fancy output when you just want to pipe information around the shell is of no value.
IMO it goes against the spirit of what commands like ls are meant to do, and the behavior exa provides is better placed, and already done well, via shell configuration (e.g. oh-my-zsh, presto, pure)
i'm not going to be rude or hate exa, it looks really cool actually. I, for one, love the color coding. But trying to replace something as old and known as 'ls' probably isn't a realistic goal. I think talents would much better geared towards something missing, instead. Either way, keep up the good work.
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 column (which position varies) and then travel back to the beginning of the line and read the rest of the metadata
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 kind of blink or a meaningful animation and you'll have my attention. I may hate the tool for it, but you'll have my attention...
I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!
Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.