Hacker News new | comments | show | ask | jobs | submit login
Exa, a modern replacement for ls (exa.website)
740 points by r0muald on Aug 3, 2017 | hide | past | web | favorite | 403 comments



Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls.

I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!

Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.


Wow, the comments in this thread are quite harsh.

I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.

Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.


Maybe. Whether the term "modern" was used or not, my hunch is that the response would be the same, for it is forbidden for one to deign to make these kinds of changes to fundamental Unix commands, and is tantamount to a kind of heresy (never mind that GNU implementations did this all the time wrt. original Unix implementations).

Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.


A lot of stuff depends on the basic Unix commmands though. It might be better to invent a new command name if the output differs in ways that would break both human and machine expectations. The difference between BSD and GNU versions of some commands is already enough to trip me up even after all these years. You expect `ls` to be `ls` on anything remotely POSIX/Unix-y.

I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.


Of course you hear the same complaints about GNU Coreutils. In general complaining about GNU-isms and GNU bloat is a time-honored tradition


Amen! (:giggles:)

I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think


I'd suggest describing it as a "colourful alternative" rather than a "modern replacement", because no-one will be removing /bin/ls with exa installed. "Replacement" strongly implies removal of the thing being replaced, as with "replacement hip", "replacement CEO" etc.

As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.


> because no-one will be removing /bin/ls with exa installed.

Why not? I would.


Yeah, that's the thing: built in gnu tools might be used by other tools/scripts/etc. - if you're ls isn't there or delivers unexpected output, they will fail miserably or cause havoc


No script should parse ls output, though. There are always better ways than parsing ls output.


The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides.

One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".

As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...


Let me quote that thing you linked to:

"As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space."

POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.


A shell glob cannot tell you the size, owner, permissions, timestamps of a file. For that .. oh look! There's ls(1). Which, by the way, spits out whitespace it sees just fine, unless you specified -q or implied it with output to a tty. If some code can't handle the result, it's that code that is broken. Tip: the only really problematic character is a newline; if you think you could be seeing those, you can still deal with it programatically, but I use find(1).

In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.


Alright, here's an example:

  touch 'file with spaces'
  for file in $(ls); do
    rm -- "$file"
  done
This will not work, because $(ls) will get expanded to three items, not one. rm will be called on the files "file", "with", and "spaces"...which is not what was intended.

Now do this:

  touch 'file with spaces'
  for file in *; do
    rm -- "$file"
  done
This works correctly.


  ls -Q
this will quote the file name for pipe operation


Still doesn't work.

  touch 'file with spaces'
  for file in $(ls -Q); do echo "$file"; done
This prints:

  "file
  with
  spaces"


xyproto, exactly my opinion too.


s/you're/your/


Given how half the comments are complaining about the colors and there's a whole thread on whether 3MB is "small" or not... I doubt it.


>I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today

For me, when I see people waxing poetically about the unix way and the old, crufty, POSIX userland, it's all about cargo cult, "that's how things have always been", minimum viable progress while keeping compatibility, and heritage-over-substance.


I did some nodejs work the other month, pinch-hitting in a product crunch, we're using grunt.

`grunt test`.. ooh, so pretty and creative! `grunt test > test.out`, wtf, why is my file full of control character bullshit?


To be fair, they could avoid that by checking if stdout is a TTY or not.


That's an amateur hour mistake on their part, frankly. I hope they have a 'switch color off' flag.


Welcome to the JavaScript ecosystem.


Writing `ls` is the first thing I do when learning a new language.


Thanks for the kind words, everybody.

exa was my first Rust project and it just grew and grew.


It looks neat. You should include a link to the documentation on the homepage. After I saw the screenshot I went looking to see how easy it would be to change some of the colors before I installed it. I read down below that the colors are baked in:(

It would also be nice to see files owned by different users and some of the git functionality.


Nice! I just downloaded it here ... My suggestion is to include an option to list the hidden files (dot files) as well as some file sorting options in the next version of Exa. ;-)


Would you consider reflecting and writing about your experiences using Rust?


Don't be worried about the hate.

ls is a gold standard but that doesn't mean alternatives aren't interesting. Especially as a FOSS project in rust I find it fascinating.


Hah, interesting! Mine is writing a simple web server (sockets, IO, string handling) and an ultra-simple command line browser (args handling, 3rd party libs for URLs, HTML parsing, etc.)


And all along I thought I was creative for skipping "Hello, World" and going straight to "Hello, World" 10 times


