Exa, a modern replacement for ls
the.exa.websiteWow, 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:
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.touch 'file with spaces' for file in $(ls); do rm -- "$file" doneNow do this:
This works correctly.touch 'file with spaces' for file in *; do rm -- "$file" done
this will quote the file name for pipe operationls -QStill doesn't work.
This prints:touch 'file with spaces' for file in $(ls -Q); do echo "$file"; done"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'.
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?
> 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).
I found this option whilst investigating why most locales were honoured, but en_GB still gave American (backwards) dates.export TIME_STYLE=long-isoI also have this, for the thousands-comma display:
Block size: https://www.gnu.org/software/coreutils/manual/html_node/Bloc...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 ixTime 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).
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.
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:
The first option gives ISO dates, the second the thousands separator. You need a locale for a thousands separator, en_GB here:export TIME_STYLE=long-iso export BLOCK_SIZE="'1"
Block size: https://www.gnu.org/software/coreutils/manual/html_node/Bloc...$ 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 ixTime 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:
If you put that in your bash profile, it will be permanent (until you remove it from your bash profile, of course).alias ls=exaAnd if you want actual ls, you can just:
command lsOr 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:
or these:6,677,967 5,916,109 7,164,551 3,745,059,597 3,175 4,194,304 3,550,137
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.6.37M 5.64M 6.83M 3.49G 3.10k 4.00M 3.39MThat 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
No need to visit subdirectories. Throw in a tee /tmp/du.out before the tail to make your life easier.du -hc | sort -hn | tailNcdu 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
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.
I already havealias asd=exa
(The first two because I use Dvorak, in which case I'd use 'aoe' instead of 'asd'.)alias h=ls alias hh='ls -l' alias lrt='ls -lrt' alias lrta='ls -lrta'
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:
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".without ,gkjsfk (Qwerty equivalent) RLRRLLRI 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=exaBut 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.
> 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.
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.
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 colorsEvery new terminal I open uses a random background color. All colored text is always readable.
What I did was make sure the background colors were always dark, and set the first 16 terminal colors to be light. I randomized the background color by specifing it to the terminal via a command line option as the output of this 10-line script[1] that takes an HSV Value as an argument and returns an RGB with randomized Hue.
It's nice for terminals to be differently colored when you have many of them open. It helps one to realize when you've switched to the right one.
iTerm2 lets you force a minimum contrast, which solves the contrast problem while still letting you use colors. Lots of programs display hard-to-see colors (red-on-black for me too), so it makes sense to address this problem at the terminal level.
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.
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? :)
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.
> exa is written in Rust, so it’s small
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.
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.
If it's not small, what would you call it?
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... ;-)
> 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
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.
Dynamic linking to what, though? The features you're looking for have to available in a library for you to be able to link to it.
The standard library for one; many C programs have libc dynamically linked. Rust's stdlib isn't.
Dynamic linking to the standard library + the projects dependencies, from the cargo file:
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"
As usual, you have to consider static vs dynamic linking, all sorts of other stuff.
Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949
Compared to JavaScript, one would guess. Rust is capable of generating extremely small binaries but none of the compiler's defaults are amenable to it
After strip it is 1.1M.
For comparison, ls is 38k on macOS (edit: and coreutils’ ls is 138k).
Rust links all its runtime statically by default. Your /bin/ls is probably dynamically linked to libc and a few others.
That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary.
> 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.
> Did you strip both binaries?
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.
> No, should I have to?
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.
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.
> how is that misleading?
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.
The performance difference between grep and ripgrep is stark, ripgrep is blazingly fast, isn't that worth some "bloat"?
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.)
Interesting; du reports on mine at 20k.
Although as you mention...% du -h /bin/ls 20K /bin/ls% ls -laF /bin/ls -rwxr-xr-x 1 root wheel 38624 Jul 15 00:29 /bin/ls*my work macbook's ls is 16k. huh
It's a lot bigger than conventional ls, but compared to a node.js implementation or Java program the description "small, fast" seems justified.
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.
What do all the colors mean? I wish he would make a little page explaining what I'm looking at and what each color means.
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™
Receive the feedback, but ignore the haters and do what you feel is right for your brainchild.
I've learned some commandline tricks just from reading the comments!
Very interesting - thanks.
/exa/src $ cloc .
41 text files.
41 unique files.
0 files ignored.
http://cloc.sourceforge.net v 1.60 T=0.10 s (423.5 files/s, 64346.3 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Rust 41 1152 929 4149
-------------------------------------------------------------------------------
SUM: 41 1152 929 4149
-------------------------------------------------------------------------------so whats the replacement for sl in that case? can't live without it
Asking the important questions. Maybe exa could show a flying axe?
axe - the rainbow colored train that.. well, trains you to spell exa properly.
Looks very nice, I've been using K, which has some other cute features (https://github.com/supercrabtree/k), but I'll definitely add this to my arsenal.
This is cool, I was having trouble with libraries, so I'm switching my main Linux to Arch.
A multi-threaded program to list files. The times we are living in...
I'll give it a try for a few weeks.
I've been using k [1] to get pretty much the same functionalities but, being written in zsh, it's terribly slow. Your program looks nice but I would love to have an output closer to k in term of colour [2], at the moment it feels way to noisy to me.
[1] https://github.com/supercrabtree/k
[2] https://raw.githubusercontent.com/supercrabtree/k/gh-pages/f...
I've seen k before, it's pretty neat.
You can't grey out the columns in exa until I land configurable colours, which I hope to get done relatively soonish. But you can use the --colour-scale (or --color-scale) option to colour file sizes based on how big they are. The person who submitted the feature request (https://github.com/ogham/exa/issues/65) used k as a direct example.
Nice, looking forward to the configurable colours, I feel when everything is in bright colour it makes hierarchy much harder to read.
./exa-linux-x86_64: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory
Couldnt all the dependencies be statically linked for max portability?
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.
The GitHub issue offers a fix for Ubuntu: https://github.com/ogham/exa/issues/194
Just make sure you update exa when there's a vulnerability in whatever got statically linked to it.
In general, they could. As always, it's a tradeoff. See the above thread about binary size...
This is great. I'm switching to exa!
I had high hopes with this command but found the git features missing: exa -l --git --time-style=long-iso -T
Nonetheless, this displays
Hopefully, the author finds this worth the time to support..
Yo. What's it display? Feel free to raise a bug if something doesn't look right. I know it's not the fastest-moving open-source project, but I'll still read everything that people submit.
the output is missing the git modification flags
so... a mix up of the following:
which ls alias ls='ls --color=auto' /bin/ls
tree -L 2
git diff --stat
git status
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
Sometimes the Unix philosophy has to be taken with a grain of salt.
But this is "Modern".
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:
The second problem is solved by configuration management tools pushing out your desired tools to your entire environment.test -f /usr/bin/exa && alias ls='/usr/bin/exa'> configuration management tools
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.
Sure, but it's easy enough to fall back after you get the command error.
If you want, you can alias it to `ls` so you don't lose muscle memory.
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?
From the FAQ:
>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.
"exa prints human-readable file sizes by default (when would you not want that?)"
When doing automated text-processing and wanting to easily do precise calculations, without having to deal with different units.
The important part is by default. exa can provide bytes sizes, it just provides human-readable ones by default.
How does the number of bytes help with text processing? Are all your files in fixed-length encodings?
Probably means "when processing ls output", in which case not having to do prefix conversion is easier.
I almost never use the human-readable file sizes.
For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal breaker for many.
> I almost never use the human-readable file sizes.
Same here. I love the idea, and i keep trying to use human-readable sizes in every command which supports them. But it turns out they're much less scannable than numbers in a common unit. How long does it take you to see which of these files is biggest:
How about now:13k potatoes.txt 7M tomatoes.txt 128 recipe_ideas.txt 1G hot_sauce_formula.txt
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.13093 potatoes.txt 7182642 tomatoes.txt 128 recipe_ideas.txt 1023984672 hot_sauce_formula.txtInteresting point. Maybe we could have our cake and eat it too:
.. 13k potatoes.txt .... 7M tomatoes.txt 128 recipe_ideas.txt ........ 1G hot_sauce_formula.txtI'm disgusted, yet intrigued.
That's a clever hack, I like it
>unless you have some fancypants sort which understands them
FWIW GNU sort can sort by human readable units using the -h option.
I really want to know what the deal with hot_sauce_formula being 1G is. That must be one hell of a hot sauce.
If you want to see the largest file, wouldn't you want to sort it by size anyway?
You would, but you would have to run `man ls` to figure out how to do that. That's a showstopper.
Or...
alias bff='ls -S | head -1' # biggest fscking file
> Most people who work with nix systems work on many systems
[citation needed] Lots of people using macOS and even Linux without being server administrators.
While there has been a influx in command line usage due to mac adoption (has actually been flat for a few years now) most people who find their way to a terminal at some point or another will find their way to ssh.
Also just because you have access to many systems it does not make you a server administrator. I have access to tens of thousands and I am not a system administrator.
Over the years of working with Linux the one thing I have learned that saved me many times and made me productive was to learn the defaults and use the tools that you will most likely find on all systems. If you don't you will find your self bumbling around and feeling lost if you ever log into a system that is missing your favorite modification / customization.
This is the exact reason I have held off on fully switching to something like zsh or fish as well. I have a few thousand servers and basically the only guaranteed thing is that they will have some version of bash or at least sh installed.
We shouldn't need complete backwards compatibility on a command that is completely new, surely? That would limit the amount of improvement that could be made dramatically.
Also, as a side note, why do you enjoy using machine readable file sizes over human readable? The latter, as chosen by their name, are meant to be easier to use for humans.
twic, replied to my original post and I think he does a good job of showing why the machine readable is preferred -- and why human-readable is not actually easier for humans.
I would also like to add to the case twic showed that often I am using ls to see if a file is growing. In human-readable format hides the actual size and rounds -- it could move 200 megs or more before the human-readable output is updated from 1G to 1.2G.
To address why backwards comparability is needed is because of muscle memory. Its not likely that this tool will be on every system I use. I don't want to have to think about what system I am on and what command I need to run. It would be nice to also be able to alias it to 'ls' as ls is way faster to type than eax -- all on the left hand makes it MUCH slower -- although I am sure there will be those who say different -- but they are wrong.
> > For example, exa prints human-readable file sizes by default (when would you not want that?)
When its being used as part of a script.
Parsing ls is a pain anyway, using "stat --printf=%s" is much better in scripts, in my opinion.
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.
Operative word: by default. If you want the bytes value, you can ask for it (-B).
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.
Exactly - it's a logarithmic scale bar chart!
What you are looking for is `ls -S` and `ls -Sr`
It doesn't support LS_COLORS, unfortunately.
My first thought is that "exa" has all three letters in the left hand. Not nearly as easy to type as "ls".
I really dig the very useful output, but I'd also muchly appreciate an `ls` compatibility mode. Thus, one could put something like `alias ls='axa --compat'` into .profile and wouldn't have to re-train their muscle memory. F.e., I'm personally using `ls -altr` very often, and `axa -altr` will yield me an error.
Very cool project, will replace ls for exa :)
If you want colors, you can use grc to colorize command outputs not just ls, even MySQL terminal.
Some old HN thread. https://news.ycombinator.com/item?id=3858954
I used it now for a year (maybe more, I can't remember) and I find it fantastic. It's great, and I can't imagine using plain old ls any more. No matter what people say, I love it.
I already installed & replaced my ls config. Thanks for making it!
Interesting that they chose to keep the file name on the right-hand side like ls, and unlike every graphical file manager.
The name is the key field and so it should generally be the left-most column.
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).
It makes sense to list the filename last IMHO.
The file name (or entire path) should be where-ever the user expects to find it. Having fixed width columns makes using sort(1) trivial.
For the "all the information" part, I've been using something like this:
fn () { find "${@:-.}" -printf "%TY %Tm %Td %TH:%TM:%2.2TS %1y %4m %3n %4U:%-3G %8s %p\n"; }
For a command that gets typed as often as 'ls', choosing 'exa', which is typed with one hand only, even worse, with a repeated finger, is kind of a poor choice.
#!/bin/bash alias lse = exa
i know this may sound trivial, but I'd probably never use this just because typing exa is a lot more annoying than typing ls. The three letters are on the left side of the keyboard and on the three rows. Sure I could rename it to something I like, but then I won't be able to get used to it, because I won't be able to find it when I log on to other computers. It's a silly thing that has a serious impact on usability...
No one invented anything better than Commander-type UI for dealing with files. For non-trivial tasks I'd fire up vifm.
This is amazing! Now:
* can you use unicode icons to replace `d` and others with icons of folders and such?
* where are the color signification explained?
Surprised no one has suggested replacing permissions display with emoticons.
What does "exa" stand for? That's what I want to know.
"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.
I'm guessing it's short for examine
examine?
What is the usefulness/learning_effort ratio of this tool?
You can pretty much use it like ls for most things, so I'd say very little investment needed.
I honestly just like it, colors make it easier on my eyes
$ exa -bghHliS ????
How about: $ exa . -- with the same outcome? :)
The last thing I want in terminal is colours.
Why do you want to replace ls?
Nice, I like the -T option.
exa is harder to type than ls, but this looks really cool.
You could alias it to ls.
Or e.
The name is too long.
cool. i feel like this whole thread is the epitome of hacker news comments
This looks awesome. Anyone's gonna make a PR for ubuntu to add this?
Wow I’m quite overwhelmed by the colors
ohh i thought exa was a replacement for the word 'is'. i was like damn.... that's fucking cool.
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:
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...
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.
I don't see it that way.
The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice?
Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" in front of /bin/ls in their shell for convenience.
So? Nobody is going to use this to replace "ls" in scripts. Are you really arguing against the creation of competing tools? "ack" shouldn't exist because "grep" already exists? "htop" shouldn't exist because there's "top"?
Correct, you don't need this tool.
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.
AFAIK bash aliases never bleed into the scripts you run. So an alias should be relatively harmless.
So what if they do?
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)
Given that the FAQ says that this isn't a drop-in replacement, I don't think they're a fan either.
i'm not going to be rude or hate exa, it looks really cool actually. I, for one, love the color coding. But trying to replace something as old and known as 'ls' probably isn't a realistic goal. I think talents would much better geared towards something missing, instead. Either way, keep up the good work.
> Git support: View the staged and unstaged status of every file, right there in the standard view. Also works in tree view.
This is nearly impossible to implement securely.
Better don't run exa against untrusted directories.
Can you please expand on your comment? It currently makes zero sense with zero references.
It uses libgit2 for this; I don't know what specific attack vector you're thinking about though.
Git's on disk format has a massive attack surface.
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.
The blurb made it sound like it checks the git status by default. But this isn't the case. You have to explicitly ask for with --git. Never mind then.
To the author: As you are already making a much more user and human friendly version of ls (like making ls -h the default behavior) please consider placing the name of the file on the left most column
inode Permissions Links Size Blocks User Group Date Modified NameAs a human I first care for the name, Currently I'm forced to scan the right most column (which position varies) and then travel back to the beginning of the line and read the rest of the metadata
It's much easier to deal with line breaks. File names first would break the entire layout when one of them is too long.
And when the terminal is on the left, you don't have to move your eyes so much away from the middle of the screen.
Color is one of the first things I turn off. So many tools color files in ways that are very difficult to read (dark blue against a black background, really?)
I'm colorblind, too, so your red/orange/green distinctions are utterly wasted on me. Raw color is a very flaky and low fidelity way to communicate to a user.
Animation, on the other hand: Give that super important file that's somehow busted or very active some kind of blink or a meaningful animation and you'll have my attention. I may hate the tool for it, but you'll have my attention...
No idea on earth why you are downvoted. My sympathies for your challenged vision. Your objection is well founded, and your suggestion has merit.
Judging the use of colors in software as a colorblind person is like rating shoes when you have no legs. He's coming across whiny and pretentious.
Sorry it doesn't work for him, but colors are generally useful when working with lots of text.
People mistake accessibility for personal taste.