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.
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.
> 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.
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 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 :( )
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.
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!
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)
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.
> 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 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 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).
Ignore what they all said. It's proven that adding 3 dimensions of color means the information entropy is at least trippled.
If you think about the terminal as a computer <-> interface, then it's pretty obvious that we're bandwidth limited by how much information you can fit onto the page. Any amount of improvement in that bandwidth are certainly welcome changes.
Niceties like having color-coded file sizes and filetypes will seem incredibly obvious in hindsight.
The naysayers today are the same people who were outspoken that a text editor with color syntax highlighting was "poor usability and design". Well then why the fuck does every single modern text editor today colors every single word and displays them in different fonts and styles?
You think these very people don't use syntax highlighting in their editors and explicitly turn them off? They should be denied from using them and rightfully so. But they will naysay and then utilize to their sole benefit, the very things they were so opposed to.
You can be assured, they are myopic morons, barely able to internalize what they see ahead of them, let alone envision with an open mind, the possibility that your fantastic work might actually benefit them while costing them nothing.
Colors are poor usability and design? Nope. Next? You're colorblind? Well, fuck you right in your colorblind eyeball sockets. Nobody gives a fuck about you. You deserve it. It brings me great joy in knowing that you are colorblind. Your life must be unfairly shitty isn't it? Great joy. Warms my heart. Next? 'exa' is too hard to type? Then don't type. Don't do anything at all in fact. You're too lazy and useless to accomplish anything worthwhile anyway. Stop consuming oxygen and occupying space. Better for everyone.
How about those points for counter-criticisms?
It's the nature of the distributions of populations that you will always find these people wherever you look. Gladly, they are easy to ignore. Listen only to those who offer constructive criticism and carry on with doing fantastic work. It is certainly appreciated by the other vast majority of people who are silent and greatly benefit from your work.
I've completely replaced ls with exa with an alias. It's a tool that I've recommended to every one of my coworkers along with fish shell. Now I only wish I had other posix tools of the same quality. Any chance you're writing other tools too? Would kill to have a total posix tools replacement with the same quality as exa.
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.
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.
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!
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.
> 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....
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.
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
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.
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.
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.
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)
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.
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.
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!
⋊> ~/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
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.
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.
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.
> 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.
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.)
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".
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.
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.
> 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.)
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... ;-)
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™
"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.
> 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.
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.
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.
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,
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.
> 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.
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.
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
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.
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.
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.
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.
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)
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.
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).
>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!
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.
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.
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.
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'.
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.
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).
419 comments
[ 7.5 ms ] story [ 693 ms ] threadwhich ls alias ls='ls --color=auto' /bin/ls
tree -L 2
git diff --stat
git status
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".
If you want, you can alias it to `ls` so you don't lose muscle memory.
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 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.
[citation needed] Lots of people using macOS and even Linux without being server administrators.
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.
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:
How about now: 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.FWIW GNU sort can sort by human readable units using the -h option.
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.
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.
When its being used as part of a script.
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.
When doing automated text-processing and wanting to easily do precise calculations, without having to deal with different units.
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.
Tilting my head every time I wanted to read a title, I didn't fancy though :)
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.
What would people think if all web pages on the internet had ugly black backgrounds?
From the doc, it doesn't appear that colors are customizable, yet. Pull request? :)
[1] https://github.com/ogham/exa
Worthy start for a default and you might want to contribute an exa config / env variable setting to solarized.
Shame, the idea is pretty neat. If you can solve that issue, OP, I'd love to give it a proper try.
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.
The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools!
Oh, and It's in homebrew already: `brew install exa`
Bit ironical, as ls already is pretty "non-unixy" and has way too many features tacked into it.
From purism point of view it would make more sense that ls would be just a list of files and let other utilities (stat, sort, etc) handle the rest.
It's the slowest file copy mechanism I've ever used!
Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll Mr Hyde :)
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)
Don't feel too let down by the comments on HN. Awesome work!
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. ;)
Just some ideas, maybe you like some of them :)
If you think about the terminal as a computer <-> interface, then it's pretty obvious that we're bandwidth limited by how much information you can fit onto the page. Any amount of improvement in that bandwidth are certainly welcome changes.
Niceties like having color-coded file sizes and filetypes will seem incredibly obvious in hindsight.
The naysayers today are the same people who were outspoken that a text editor with color syntax highlighting was "poor usability and design". Well then why the fuck does every single modern text editor today colors every single word and displays them in different fonts and styles?
You think these very people don't use syntax highlighting in their editors and explicitly turn them off? They should be denied from using them and rightfully so. But they will naysay and then utilize to their sole benefit, the very things they were so opposed to.
You can be assured, they are myopic morons, barely able to internalize what they see ahead of them, let alone envision with an open mind, the possibility that your fantastic work might actually benefit them while costing them nothing.
Colors are poor usability and design? Nope. Next? You're colorblind? Well, fuck you right in your colorblind eyeball sockets. Nobody gives a fuck about you. You deserve it. It brings me great joy in knowing that you are colorblind. Your life must be unfairly shitty isn't it? Great joy. Warms my heart. Next? 'exa' is too hard to type? Then don't type. Don't do anything at all in fact. You're too lazy and useless to accomplish anything worthwhile anyway. Stop consuming oxygen and occupying space. Better for everyone.
How about those points for counter-criticisms?
It's the nature of the distributions of populations that you will always find these people wherever you look. Gladly, they are easy to ignore. Listen only to those who offer constructive criticism and carry on with doing fantastic work. It is certainly appreciated by the other vast majority of people who are silent and greatly benefit from your work.
I've completely replaced ls with exa with an alias. It's a tool that I've recommended to every one of my coworkers along with fish shell. Now I only wish I had other posix tools of the same quality. Any chance you're writing other tools too? Would kill to have a total posix tools replacement with the same quality as exa.
Be civil or don't comment.
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?
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.
- 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.
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?
Related: http://www.linusakesson.net/programming/syntaxhighlighting/
Just clicked-through to see what you meant about `exa -l` and I agree. When individual characters have different colors that's just way too much.
It's not "the sane thing" to differentiate output on STDOUT's attributes. grep doesn't have the --colour option ternary for nothing.
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.
> grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.
Didn't I say that? Ternary. On, off, detect.
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…
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!
"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.
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:
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".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....
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.
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.
But yeah, alias ls=exa also works.
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.
Also I've noticed terminal emulators (like terminator) recognize output and sprinkle in formatting on the display.
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.
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.
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)
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.
[1]: https://github.com/Homebrew/homebrew-core/pull/13676
Are you really sure you want to replace ls with exa? I can think of a dozen reasons it could cause trouble.
Actually replacing the binary? That would cause so many problems!
⋊> ~/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
...yup.
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.
Why?
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.
An example would be busybox, which can decide which executable to pretend to be by the target name.
It's quite useful and fast
'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.
I suspected this would be total bullshit, and it is. Its small binary is a mere 3.4 megabytes. I wonder if I misinterpreted the "small" part.
Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949
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.
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.
You don't have to do anything, including publishing misleading comparisons.
> Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem.
Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64.
>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.
I explained how. Take it or leave it.
> If the size can be reduced then why isn't it done when you publish it?
Because it's not a big deal? The only people who complain about this are people debating holy wars on HN, as if the static vs dynamic trade offs haven't been well understood by now.
> Again, it was an example. Show me a similar rust library that can be dynamically linked to like this?
Rust's standard library.
(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.)
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.
I'd be willing to bet dynamic linking would get it much closer to that ballpark and wouldn't compromise the feature set or development.
ansi_term = "0.8.0"
datetime = "0.4.3"
getopts = "0.2.14"
glob = "0.2"
lazy_static = "0.2"
libc = "0.2.9"
locale = "0.2.1"
natord = "1.0.7"
num_cpus = "1.3.0"
number_prefix = "0.2.3"
scoped_threadpool = "0.1.*"
term_grid = "0.1.2"
unicode-width = "0.1.4"
users = "0.5.2"
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... ;-)
This is nearly impossible to implement securely.
Better don't run exa against untrusted directories.
Do not run "git" in untrusted directories. It is not hardened against that (as opposed to the network protocol).
That probably includes libgit2 unless it explicitly states the opposite.
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.
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.
If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
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.
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.
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!
How does 524404648 vs 5.24404648e8 look?
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).
Seven digits isn't quite as bad, but without thousands separators it's bad enough.
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'm not sure why I said nine, seven is what I was thinking of.
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 disagree; what's easier, spotting the biggest and smallest of these at a glance:
or these: 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.Seriously, "du -h | sort -h" is a regular command for 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.
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.
> 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.
Doesn't sound like a default case to me.
Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.
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!
Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...
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.
Couldnt all the dependencies be statically linked for max portability?
The GitHub issue offers a fix for Ubuntu: https://github.com/ogham/exa/issues/194
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:
http://man7.org/linux/man-pages/man5/dir_colors.5.html
edit: actually, BSD's ls(1) seems to be $LSCOLORS (https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1):
[1] http://www.jedsoft.org/most/
[2] https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-t...
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.
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)
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.
The name is the key field and so it should generally be the left-most column.
It makes sense to list the filename last IMHO.
For the "all the information" part, I've been using something like this:
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.
I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows 10 laptop to test on as well.
PS: I develop on Windows
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.
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 :)
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.
It wouldn't be right if something didn't go badly wrong at the worst possible moment!
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.
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 also have this, for the thousands-comma display:
Block size: https://www.gnu.org/software/coreutils/manual/html_node/Bloc...Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...