I like to write chip-8 and other VMs to get a handle Of a new lang


Mine in similar, I implement an authoritative domain name server. I've done it in something like 20-25 languages now. The only language I've learned in the last decade I didn't write one in is ARM Assembly. I am not that "dedicated" (more like masochistic) enough to try to do one in assembly.


I tend to reimplement the Linux kernel from scratch a few times in every language and go from there onto the X server, desktop environment, networking stack, etc.


Github link? ;)


mine is doing everything in hackerrank in the new language


A friend of mine used to learn new languages by implementing Tetris in them.

Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.


Is it useful to learn how to do system calls and formatted output for the kind of programming work that you do?


You must have had an easy time with Ruby, then.

  #!/usr/bin/env ruby
  `ls`


You haven't written ls in Ruby, you've called ls with Ruby. Big difference!


It would be nice if it implemented the exact same set of command line flags as ls plus whatever else it does. That way I'd be able to use it as a replacement when I type 'ls', much as 'vi' fires up 'vim'.

Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.


oh great, but shouldn't it then also behave exactly like ls does, i.e. deliver the same output whenever a script of yours or somebody else calls ls and expects a certain output?

oh wait, I know what behaves exactly the same way: ls


If you're interested in learning Rust by watching someone work, the author did several long screencasts of himself working on exa: https://www.youtube.com/channel/UCoBjY7TeCXzOULdiE40Ig1w


Is this a trend? Learning by seeing someone write a program? Because I find it neat.


It is great to scratch an itch and make something behave exactly as you want it to be - kudos.

That said, this is very much not for me. Default-colorized is something I emphatically do not want; defaulting to relative units, ditto. It it were me, the first thing I would do is get rid of 'grid' display entirely - reading across just doesn't work for me. Etc.

More prosaically, `ls` is sort of like breathing for me - I do it so much during the average day that I don't even think about it. Can't say I immediately know every one of the switches, but probably 10 or so variants I use daily are pure muscle memory, and less frequently used things (extended attributes, symlink-deref options, etc.) I can remember without the man page.

So in that sense, `ls` is well into the same category as vi for me - I'm so accustomed to whatever warts there may be that switching would be much more painful than any efficiency gain.


Thanks for the kudos! It's absolutely mindboggling how many times I've decided to deviate from one of ls's default settings -- certain that the old way was inferior and outdated, and that the new way will be obvious and immensely popular -- only to find people have no idea why I'm doing things this way! I need the colours to help me scan the output; if I don't see human-readable units, I curse myself for forgetting the flag. But thousands of people don't like this, and it's usually a different set of features with each person, too. I would never have guessed I was so 'out there'!

ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.

(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)


I use colorized ls by default and get a bit peeved by how I have to jump through hoops to get that on OSX by default. If it works out. i'll probably alias "ls" to "exa" in the future.

That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.


> That said, the binary isn't self-contained (I know, I know)

It wouldn't be right if something didn't go badly wrong at the worst possible moment!


exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory


Interesting. Why does it need an HTTP parser?! Some accidental dependency maybe?


Looks like it has some form of git support, via libgit2. Dependency chain for that is probably where it came from.


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'.


> defaulting to relative units, ditto.

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).


  export TIME_STYLE=long-iso
I found this option whilst investigating why most locales were honoured, but en_GB still gave American (backwards) dates.

I also have this, for the thousands-comma display:

  export BLOCK_SIZE="'1"

  $ ls -on i*
  -rw-rw-r-- 1 1001     1,335 2017-06-16 14:31 icon-shelters.svg
  -rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
  -rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Block size: https://www.gnu.org/software/coreutils/manual/html_node/Bloc...

Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...


Thank you!


Oh and file sizes should all use the same unit for easy comparing (maybe default to MB).


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.


What's your proposed method for getting tailored, filtered output to your transient requirements, without expending so much effort as two keypresses?


I do not think I could have said it any better. Absolutely fabulous work to the developer. I am just not his userbase.


I might be in his userbase part of the time. It seems exa does have some features I'd find handy once in a while in addition to ls. I think "replacement" is going too far for me. Some of the subthreads talking about actually aliasing 'ls' to 'exa' sound to me like they're going to break some little-known features on their systems. I'm in the "potential supplement" camp I guess.


I am pretty much in agreement. I have no complaint about anyone who likes this and wants to use this, but it's not for me. I like utilities that do one thing. ls for listing files. find for finding files and traversing hierarchies. git for dealing with git repos. xargs and pipes and maybe other utilities if I need to glue things together.

