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.
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
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.
Why not? I would.
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).
"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.
touch 'file with spaces'
for file in $(ls); do
rm -- "$file"
Now do this:
touch 'file with spaces'
for file in *; do
rm -- "$file"
touch 'file with spaces'
for file in $(ls -Q); do echo "$file"; done
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.
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.
Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.
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.
ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.
(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)
That said, the binary isn't self-contained (I know, I know) so I was in the middle of compiling it from source before being pulled away for work. Looking forward to trying it.
It wouldn't be right if something didn't go badly wrong at the worst possible moment!
One thing I always wanted to remove from `ls` is the default "human-like" display of dates and times (which `exa`, unfortunately, seems to inherit). This is IMO just annoying (and replacing time with year, if it differs from current, just plain stupid; and don't get me started about the "bright" idea of using locales there!). We have ISO-8601 for a reason. It's readable and universal. 2017-06-17 is easier to parse than "cze 17" (hello, locales).
I also have this, for the thousands-comma display:
$ 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)
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 :)
But not with your reaction to colourblindness - it's surprisingly common. We changed a grid of clickable red/green squares to add crosses and ticks after a chance comment, and several more users bothered to contact us about how much easier it made the UI.
So please DO give a... fig... about colourblindness - if it's worth adding colour to help users, surely it's also worth a little thought about how to cater for colourblind people. In this case, a grey-scale palette perhaps?
Be civil or don't comment.
but in all fairness, other than what you had to say about colorblind people, I more or less agree with your other words and claims. but seriously: i didn't choose to be colorblind and I honestly do hate it sometimes.
- when I was maybe 12 the ophtalmologist told my father in from of me that I should forget about engineering and science in general. Take it dumbass, I am an engineer and PhD in physics (I had to let this out one day :))
- I was shopping for school supplies this morning and had to ask someone to help me choose the copy books so that they are of various colors and not pink. She was surprised at first but then we ended up with a nice talk.
- I reflashed a router 5 times as the flashing was failing, the LED was red. My brother was walking by and told me it is actually green, ending my agony. The router survived.
- a support guy flew cross country once to support my switches which were failing. As you can imagine they were not, I thought that the LEDs were red but they were green (maybe the ophthalmologist was right after all. Still a dumbass for saying this in front of a pre-teen geek who could have listened and go for liberal arts)
- my boss (a lady) told me that I wear interesting color combinations. I thought I was always wearing a combinaison of beige and pale blue. I was not.
Seems to be the case that there is no modern text editor that doesn't color every single word. Must be so hard for you now that you're forced to use these tools with such "poor usability and design". How do you even manage?
Just clicked-through to see what you meant about `exa -l` and I agree. When individual characters have different colors that's just way too much.
It's not "the sane thing" to differentiate output on STDOUT's attributes. grep
doesn't have the --colour option ternary for nothing.
exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.
Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
I'm not certain if it's exactly what you're getting at, but less can be instructed to parse ANSI color sequences, and output them, with the -R flag. (If you forget to put -R on the command line, or some utility automatically starts less for you, you can also type "-R" while in less to trigger that behavior.) That said, less has to be fed the sequences, and most programs will not output color sequences when piped to less, as they detect that the output isn't a TTY (this is normally the right thing to do, it just kinda sucks in less's case) so you might need to, e.g., that_prog --color=always | less.
> There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
Yeah, this is the real problem. I kind of wish there was some sort of content negotiation between piped utilities, s.t. less could inform the upstream utility of "hey! I speak ANSI color codes!".
What follows is definitely well into the "WTF too clever" column and I do not recommend it, but, this is HN: I presume you could riff through /proc trying to find the other end of the pipe that you're writing to (I think /proc on Linux has that) and then, if the executable's name is "less", well, you see where I'm going…
Of course, PowerShell has its own issues, but the idea of a shell with more meaning attached to things is appealing. Rebuilding an ecosystem that can handle it all though... not so plausible!
> 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.
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.
HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.
> HN is so predictable that I knew someone would complain about this the second I read it
And I considered there'd be a pretty good chance that I'd get a reply like this.
Doesn't sound like a default case to me.
Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.
In a program that natively makes strong use of colour, though, here's an option: print exact file sizes, but in two related colours (say, bright yellow and dark yellow/brown), as follows: the first colour for the first 1, 2, or 3 digits, and the other for the remaining $n$ digits where $n$ is divisible by 3. That way the first colour will represent a whole number of KB, MB, GB, etc—and which of these it is will be very clear as it's easier to get that rough-count size—and the fainter/darker colour would give the full exact number of bytes. Best of both worlds!
$ 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
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.
If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
I disagree; what's easier, spotting the biggest and smallest of these at a glance:
But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.
Human readable units helps quite a bit with this, and I think that makes it a sane default. As long as you can specify you want to see bytes, and the sorting is done on the actual byte value, there's little lost because the majority of the time it will help rather than hurt.
Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.
People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.
Actually, many of the utilities that output in human readable format do so in a way that's also sortable through sort's -h option. It might be worth making sure you have a mode that outputs the same way so people can easily utilize sort. That is, K/M/G instead of Ki,Mi, Gi. Unless sort ignores the second alpha character when using -h and it still works, then no problem. :)
Edit: Actually, I just tested, and at least as of the sort in coreutils 8.4, it recognizes both forms, and actually dies with a warning if you mix them, so you're all good!
# echo -e "100Mi\n100Ki\n10Mi\n10Ki" | sort -h
# echo -e "100Mi\n100Ki\n10Mi\n10K" | sort -h
sort: both SI and IEC prefixes present on units
I think your perception of filesizes is slightly skewed; "nine or more digits" means roughly >=100MB. Disk images, software, and videos would be in that range, but probably not the average MP3 (100MB of 320k MP3 is over 40 minutes), and I don't think I've ever handled a "word processing document" more than a few dozen MB --- and even that would already be many hundreds of pages.
Of the files sitting on my desktop at the moment, which is not necessarily representative nor typical but covers a wide range of types (pdf, mp3, zip, exe, jpg, mp4, ...), slightly more than 10% are 10MB or more (8 digits), ~15% have 7 digits (1-9MB), and the rest are below 1MB (<= 6 digits).
Seven digits isn't quite as bad, but without thousands separators it's bad enough.
Even then, most of my documents are quite a bit smaller, as I have a tendency to write my documents in wordpad instead of office, and then save as rtf or txt.
I'm not sure why I said nine, seven is what I was thinking of.
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.
Seriously, "du -h | sort -h" is a regular command for me.
At least I learned that ls had a -h option. I don't know why I should use it on files but I routinely do df -h to check the size of file systems. That's a place where it is useful.
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.
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.
du -hc | sort -hn | tail
An example would be busybox, which can decide which executable to pretend to be by the target name.
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.
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.
alias hh='ls -l'
alias lrt='ls -lrt'
alias lrta='ls -lrta'
"gf" for example would be better. neighbor characters on the keyboard, could stand for get files.
Its because of the rules of blind typeing courses that says thumb should be used only for space? If you got such a courses more than a year before and already mastered blind typeing, than stop worrying. Just use thumb for `x`.
> I've tried micro-optimizing special cases like this before, but then I have to think as much about typing as what I'm typing.
It got better with practice. Like blind typeing. All you need is to train you fingers for they do it without conscious effort of thinking. Are you play on some musical instrument? Try it, it teaches how to train your fingers.
It could be different for others. I saw a guy who could do 100 WPM with literally two fingers, although it looked exhausting. A year of waking up with my fingers locked, simultaneously numb and throbbing in pain, taught me that maintaining a relaxed flow is more important than those last 10 WPM. But that means a few combinations like e-x-a will be tap-tap-tap instead of t-t-tap.
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:
,gkjsfk (Qwerty equivalent)
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....
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.
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.
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).
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.
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.
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.
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 know that Gnome Terminal supports 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.
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 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.
> 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.
"exa prints human-readable file sizes by default (when would you not want that?)"
I actually use bytes a lot for certain progress calculations.
Also I get an error "exa: error while loading shared libraries: libhttp_parser.so.2.1: cannot open shared object file: No such file or directory" (Ubuntu 17.04)
I can see how it looks VERY SUSPICIOUS for a file lister to be parsing HTTP headers! I'm not going to sell your directory entries to advertisers, I promise.
⋊> ~/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
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.
But there is a great joy in being able to release a new utility and say about it, "This is how it should work." It reflects your own desires, you understand it, you made the decisions that went into it and have actually thought about the alternatives. There's a delight there. It could be a sign of a piddling egotist, or of a developer who is excited about what real users get to see.
(I did this sort of thing once -- reimplementation of commonly-used, if more niche, thing + manifesto -- from more than 20 years ago: http://all-day-breakfast.com/wm2/)
My main hope for anyone doing this kind of thing is that not too many people actually use it. You don't want to get stuck supporting a tool like this for the world and its dog.
Nothing is more human readable than "123,456,789", so I think the problem is just the way you go about making them human readable. I couldn't agree more that lurching between B, kB, MB, and GB just because the file size changes it extremely jarring and disconcerting, and actually makes comparing the size much more difficult.
Tilting my head every time I wanted to read a title, I didn't fancy though :)
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.