Exa, a modern replacement for ls(the.exa.website) |
Exa, a modern replacement for ls(the.exa.website) |
Even just with PATHs or aliases, or a new binary entirely.
And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), https://github.com/rupa/z.
A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.
The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.
Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.
In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, The Tao of tmux [2] (available free to read online).
So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:
export EDITOR=vim
Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:
export GIT_EDITOR=vim
Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:
http://man7.org/linux/man-pages/man5/dir_colors.5.html
edit: actually, BSD's ls(1) seems to be $LSCOLORS (https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1):
[1] http://www.jedsoft.org/most/
[2] https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-t...
The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice?
Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" in front of /bin/ls in their shell for convenience.
This is nearly impossible to implement securely.
Better don't run exa against untrusted directories.
Do not run "git" in untrusted directories. It is not hardened against that (as opposed to the network protocol).
That probably includes libgit2 unless it explicitly states the opposite.
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
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.
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...
Sorry it doesn't work for him, but colors are generally useful when working with lots of text.
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.
I forgot to add: Having colors / fancy output when you just want to pipe information around the shell is of no value.
IMO it goes against the spirit of what commands like ls are meant to do, and the behavior exa provides is better placed, and already done well, via shell configuration (e.g. oh-my-zsh, presto, pure)
I'll give it a try for a few weeks.
[1] https://github.com/supercrabtree/k
[2] https://raw.githubusercontent.com/supercrabtree/k/gh-pages/f...
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.
Couldnt all the dependencies be statically linked for max portability?
The GitHub issue offers a fix for Ubuntu: https://github.com/ogham/exa/issues/194
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..
which ls alias ls='ls --color=auto' /bin/ls
tree -L 2
git diff --stat
git status
Certainly not life changing, but after using it for a while, I can tell you that every time I'm on a machine that doesn't have exa, I feel so frustrated ls doesn't give me everything exa has. I often end up downloading exa on any machine that doesn't have it
The problem I see with these "modern" command replacements is 1) muscle memory and 2) I have to log into some old systems that simply will not have anything this "modern".
test -f /usr/bin/exa && alias ls='/usr/bin/exa'
If you want, you can alias it to `ls` so you don't lose muscle memory.
>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.
When doing automated text-processing and wanting to easily do precise calculations, without having to deal with different units.
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.
When its being used as part of a script.
Some old HN thread. https://news.ycombinator.com/item?id=3858954
The name is the key field and so it should generally be the left-most column.
It makes sense to list the filename last IMHO.
For the "all the information" part, I've been using something like this:
fn () {
find "${@:-.}" -printf "%TY %Tm %Td %TH:%TM:%2.2TS %1y %4m %3n %4U:%-3G %8s %p\n"; } #!/bin/bash
alias lse = exa* can you use unicode icons to replace `d` and others with icons of folders and such?
* where are the color signification explained?
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.
How about: $ exa . -- with the same outcome? :)
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.
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.
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:
13k potatoes.txt
7M tomatoes.txt
128 recipe_ideas.txt
1G hot_sauce_formula.txt
13093 potatoes.txt
7182642 tomatoes.txt
128 recipe_ideas.txt
1023984672 hot_sauce_formula.txt
.. 13k potatoes.txt
.... 7M tomatoes.txt
128 recipe_ideas.txt
........ 1G hot_sauce_formula.txtFWIW GNU sort can sort by human readable units using the -h option.
alias bff='ls -S | head -1' # biggest fscking file[citation needed] Lots of people using macOS and even Linux without being server administrators.
Also just because you have access to many systems it does not make you a server administrator. I have access to tens of thousands and I am not a system administrator.
Over the years of working with Linux the one thing I have learned that saved me many times and made me productive was to learn the defaults and use the tools that you will most likely find on all systems. If you don't you will find your self bumbling around and feeling lost if you ever log into a system that is missing your favorite modification / customization.
Also, as a side note, why do you enjoy using machine readable file sizes over human readable? The latter, as chosen by their name, are meant to be easier to use for humans.
I would also like to add to the case twic showed that often I am using ls to see if a file is growing. In human-readable format hides the actual size and rounds -- it could move 200 megs or more before the human-readable output is updated from 1G to 1.2G.
To address why backwards comparability is needed is because of muscle memory. Its not likely that this tool will be on every system I use. I don't want to have to think about what system I am on and what command I need to run. It would be nice to also be able to alias it to 'ls' as ls is way faster to type than eax -- all on the left hand makes it MUCH slower -- although I am sure there will be those who say different -- but they are wrong.
I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again!
Thanks for sharing this and also for your screencasts. I'd definitely spend a lazy evening watching you program exa.
I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.
Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.
Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.
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.
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.
`grunt test`.. ooh, so pretty and creative! `grunt test > test.out`, wtf, why is my file full of control character bullshit?
exa was my first Rust project and it just grew and grew.
#!/usr/bin/env ruby
`ls`Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.
oh wait, I know what behaves exactly the same way: ls
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.
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.
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.
'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.
Why?
On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.
An example would be busybox, which can decide which executable to pretend to be by the target name.
exa -bghHliS
alias exa-size='exa -bghHliS'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.
They are also all on the left hand in both Dvorak and Neo.
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.
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)
⋊> ~/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.
Are you really sure you want to replace ls with exa? I can think of a dozen reasons it could cause trouble.
Actually replacing the binary? That would cause so many problems!
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)
using color to show git status in normal view would be much more interesting to me.
Well, Windows VMs aren't hard to come by and they work quite well on any host platform (contrarily to some other OSes coughMacOScough)
A native windows version would be interesting, though I believe people generally shun any prolonged interactive use the windows command line, this kind of tool might be one of the possible remedies against the pain of using it.
I do have a Windows 7 VM setup for testing, but I also bought a cheap Windows 10 laptop to test on as well.
PS: I develop on Windows
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`
It's the slowest file copy mechanism I've ever used!
Plot twist: What if it turns out that it was you all along! :O A la Dr Jekyll Mr Hyde :)
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.
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.
38 kilobytes of executable isn't small, it's tiny; there's no way exa could get to that level without compromising its featureset or development, and even if you did, you'd just have another ls, and we already have ls.
If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter files all over your computer" to me, and exa's smaller than that.
Self-contained, portable, featureful, etc. There are plenty of other adjectives to say it's not huge or "download tens of megabytes of runtime and scatter files all over your computer".
For me, <64KB is small and <4KB is tiny. But then again, being aware of the demoscene, I've seen what can be done in those size categories... ;-)
I'd be willing to bet dynamic linking would get it much closer to that ballpark and wouldn't compromise the feature set or development.
I've learned some commandline tricks just from reading the comments!
/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
-------------------------------------------------------------------------------ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.
(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)
That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.
One thing I always wanted to remove from `ls` is the default "human-like" display of dates and times (which `exa`, unfortunately, seems to inherit). This is IMO just annoying (and replacing time with year, if it differs from current, just plain stupid; and don't get me started about the "bright" idea of using locales there!). We have ISO-8601 for a reason. It's readable and universal. 2017-06-17 is easier to parse than "cze 17" (hello, locales).
export TIME_STYLE=long-iso
I also have this, for the thousands-comma display:
export BLOCK_SIZE="'1"
$ ls -on i*
-rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg
-rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
-rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...
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.
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)
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?
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.
HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.
> HN is so predictable that I knew someone would complain about this the second I read it
And I considered there'd be a pretty good chance that I'd get a reply like this.
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!
export TIME_STYLE=long-iso
export BLOCK_SIZE="'1"
$ ls -on i*
-rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg
-rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png
-rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix
Time style: https://www.gnu.org/software/coreutils/manual/html_node/Form...
The rendering of time in any format other than ISO-8601 is a pet peeve of mine. It always baffles me why people do it.
alias ls=exa
command lsIf they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
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.
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.
"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.
Also I've noticed terminal emulators (like terminator) recognize output and sprinkle in formatting on the display.
iirc, if your terminal emulator is doing something funny with the output of `ls` it's because they've re-implemented it as a function and are intercepting the call to ls and running their function instead, not because they're recognizing the output.
But yeah, alias ls=exa also works.
It's top row, bottom row, middle row, and the 'x' on a normal keyboard is half way to being directly under the 'e'. Very awkward and antithetical to the ideas of people who have designed keyboard layouts specifically for efficiency and ergonomics.
The only demographic that comes to mind which would find that hand position "natural" would be guitarists and other string players.
export pls=exaSpeaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).
Is the problem really that there are colors, or that the colors used don't work well for colorblindness? Do you find coloring that doesn't go afoul of your particular type of colorblindness still less useful than no coloring, or is it just that so often little attention is paid and an assumption is made that it's no worse than monochrome when in actuality it sometimes is?
I guess my real question boils down to if whether the author tried to make the default color profile at least not horrible in some respects for most colorblind users, would you still think defaulting to color is the wrong default?
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.
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`.
If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.
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.
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.
If your machine uses termcap/terminfo, type this to see how many yours supports.
tput colorsWhat 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.
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.
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.
What would people think if all web pages on the internet had ugly black backgrounds?
From the doc, it doesn't appear that colors are customizable, yet. Pull request? :)
Worthy start for a default and you might want to contribute an exa config / env variable setting to solarized.
Shame, the idea is pretty neat. If you can solve that issue, OP, I'd love to give it a proper try.
If your blue doesn't look right on your dark background, why are you using that blue?
If your yellow doesn't look right on your light background, why are you using that yellow?
I mean i get how this can be a problem with hard-coded arbitrary values — you can't ever guarantee that e.g. #ff6600 will go with anyone's particular colour scheme. But these 8 or 16 standard colours are not hard-coded, they're configurable in every terminal i've ever used, including Windows's shitty command prompt. They can and should be set to a value that's appropriate for your background and text colours.
Maybe this is more a fault of the terminal/theme developers for providing unusable defaults. idk.
Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949
I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.
I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think
It would also be nice to see files owned by different users and some of the git functionality.
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.
du -hc | sort -hn | tail
Why not? I would.
Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.
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.
\ls alias asd=exa
alias h=ls
alias hh='ls -l'
alias lrt='ls -lrt'
alias lrta='ls -lrta'
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.
Tilting my head every time I wanted to read a title, I didn't fancy though :)
Doesn't sound like a default case to me.
Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.
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"
Related: http://www.linusakesson.net/programming/syntaxhighlighting/
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.
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.
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.
I understand that the answer may be different for different people in somewhat non-subjective ways, since there are different types of colorblindness.
In the case of text that means asking the question: does removing all color remove any information? If the answer is no, then a colorblind individual can use other cues. (While my prior post focused upon legibility, two different colors may look like the same color to me even when the text is perfectly legible.)
I would also suggest keeping the number of colors used to a minimum. More color combinations means more opportunities for problems and more difficulty in resolving those problems by setting a custom palette.
Finally, only use color when it adds value. The use of color to highlight different file types was useful. (The file extension still existed as a cue, which is great.) The use of color to highlight columns is just asking for trouble without adding value. It is not adding value because all of the elements in a column are the same color anyhow, so it adds the risk of reduced legibility without highlighting anything in particular.
* http://invisible-island.net/xterm/xterm.faq.html#dont_like_b...
Seriously, "du -h | sort -h" is a regular command for me.
It's not "the sane thing" to differentiate output on STDOUT's attributes. grep doesn't have the --colour option ternary for nothing.
exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.
Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
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…
> 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.
It wouldn't be right if something didn't go badly wrong at the worst possible moment!
That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary.
For a single app, sure it's no problem, but what about when the thousands of other programs in bin introduce similar levels of bloat? Another one is ripgrep, weighing in at 5MB compared to greps 204kb.
And this is just for fairly simple command line tools, Imagine what life will be like when we have UI toolkits like QT statically compiled into everything.
Did you strip both binaries? If I strip rg after compiling it, it shrinks to 2.7MB on Linux. If I strip the distributed binary on Github (which is statically linked with musl), then it shrinks to 2.4MB.
> Imagine what life will be like when we have UI toolkits like QT statically compiled into everything
I imagine Qt will be dynamically linked, so I'm not sure why you'd say that.
Of course, if you want to statically link something like Qt because it makes distribution easier for $reasons, then that's a different story. But that has nothing to do with Rust.
% du -h /bin/ls
20K /bin/ls
% ls -laF /bin/ls
-rwxr-xr-x 1 root wheel 38624 Jul 15 00:29 /bin/ls*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...
"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.
In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.
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. ;)
Don't feel too let down by the comments on HN. Awesome work!
Just some ideas, maybe you like some of them :)
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!
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.
things that can't be typed w/o moving your fingers from the home row are really easy to type.
That's why some people (like me) switched to Dvorak.
Your sentence on Qwerty was 43 top, 21 middle and 12 bottom row keypresses.
On Dvorak, it's 24 top, 45 middle and just 7 bottom row characters, twice as good!
"ithout" is also entirely home-row, so you wouldn't need to bother with "w/o". The word demonstrates Dvorak's other feature nicely, hand alternation and outward-to-inwards flow:
without
,gkjsfk (Qwerty equivalent)
RLRRLLR
(That statement changes a lot if you're looking at another grep like BSD grep, or if you're directly comparing `grep -r pattern` with `rg pattern`, which is always subject to caveats, because the latter is doing some guesswork and parallelism where the former isn't.)
I disagree; what's easier, spotting the biggest and smallest of these at a glance:
6,677,967
5,916,109
7,164,551
3,745,059,597
3,175
4,194,304
3,550,137
6.37M
5.64M
6.83M
3.49G
3.10k
4.00M
3.39M
But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.
Human readable units helps quite a bit with this, and I think that makes it a sane default. As long as you can specify you want to see bytes, and the sorting is done on the actual byte value, there's little lost because the majority of the time it will help rather than hurt.
Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.
People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.
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).
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.
How does 524404648 vs 5.24404648e8 look?
I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
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.
It could be different for others. I saw a guy who could do 100 WPM with literally two fingers, although it looked exhausting. A year of waking up with my fingers locked, simultaneously numb and throbbing in pain, taught me that maintaining a relaxed flow is more important than those last 10 WPM. But that means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.
But 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....
Seven digits isn't quite as bad, but without thousands separators it's bad enough.
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 unitsI'm not sure why I said nine, seven is what I was thinking of.
No, should I have to? I'm just looking at the published binary sizes.
> I imagine Qt will be dynamically linked, so I'm not sure why you'd say that.
I said like Qt, as in something similar written in rust. The Qt5 GUI module weighs in at about 10MB, if every gui program included it plus all the other libs then the bloat quickly adds up.
> But that has nothing to do with Rust.
Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem.
Love the brigading the rust community always does btw. Apparently someone was triggered enough to go through my comment history downvoting.
You don't have to do anything, including publishing misleading comparisons.
> Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem.
Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64.
>Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64
Again, it was an example. Show me a similar rust library that can be dynamically linked to like this? A rust equivalent will have to either use a c interface or be statically compiled.
touch 'file with spaces'
for file in $(ls); do
rm -- "$file"
done
Now do this:
touch 'file with spaces'
for file in *; do
rm -- "$file"
done
ls -Q
touch 'file with spaces'
for file in $(ls -Q); do echo "$file"; done
"file
with
spaces"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.