If I want something fancy, I will use emacs dired mode as a filesystem navigator and magit for git repos.

And cynically, if this wasn't written in Rust I don't think it's on the front page.


I just noticed the tests and the incredible lengths the author went to in order to effectively test exa. It's really impressive. GNU coreutils ls has a pretty good test suite, too ( http://git.savannah.gnu.org/cgit/coreutils.git/tree/tests/ls ), but this goes well above and beyond the call for something so new.


This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.


The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.


(author here)

You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".

Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.

That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)


> Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".

I think the coloration is good, but I would have defaulted a bit differently in the permissions. I would have made all user bits green, all group bits orange, and all other bits red. Not only does this denote the possible security implications of the permissions, but it also maps well to what I'm usually looking for - what are my permissions, and being able to see all those quickly with green would be useful. As an added benefit, there wouldn't be as many per-character color changes in that section, so it would be less busy.

Awesome work, BTW. I love seeing interesting re-imaginings of old standby utils. I was actually thinking of doing my first real Rust project as a cat replacement. I was thinking of calling it calico. ;)


I really like a lot of the extra colors but I was also overwhelmed by the rainbow permissions. User, group, world are the organizing principle for me. World writeable is something I never want to have in my mind as similar to user writeable.


I like the colors, but I'd like to be able to configure what's colored and, more importantly, what gets bolded. For me, the bold stuff jumps out and can kind of push the non-bold stuff into the background, which makes scanning that stuff a bit harder. (In case you're wondering, I think I'd skip bolding the username and the owner perms.) Also, I think that setuid bits are probably worth bolding, because you probably shouldn't see them very often.


Thanks! Configurable colours are something I'd like to get done, too. About half the work has been done to achieve this -- none of the colours are hard-coded, they're all looked up from a big Colours value that gets passed around internally. This value just needs an interface so it's configurable by the user. I've been meaning to open it up to the community instead of just defining an ad-hoc EXA_COLO[U]RS environment variable, but y'know, time.


I'd settle for a flag that disables the rainbow perms, it seems to be a common gripe. It's nearly a dealbreaker for me. But, that's personal preference - congrats on a great util.


Cheers. Yeah, most of the comments on the colours have mentioned the permissions column in particular!


I feel your way too. Colours can add valuable information when done right.

Don't feel too let down by the comments on HN. Awesome work!


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).

Just some ideas, maybe you like some of them :)


I'm a big fan of this colorization. I like that I can quickly scan permissions, take note of the user, and figure out what kind of file I'm looking at. With regular 'ls', I usually have to do a double-take on all of those.


I heavily rely on colorization to read what I need to on the terminal. I pipe almost all of my logs through ccze by default. Thanks for this great tool -- installing.


[flagged]


We've banned this account for violating the site guidelines.


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?


> You're colorblind? Well, fuck you right in your colorblind eyeball sockets.

Be civil or don't comment.


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.

Related: http://www.linusakesson.net/programming/syntaxhighlighting/


Did he seriously just throw random colors on random words and compare that to syntax highlighting?


I like color formatted text if possible, but more so just for keeping columns in a tabular output more easy to tell apart.

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.


I sometimes use lolcat, just because I like colour. I just find it helps cheer up a little bit. I guess it is just personal preference..


I also don't like colorized output - for instance, what if you want to pipe stdout of a process to Slack? You will get bash control characters.


It does the sane thing when it detects the output is being pipped and doesn't output the color controls.


