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.
If colored "ls" had been standard from the early days, I'd bet that people would be praising how useful it is, and wondering how can you live without it. But many *nixes still don't have it and people that made a life using them get into this "get off my lawn" attitude.
I can read the output of "ls" just fine without color. I use systems without colored "ls" daily. But... I find color in "ls" invaluable.
Color conveys information in a very unobtrusive way (if it isn't excessive). Much better to see blue text and knowing immediately that it's a directory, than looking at the permissions column or warts ("ls -F").
Actually, colorless "ls" makes the system feel old. It's the feeling I get every day when using AIX, for example. I just feel like changing the color scheme to green-on-black or amber-on-black just to feel like the old days.
Switching between many programs and systems, I have a hard time keeping track of what colors mean what. Especially when people start customizing their colors. There are enough tools to show you what a file is, I don't need directories printed in red and files in blue and symlinks in green. ls -l is good enough and works everywhere.
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)
It might be nice if it could obey LS_COLORS so it would match the output of ls.
But this is nice, combining it with micro makes for a dead-easy combo of single-file utilities that I can drop onto a server and more easily move about.
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'll give you an argument: it's difficult to read colored output, at least for me. Perhaps it is because I'm colorblind, idk, but the output of e.g. "ls" makes it hard to find certain files. The directory names get all fuzzy, and 'tgz' files scream. It takes much more effort to parse than uncolored output. And terminal colors are just garish, but that's a matter of taste.
> accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means
Yeah, we might not agree on that. That practice might be a tad overrated or overused. In some contexts it might make sense, but that doesn't mean any semantic difference should be expressed. E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? Why not color by file size? Or by age? How am I going to remember those colors? Plus, it's unusable in a script, because then "ls" suppresses the color.
But why argue (pretty harshly) against a proposal that won't affect the way you see the output? And why give such a weird, unfriendly option to remove color?
Personally I find many different colors confusing.
I've a wrapper script that highlights permissions etc. rather than using colors to distinguish them.
It also makes the output of ls consistent across linux/osx/solaris/... which it does by adjusting the output from the
existing ls implementations on each platform
I actually prefer my ls output to be monochrome, and the first time I encountered a coloured one I turned it off since some of the colours were nearly unreadable (who thought dark blue and gray on black was a good idea?)
You can customize LS_COLORS if you want, but I've never been mad at the defaults. Also, I prefer c-style escapes, which allows you to copy and paste the filename and use it in other commands:
alias ls='ls --color=auto -F -b -T 0 -A'
-F classify entries with (*/=>@|)
-b use c-style escapes instead of quoting
-T 0 do not use tabs for alignment
-A show all dotfiles except . and ..
Plus, I find colors to be insanely useful when my old eyes try to read 'ip' output, so I really do prefer:
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 :)
First thing I usually do on a new Linux system is dial down colors in “ls”. Default colors are ridicuously distacting and most don’t convey any new information. I like directories and symlinks highlighted. But the fact that a file is a .jpg or .tar.gz is sufficiently obvious from its name, without turning my terminal into a circus.
I similarly dislike the new trend of fancy command prompts. It’s a prompt, it should stay in the background.
My distro's ls already does coloring by default. It turns it off somehow if it detects the output is a pipe, so that "ls | less" still works. It also turns off multi-column in that case, so "ls | wc -l" counts directory entries.
> 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 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 this a lot. One thing I noticed is that on the video, the first change is on the background from green to red. As a deuteranomalous (color-blind) person, I really couldn't see the difference unless I watched really close while it happened (and didn't blink). A small thing, but that kind of thing can be slightly frustrating for us. At any rate, the other examples were helpful in giving a feel for the product.
On a philosophical level, I like how this should integrate well with the rest of the Unix utilities. It isn't as immediate and interactive as Bret Victor's examples, but I think this has the advantage that the code is actually there and it works. It's not the ideal system, but I suspect that it is an improvement over the status quo. I'll definitely be keeping an eye on this.
reply