Great! Where are my colours in `foo | less -SR' on the terminal?

It's not "the sane thing" to differentiate output on STDOUT's attributes. grep doesn't have the --colour option ternary for nothing.


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!


>> grep doesn't have the --colour option ternary for nothing.

> 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.


Oh, I completely missed that word. My bad.


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.


I set up $LS_COLORS like 15 years sgo in my .zshrc… and haven't had to touch it since. Doesn't seem like a huge deal worth replacing it over.


Seems like it comes on by default in Ubuntu/Debian based systems for bash. Also, if you want to see the file sizes in MB, KB etc. then use 'ls -lh' command.


It's not exactly the same though. LS_COLORS only colours file types (whether it's a file, dir or symlink) and permissions, while exa appears to also set the colours based on the mime type (text, image, etc.).


I'm pretty sure ls does this as well. At least for images and archives


Specifically, you list which extensions should get what colors. So it's more like telling ls "Color anything ending in .jpg or .gif in red", as opposed to "Color all images red".


> For example, exa prints human-readable file sizes by default (when would you not want that?)

When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.

That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.


To be fair, you're ignoring the "by default" part. Yes, when you want to see uniform units, you can add a command line argument.

HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.


I'm not ignoring the "by default" part; it's the crux of my complaint. There's a reason that I included that part of the text when I quoted it, after all. I perfectly understand that exa has a "-B" option.

> HN is so predictable that I knew someone would complain about this the second I read it

And I considered there'd be a pretty good chance that I'd get a reply like this.


"""When I've got two similar but non-identical files, and I think that the difference between their sizes might be important."""

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.


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.


I'll repeat this here:

  export TIME_STYLE=long-iso
  export BLOCK_SIZE="'1"
The first option gives ISO dates, the second the thousands separator. You need a locale for a thousands separator, en_GB here:

  $ ls -on i*
  -rw-rw-r-- 1 1001     1,335 2017-06-16 14:31 icon-shelters.svg
  -rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
  -rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Block size: https://www.gnu.org/software/coreutils/manual/html_node/Bloc...

Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...


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.


Sadly not supported by BSD ls.


True, but if you "pkg install gnuls" and set up an alias, you can get gnu ls transparently.


If it turns out you like it, you can use it as a direct replacement for ls by using alias:

    alias ls=exa
If you put that in your bash profile, it will be permanent (until you remove it from your bash profile, of course).


And if you want actual ls, you can just:

  command ls


Or even:

  \ls


I agree. Relativity is important - uniform units.


You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone.

If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.


If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone.

I disagree; what's easier, spotting the biggest and smallest of these at a glance:

        6,677,967
        5,916,109
        7,164,551
    3,745,059,597
            3,175
        4,194,304
        3,550,137
or these:

    6.37M
    5.64M
    6.83M
    3.49G
    3.10k
    4.00M
    3.39M
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.


For this reason when I list in -h mode I pretty much also need to sort by size (ls -lSrh).


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.


You hit the nail on the head!

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.


Maybe we could split the difference between precision and readability by using scientific notation?

How does 524404648 vs 5.24404648e8 look?


Well all of that is just a matter of how many significant digits to print. You can print "1.873554727 GB". Its ugly as hell. But at least I can mentally truncate everything after the period without having to count the digits.


But unless they are differently colored, if you are looking at a column of 50 numbers, all 100-500 except only two of them have an "M" suffix and the rest have "K", it is very easy to miss. From experience with "du -h" which I rarely use anymore because of this,


Indeed, but you are speaking of relativity on a smaller scale. The problem is, at a glance, seeing 990KB flash by next to 1MB, you will mentally categorize them very differently.

I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.


> You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important.

Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.


I'd also consider things like piping to awk or finding the largest files in a set of directories. Human readable sorting is much more complex.


Isn't there `sort -h`?


It's almost as if people used these tools together enough, that they made an effort to make them work well together. ;)

Seriously, "du -h | sort -h" is a regular command for me.


If you do it quite a bit you may want to check out ncdu, it is an ncurses directory size viewer. Super handy and fast for what it does.


curses is actually less useful to me. It's often mixed with a grep and a head or tail with a tee.


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.


a thousands separator is a good middle ground


also, human readable is sort of a misnomer here. it's not that hard for me to count digits, and that gives a much better sense of scale than having to scan manually for Ms and Gs


It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'.

I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24'

Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandline tool, as I'm a big fan of 'ripgrep', another popular tool written in Rust.


> such as showing directory size, which would be a killer feature.

'ls' (and 'exa') is nice because it's pretty fast. If I'm going to use 'du', I'm wading in with the assumption that it'll take a while. It'd be a cool option to add, but I don't think it should do it by default.


> I hate using 'du'

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.


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.


What you're looking for is

  du -hc | sort -hn | tail
No need to visit subdirectories. Throw in a tee /tmp/du.out before the tail to make your life easier.


Ncdu is a command line application that does this (a tree with sizes)


Probably KDirStat / WinDirStat / Disk Inventory X


I have the same issue with the same solution. It’s called Disk Inventory X on macOS.


I think in a lot of cases it's kind of nice to just get this all in one command.


hmm, but is it important that the small tools are actually developed separately? or just that you can call them separately?

An example would be busybox, which can decide which executable to pretend to be by the target name.


Rust is my favourite language for code that has to run on end-users' computers. It's also my favourite language in general, but for that specific usecase it's leagues ahead of the competition in my opinion.


ripgrep is amazing. people are starting to do really cool stuff in rust (alacritty also comes to mind) -- it definitely makes me feel optimistic about the language. (i've never done more than just poke at it.)


This is cool, but it doesn't solve (in fact, exacerbates) my usual complaint with `ls` - I don't know what the arguments are. The example on the site is:

    exa -bghHliS
Argh! I want to be able to say `ls --size` to get the file sizes. I don't want to remember a million arguments.


Completely agree. If the author wants it to be a better alternative to ls, it should have better default. I.e. -bghHliS should be the default options.


I guess everyone has their preferences. exa -bghHliS is too much info for me. I agree there should be a shorthand for "give me everything" though.


Yes, it's probably too much. But what's shown by default is too little for me.


This is what aliases are for.

    alias exa-size='exa -bghHliS'


I love it, but it's also kinda angry fruit salad.

Colors are good...too many colors is overwhelming. It might be that I'd come to recognize what the colors mean if I work with it every day, in the same way that I begin to recognize the flow of a program and when a color is "wrong" after using the same syntax highlighting in an editor for a long time. But, I couldn't tell you what any of the colors mean in my favorite editors.

It's more about recognizing when something has the wrong color compared to everything else with that "shape". e.g. a good example is that in shell scripts, I often put space between the var name, '=', and the value. That's not an assignment and can lead to subtle bugs (shellcheck will catch it, too, but I see it clearly in the editor because it doesn't highlight as a variable declaration).

So, what I'm getting at is that I'm pretty sure I'll always have to read the actual text to make any sense out of this output; the huge number of colors may just hinder readability. I don't know this for sure, but it's pretty jarring to look at even with a nice muted color scheme. I love colors in terminals, though, so I'll give it a go.


exa is hard to type, bad choice of name for something I'd be typing many times a day


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.


  alias asd=exa
I already have

  alias h=ls
  alias hh='ls -l'
  alias lrt='ls -lrt'
  alias lrta='ls -lrta'
(The first two because I use Dvorak, in which case I'd use 'aoe' instead of 'asd'.)


I thought the same at first. ls is good mnemonic for list, but what exa stands for and why three letters?

"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.


Furthermore, l and s are typed with different hands, which makes it quite fast to type. Exa is all left-handed, so it takes even longer.


annoyingly, on dvorak ls is typed with the pinky of the right hand for both characters, and then I usually use the same finger to press enter again after


exa can be typed by using three different fingers. Its not any significantly longer then ls which use two finger movement. Maybe even faster: I dont know what science tells us about such motions, but at my opinion fingers of one hand can be more precisely synchronized, so you really can do faster movements and lower delays between keypresses. Just try to use fingers 2-1-4 (index finger, than thumb, than ring finger) in that order, and you'll see. Or, when typing exa as part of larger text, you can use 3-1-4 sequence of fingers it allows to place palm in a way that allows fast movement into "exa" or out of it, keeping index finger free.


Is that how you actually type, or are you speculating? With regular home row typing, e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on three different rows. I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing. On the other hand, I know I've hit "sl" by mistake more than a few times.


> e-x-a is 3-4-5, which are the hardest fingers to "drum", and even harder on three different rows.

Its because of the rules of blind typeing courses that says thumb should be used only for space? If you got such a courses more than a year before and already mastered blind typeing, than stop worrying. Just use thumb for `x`.

> I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing.

It got better with practice. Like blind typeing. All you need is to train you fingers for they do it without conscious effort of thinking. Are you play on some musical instrument? Try it, it teaches how to train your fingers.


My fingers are pretty well trained for typing - around 100 WPM, 120 on a good day. As I say, I've tried tweaking my technique for special cases, but it just makes typing more laborious for little or no gain.

It could be different for others. I saw a guy who could do 100 WPM with literally two fingers, although it looked exhausting. A year of waking up with my fingers locked, simultaneously numb and throbbing in pain, taught me that maintaining a relaxed flow is more important than those last 10 WPM. But that means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.


maybe i'm typing wrong, but i want to hit "e" and "x" with the same finger, which makes it way slower to type than ls.

things that can't be typed w/o moving your fingers from the home row are really easy to type.


> 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....


"exa" probably stands for "examine", though I don't know for sure.


+1. ls (or ll) is a more tangible name. a frequently used command is best to reside on the middle row of the keyboard.

Also I've noticed terminal emulators (like terminator) recognize output and sprinkle in formatting on the display.


>terminal emulators (like terminator) recognize output

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 usually alias 'ls' to 'l' anyway, so it would not be a big deal to alias 'exa' to 'l'. I agree that exa is not exactly memorable.


Just think "examine" rather than "list" and you'll be fine.

But yeah, alias ls=exa also works.


You typically would alias replacement scripts.


Well, it can be typed easily with one hand. At least it has that going for it


"easily"

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.


The author could change the name to pls (pretty ls). Still easy, confortable and differentiates it from ls, while maintaining proximity.


    export pls=exa


But the tool is all about its sensible defaults (which I find justifiable).


'xa' is available on my system. Who is working on the PR?


Switch to dvorak and you'll find that 'exa' is noticeably more convenient than 'ls' :-)


You can just use an alias.


alias it.


There's only one problem with this thing: all the characters are on one hand with a qwerty keyboard! A bit more annoying than ls, where you can practically hit the keys simultaneously. (You want to nitpick the colors, do you? I'll show you what real bikeshedding is...) In all seriousness, though, it looks good.


> There's only one problem with this thing: all the characters are on one hand with a qwerty keyboard!

They are also all on the left hand in both Dvorak and Neo.


I find quite funny that the author is so convinced that the use of colors is the "right default". 1) I'm colorblind so my view of colors is different from yours. 2) I find that any tool which use many colors suck: there will be a color combination which will be hard to read (for example git log: the sha1 keys are dark red on black, unreadable) but using just a few color is very nice (git diff: 3 colors, one for +, one for - and a third one for the rest, nice!).

Also I've seen two times that the color bytes broke something: an expect script was broken by grep's colors and colleagues of mine were very confused when two similar commands gave different output, the reason? Colors!

So colors by default? Thanks but no thanks.


Sorry the colours aren't working out. One of the feature requests in exa's pipeline is the ability to customise the colours, so you could make everything use bold colours if it's too dark, or make more things the same colour if it's too garish. Would something like this make it usable?

Speaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).


re: PuTTY, it seems so odd that its default blue continues to be the shade it is to this day. It is a nearly unreadable default.


What colour "blue" should be is something that isn't going to ever satisfy everyone.

* http://invisible-island.net/xterm/xterm.faq.html#dont_like_b...


On that subject, notice that Microsoft has made a big fanfare about how it has altered the colour blue in console windows.

* https://news.ycombinator.com/item?id=14915123


> So colors by default? Thanks but no thanks.

Is the problem really that there are colors, or that the colors used don't work well for colorblindness? Do you find coloring that doesn't go afoul of your particular type of colorblindness still less useful than no coloring, or is it just that so often little attention is paid and an assumption is made that it's no worse than monochrome when in actuality it sometimes is?

I guess my real question boils down to if whether the author tried to make the default color profile at least not horrible in some respects for most colorblind users, would you still think defaulting to color is the wrong default?


From my experience as a colorblind person, the use of color to convey information falls into several categories.

1. It improves the presentation of information. The vast majority of colorblind can still see color. In this respect, we are no different from people who have normal color vision.

2. It has no impact upon the presentation of information. In these cases, the colors may not be distinguishable but there are other cues that convey information. I typically think of these cues as context. An example of context relevant to to exa is the column or character used to represent the information.

3. It degrades the information being presented. In addition to there being different types of colorblindness, each type seems to be variable. That is to say that most colorblind persons aren't actually blind to a particular color, they are simply less sensitive to that color. This means that they may be able to see a color if it is intense. Using colored text is really bad in this respect since it is typically less intense, likely due to a small number of pixels being illuminated. This reduces the legibility of text to varying degrees.

4. It makes information illegible. This is essentially the extreme version of case 3. This happens when the contrast is so low that color is the main distinguishing factor, so it may be nearly impossible to distinguish two adjacent colors (such as foreground and background colors for text).

Take anything that I say at face value. It is largely based upon personal experience. The only thing that I can say with certainty is that colorblind people see color differently. I suspect that people with normal color vision suffer from similar issues to colorblind individuals. It simply manifests itself in a standard way so that there are standard design methods to avoid it. Of course colorblind people throw a wrench into the works because their vision is calibrate in different ways due to their sensitivity to each color.


Does it not make sense for the colourblind person to adjust the colour definitions for their terminal, so all programs give acceptable output? Just as a myopic person may increase the font size.

I don't think it's colourblindness, but I have trouble reading ANSI blue, which xterm defaults to rgb(0, 0, 238). I've changed it to be a roughly Persian green colour rgb(0, 166, 147).

If I had the most common male colourblindness, I'd probably add some orange to the default reds.

https://en.wikipedia.org/wiki/ANSI_escape_code#Colors


Sure, I'm largely aware of how colorblindness works (my father is colorblind and my friend is colorblind and I've discussed it multiple times with each). I'm really looking for whether experiencially you, or the root comment, have experienced good color schemes that work well within the constraints you impose, and whether that alters the statement slightly from "it should not default to color" to "it should not default to color unless done well".

I understand that the answer may be different for different people in somewhat non-subjective ways, since there are different types of colorblindness.


I would rather see color done well.

In the case of text that means asking the question: does removing all color remove any information? If the answer is no, then a colorblind individual can use other cues. (While my prior post focused upon legibility, two different colors may look like the same color to me even when the text is perfectly legible.)

I would also suggest keeping the number of colors used to a minimum. More color combinations means more opportunities for problems and more difficulty in resolving those problems by setting a custom palette.

Finally, only use color when it adds value. The use of color to highlight different file types was useful. (The file extension still existed as a cue, which is great.) The use of color to highlight columns is just asking for trouble without adding value. It is not adding value because all of the elements in a column are the same color anyhow, so it adds the risk of reduced legibility without highlighting anything in particular.


Point 4 is the overriding problem. I have never been able to find a color scheme that works acceptable for text on light background and for text on dark background. It is virtually impossible to find a good pleasing and legible color scheme that works just on text on a light background.


Congratulations! You are part of the roughly 4.5% of the global population with colorblindness.

Applying your physical shortcomings to a project when you are by and large the minority makes very little sense.

If `ls` is better for you, use `ls`.


I do not like this attitude one bit. exa isn't here to make money, it's here to list files; if somebody can't use the software, then that's one less member of the community and one less person who can offer suggestions, rather than a resource who wouldn't give me a return on my investment.

If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.


I see where you are coming from (you want your software to be used by as many people as possible), but this really isn't the pragmatic approach to this type of software.

For certain products, this approach makes sense. Generally, this approach works for "any software where more adoption means a better experience for an individual user". Examples: a messaging app, anything with its own format (like a word processor), because it makes sharing easier, or anything which I need to work with as part of a team (version control).

This is not that. File listing programs are local and isolated. My experience using some file listing program does not improve if more people use the one that I am using. In this case, it makes more sense to have exa or ls or whatever be the software that addresses 99% of use cases for the average user. Then, for the portions of the population with particular needs, you make software that is particularly tooled towards them.I am not colorblind, so having support for colorblindness just makes software more bloated.

tl;dr - I agree with your sentiment when it comes to programs that need/want "universality". This is not one of those programs and doesn't need to be.


Ah, I'm with you now. And yeah, I do agree that a line has to be drawn somewhere. exa would probably fail if used with a screen reader, or heck, it doesn't even work properly under Windows right now. That's a huge market I'm ignoring!

What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.

For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.


Expecting every single command-line application to support different colour schemes for colorblind people is insane, not because the effort it worthless, but you are asking it to be spent on the wrong level of abstraction.

I know that Gnome Terminal supports[1] different colour schemes which you can customise, and I think this is the point where it should be implemented at.

[1]: https://i.stack.imgur.com/bw0y7.png


My trouble is that most terminals have color settings such that colored text is not very visible. I really wish I could have a large number of different-colored terminals for different tasks, and that is easy if I turn off color, as designing a whole color set that always works is a bigger job.

What's funny is that colored interfaces worked just fine on IBM 3270 terminals in the 1980s, as they did on PCs. I can't understand why we can't get it to work right in the 2010s.


Another tricky thing is finding a colour set that works against various backgrounds. A ton of people use either black or white backgrounds. Occasionally you come across a different colour (eg: some people use red backgrounds for 'root' or 'production'), but even if you exclude these folks, getting something that works with both black and white backgrounds is a minimum requirement.


256 colors is already the default in all modern Terminals, and 24-bit colour is configurable in most...

If your machine uses termcap/terminfo, type this to see how many yours supports.

  tput colors


Every new terminal I open uses a random background color. All colored text is always readable.

What I did was make sure the background colors were always dark, and set the first 16 terminal colors to be light. I randomized the background color by specifing it to the terminal via a command line option as the output of this 10-line script[1] that takes an HSV Value as an argument and returns an RGB with randomized Hue.

It's nice for terminals to be differently colored when you have many of them open. It helps one to realize when you've switched to the right one.

[1] https://github.com/jolmg/randcolor


iTerm2 lets you force a minimum contrast, which solves the contrast problem while still letting you use colors. Lots of programs display hard-to-see colors (red-on-black for me too), so it makes sense to address this problem at the terminal level.

From https://www.iterm2.com/documentation-highlights.html:

> Sometimes an application will display text with a color combination that is hard to read. Colorblind users in particular may find certain combinations hard to see if the colors differ only in hue and not brightness. If you enable minimum contrast (under Preferences > Profiles > Colors > Minimum contrast, then iTerm2 will guarantee a minimum level of brightness difference between the foreground and background color of every character. If you set this to its maximum value, then all text will be black or white.

BTW, I actually like having the git hashes almost invisible. I don't need to see the hash, I just want to double-click to copy it.


Yeah, let's all adapt to your physical deficits.


"I laugh at the author because i have different vision than everybody else"


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)


Why does a directory lister need an HTTP parser?


This binds to libgit2, which binds to curl. I believe that brings it in.


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. :)


There is one already; it's a cargo feature.


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.

[1]: https://github.com/Homebrew/homebrew-core/pull/13676


I am wondering that too, but FWIW `sudo apt-get install libhttp-parser2.1` will have you on your way.


Thanks, but I wanted to report it nevertheless because it says the file is self contained.


A bug was filed a week ago https://github.com/ogham/exa/issues/194


⋊> ~/Downloads unzip exa-linux-x86_64-0.7.0.zip Archive: exa-linux-x86_64-0.7.0.zip inflating: exa-linux-x86_64

⋊> ~/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.


> 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

Are you really sure you want to replace ls with exa? I can think of a dozen reasons it could cause trouble.


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!


It will definitely be easier to check it out this way.


Yeah, the 'cd' and 'ls' combo is so easy to type too. 'exa' feels more difficult since my left middle finger has to contort a little going from e to x.


The feature I'd be most interested in here is the integration with git, but I don't see an example on the site that demonstrates that. If the author is reading this, could you please add one? (Or maybe point it out, if I'm just missing it?)


You're right -- I missed it out! Could have sworn I put one in one of the screenshots, too...

In any case, I've been working on a new site for exa, with much better documentation and actual explanations for what the features are, and that has one in it. So you'll have to wait a bit longer I'm afraid. (I could link a screenshot here if you'd like one)


Yah there's git integration, re read site ctrl+f "git"


swift knows that. They're asking for an example of the output of exa in a git repo.


if you pass --long --git you'll have a column that shows git status.

using color to show git status in normal view would be much more interesting to me.


>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.


To the credit of both Microsoft and the Rust team, Windows has become a much easier platform to develop on than when that sentence was written!


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? :)


It's available as a library: https://docs.rs/termcolor/0.3.2/termcolor/


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!

PS: I develop on Windows


This is really cool - bringing the great treatment of `ack` to ls. And can confirm how fast it is!

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`


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!


You should buy that person a beer if you ever find out who it is.

Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll Mr Hyde :)


> The unix philosophy is a great idea, but it doesn't really lead to a good experience. Glad people are making more integrated tools!

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.


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.


That's got UX backwards. You'd want to minimize the effort user has to make, no?


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.


Does it take into account the background color of my xterm so things do not become unreadable?


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.


> "human-readable" file sizes).

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.


Cool windows manager :thumbsup:

Tilting my head every time I wanted to read a title, I didn't fancy though :)


Sounds a bit extreme, but I am always puzzled by people who think dark backgrounds are just fine. Light all the way for me!

What would people think if all web pages on the internet had ugly black backgrounds?


Oh, it's definitely extreme! It feels weird to feel so strongly about it. I should probably talk to a therapist about it.


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? :)

[1] https://github.com/ogham/exa


Yes, I was about to mention http://ethanschoonover.com/solarized

Worthy start for a default and you might want to contribute an exa config / env variable setting to solarized.


I have a zillion iTerm profiles configured with popular colour schemes for testing with both light and dark ones. You're covered.


Wow! That's a bold statement to make. I wish I get a chance to make such a statement to a user about a tool I made. A hat tip to you sir! :)


Nope - it's pretty unreadable in iterm2 for me - http://i.imgur.com/bKQwIdJ.jpg

Shame, the idea is pretty neat. If you can solve that issue, OP, I'd love to give it a proper try.


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 :( )


Because those colours never show up. I've never had a problem with readability till now.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: