Exa Is Deprecated
github.com
github.com
Both projects are amazing little utilities that when combined with a well-customized shell, really make using the terminal a joy.
I absolutely love the trend of rewriting classic Unix utilities in rust, because the new tools often have (small or large) usability and quality of life improvements that altogether make the terminal a much more powerful environment.
I avoid them unless I'm capable of maintaining them myself. My primary reason for using classic Unix utilities is trusting that they'll still work in a few years. The initial stages of a rewrite can be a lot of fun, but I want to use it long after the excitement has worn off.
But if what the comment I replied to meant by "capable of maintaining them myself" was about having an organizational structure where they could become an official maintainer of the official project rather than needing to fork it if the owner becomes unavailable, then yep, that's a great point about these single-owner projects.
But my original interpretation was about the difficulty of maintaining the code. To me, these rust tools are a huge improvement in that way.
But in practice, the tooling for making those tools never got very good. (That is, in my opinion - there is at least one commenter here who replied to me about actually liking autotools, which is fair enough, just not my opinion.)
So while fully recognizing the value of the old tools that will always exist, for new useful tools, I'm very happy to see this renaissance of writing them in rust. In my opinion, it is much easier to build them, dig into their implementation, and contribute to them (especially without introducing security vulnerabilities or data races).
Where I do absolutely agree, and what I do wish for is that more of this were being done under the auspices of an organization, like how the `ls` most of us are using is likely maintained by either GNU or one of the BSD organizations.
It frankly doesn't seem like a deprecation in the traditional sense.
tools like ls or grep are certainly showing their age, but that has also been their strength. The POSIX ecosystem comes in many flavors but I can always depend on it.
It’s not like I can ever expect to shell into any arbitrary system or container and expect to have exa/lsd/rg or any of these nice replacements available to me. My tooling needs to be somewhat more portable.
Ah yes, because it's 100% impossible to learn new tools and fall back to the core ones when you need to. ;P
I've been doing this for decades now, it's just not that big of a deal.
if [ -z "$(which exa)" ]
then
LS1='ls -1'
else
:
fi
${LS1} ${SOME_DIR} | ...
?Which ones gave you trouble?
A timeless tautology.
Some things just are easy and pleasant. Caddy server, Cargo, ripgrep come to mind. Some things are easy only once you've learned them. No kidding!
Agreed that cargo has bugs and I hope it improves over time (granted: it is not at all new). But say what you want about cargo, at least it's an ethos!
> I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.
https://twitter.com/timmartin2/status/23365017839599616
gnu autotools i suppose works for some projects, but wow does it seem to be completely annoying to use.
Even VS Code uses it for its search beneath the hood.
Related: the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect)
Beware of [HN] bias. People are very quick to rain on Rust for reasons none of them have ever explained substantively and with facts, and many others are quick to agree without checking.
I'm not sure what this paragraph is doing in this context. I was specifically talking about my own experience. I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability". That came crashing down when exa crashed and core dumped.
It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.
Just a small precautionary statement. I've observed it enough times to get very wary of it.
> I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability".
Filter bubbles in a nutshell, I usually see mostly negative ones and barely see any praise (though I'd define "praise" here as "fan-boying", and NOT as "recognizing the strong sides"; the latter is quite normal and should not be called praising).
> That came crashing down when exa crashed and core dumped.
That's the part I find a bit overly dramatic, this was likely Rust's `panic` mechanism so they likely just didn't handle an expectation / assertion in the code? I had several Rust services in production for years and former colleagues have contacted me to tell me the thing hasn't crashed even once and was only ever restarted for upgrades.
> It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.
Yes, fair. If you pepper your Rust code with `.expect()` and `.unwrap()`, the program ending abruptly is expected because the team hasn't taken precautions to handle all possible errors.
Mine is that they're ubiquitous and I can rely on them existing on all Unices. For the same reason, I avoid getting used to any features that are unique to a particular platform or distribution. It just causes additional friction when I'm working on a different system.
Exa was nice but it's command line options were just different enough in places to clash with my muscle memory. Lsd looks a lot closer.
The muscle memory of `ls -alt` and `ls -alrt` was too powerful for me to switch to `-snew`, even after literal years.
This was actually a big draw of GNU implementations in the mid-to-late 1980s vs. the "then classics" of the mid-to-late-1970s. Before the dominance of Linux / OSX, people on SunOS / Ultrix / HP-UX / Irix / AIX / *BSD would often quickly install those more featureful GNU utilities. I imagine AIX/*BSD people still do.
Quite true for many in the macOS subset of BSD
well-rustomized
There, fixed it for you.
But holy hell is getting a working font a nightmare. I spent multiple days desperately trying to figure out font issues, because LSD refuses to list what fonts actually work for it.
And if you just use something from Nerd Fonts thinking it will work (which is what LSD recommends, btw), you'll find that 3/4 or more are missing some stupid symbol or another that LSD uses.
And then you find out that getting it working on other systems is awful. WSL which uses the Windows command prompt under the hood needs a TTF version instead of OTF, which many Nerd Fonts don't bother to make. On MSYS2 it just indefinitely hangs. It's a nightmare.
I have gotten LSD to work once in all my trying on one system.
You could use Windows Terminal instead? Or does it have the same issue?
None of those three "use" anything.
On machines that predate the new ConPTY replacement mechanism (so, everything before Win11), any app that is a command line program (such as cmd.exe, Powershell, anything compiled to be a console program and not a GUI program (this can be any program, and is chosen at compile time)), it is ConPTY.
ConPTY can see OTF fonts (afaik, I remember that working, I don't have a system old enough to check), but can't see any fonts that are in your user font directory (%LOCALAPPDATA%\Microsoft\Windows\Fonts).
As of Win11, however, ConPTY (which has been in existence since NT4, and has been an ugly pain in the ass for just as long) has been replaced with a mechanism to allow you to chose which one you want: a user supplied terminal that can supply that dependency (currently only Microsoft Terminal, but it is documented so any terminal can do it), or a ConPTY replacement owned by the Terminal team (which is basically the renderer and parser ripped out of Terminal, and a massive in-place upgrade, while still looking and acting like ConPTY otherwise). If the old ConPTY can't see OTF fonts (which would stem from using the oldest and most classic font API still in Windows), the new one can (as it uses DirectWrite).
On Win11 machines set to use Terminal instead of new-ConPTY, launching cmd.exe, Powershell, WSL.exe, or any other console program, will launch Terminal to display itself if not already in a console session.
However, fundamentally, for the entire conversation preceding this, it doesn't matter if a font is TTF or OTF for the purposes of supplying Unicode or Nerdfonts icons. OTF only matters if you want Type1-style glyphs (cubic Bézier curves vs quadratic) or want to use OTF features (which aren't meaningful for terminals, generally).
* Windows shells (at least for me, right now) won't DETECT a .otf font. You can't even choose to use it in the options of powershell/prompt/etc
* Most nerd fonts don't bother to convert to TTF. They only provide an OTF.
Even if they're fundamentally the same that doesn't matter if Windows won't detect it in the first place to let you select it.
This ConPTY replacement ('Windows Terminal') sounds fairly recent, so I think you'll forgive me if I didn't know about it. Our work machines only updated to Windows 11 in the last couple of days.
In any case, without access to the store I can't install it anyways. Nice for those who are on 11 already and have access though.
They use the nerdfont patcher, which mainly mutilates fonts, and often breaks them trying to add the nerdfont glyphs. The nerdfonts project also distributes these broken fonts while ignoring the font licenses, and also ignoring the fact that fonts update and then nerdfonts refuses to patch and distribute the new version.
Many projects distribute both OTF and TTF versions, while nerdfonts only distributes the patched OTF version (as you, indeed, have noticed).
The upside is, since the patcher exists, you can just run it on your own fonts and do whatever you want.
I highly recommend avoiding nerdfonts altogether, disable it in any program you find it in, and also consider filing bugs with those projects to entice them to remove support entirely.
Unicode exists for a reason, and fonts should strive to cover as much of it as possible. Corporate logos and custom icons should not be enshrined into any font, not even as something niche like nerdfonts, even if nerdfonts lives entirely in the Unicode private use area (PUA).
The issue also lays with LSD, since they recommend Nerd Fonts.
I always try to push projects to, if they choose to support nerdfonts, to default to off. It is confusing for new users to have to install a specific font (especially when they probably already have their chosen font, and possibly one that can't be nerdfont patched) to use a program.
LSD, in particular, can just either turn symbols off or just map them to commonly available Unicode symbols (a "well formed" terminal font covers most of, if not all, of the Box Drawing, Geo Shapes, Legacy Computing, and Arrows Unicode blocks, which is all you really need).
2019 first release, replaced the old Windows Console as a default since Windows 11 22H2.
I wrote about this in 2018: https://kodare.net/2018/06/25/salvaging-abandoned-projects.h...
Still, even this situation is much better than what we had before. It's on github and so the project doesn't randomly vanish from existence when the owner isn't there to maintain the machine in their closet anymore. Contributors see each other and can realize "Hey, maintainer isn't active anymore but there's still interest in the project, maybe we should do something about this".
So I'm not sure we're we're a good fit, in that we're neither something comparable to Code Shelter, nor unmaintained.
When the project isn't huge (think linux sized) it looks like the best solution, with able persons forking the project and trying to revive it. And if they don't manage to revive it (it's hard to know in advance who will be strong and available enough) maybe another fork will.
Maybe I'm bad at marketing, it seems like a pity.
CS is there to ensure continuity for the original repo (and releases).
How is it hard? Just fork it.
It's also a suuuuper short little blog post. I almost always write very short stuff :P
Not as silly as the person who assumes they didn't read it, when they actually did ;P ;) xx ;p haha!
or you think the only way to disagree with your absolutely right ideas is to have not encountered them, because anyone encountering them can see they are unassailably right?
Come on, that's not a very good view of other people, and an overly inflated view of yourself. They must understand your ideas, just disagree. That's OK, isn't it?
Or, do you write expecting to be agreed with? Well, as you might say "that makes you kinda silly"--the internet is a diverse place!
I agree your example is clear, I just think it's inaccurate, as in missing some perspective. My is perspective is: fork it, do your own marketing, profit. That's what I did to get where I am? Why think you have some right to someone else's work just 'cause they don't reply to you, and you can piggyback on their marketing without doing the work? That's wrong.
That successor will gain access to the _public_ repos of your account after presenting a death certificate. As it's only for public repositories, it's a no-brainer for me.
Sometimes, perhaps, but https://github.com/eza-community/eza looked pretty easy, and they even had push access to change the exa repository to point to it.
The tech notes are particularly useful: https://bsago.me/tech-notes
There’s a ray of hope on their RSS feed: https://bsago.me/tech-notes/feed.json
The last published date is September 2022, which is almost a year after their last GitHub activity: https://github.com/ogham?tab=overview&from=2021-12-01&to=202...
So in absence of other information, I’d rather believe they’re ok. I’ve gone through periods of my life where I blow off all existing responsibilities and reinvent myself. A big project like exa comes with a lot of responsibilities that don’t become apparent until it explodes in popularity; it’s understandable for people to want to disassociate from those.
Some might argue that open source authors have a responsibility to communicate status, but it seems like Benjamin fulfilled that by making sure exa had additional maintainers that could update the readme with a deprecation notice.
One other strange phenomenon is that when you run from a responsibility, it can feel like more and more of a hurdle to come back and face it, at least for me. So it’s probably best to assume they’re fine and to put as little pressure on them as possible. Even just popping in to say “I’m still alive” can feel like pressure.
EDIT: ls on linux is apparently an executable part of GNU and not a built-in
And besides, I said in other places: "ls" has been "deprecated by its maintainer" more times than exa, it's just that somebody has always forked it. GNU "ls" (the one in Linux) is a complete rewrite of the original shell, and it is annoyingly incompatible with the macOS fork of BSD ls.
> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...
However, in my experience, I don't recall seeing any POSIX or POSIX like system that didn't have /bin/sh.
If an ls replacement could somehow handle directories with >10^4 files faster, then I'd switch.
alias ls='ls -U'
(it probably helps that I use a filesystem - btrfs - that is fundamentally append-based so gives a meaningful order even with -U)
I could imagine another utility having a different feature set that people find useful, but in my experience gnu ls always does what it claims to do, and is so foundational that it's a de facto standard when working with Linux.
The desire to "replace" such well established utilities seems misguided to me - by all means add on additional utilities that help you out, but I think it would be wise accept the fact that due to its long history "ls" and similar tools are not going to be replaced any time soon.
It's not wise to accept broken tools just because they persist, that's just mindless conservatism
The practices of project sustenance are already baked in, where as new projects like exa/eza have to figure out and put these practices in place to be around for that long.
We have a phrase "test of time" for a good reason.
They're saying the word "metaphor" is incorrect, and that the original comment is describing "irony".
man 2 stat
Personally, I tend to avoid using replacements for POSIX tools in any shell scripts where possible for this reason. But in terms of what I use day-to-day in interactive sessions, I'll take whatever improvements modern tools will give.
The active maintainers moved the project to a shared repository with a different name 2 years after the creator was seen anywhere.
Personally, I view it as a big success for open source. Someone can make something cool and vanish, and it still lives on via fork. It’s hard to think of any other type of work where that’s possible.
Which is exactly the reason "ls" is working perfectly fine for you today. The original AT&T UNIX "ls" has been forked over and over again and rewritten from scratch several times. You're using an evolved fork of this "ls" if you're using macOS or BSD, but if you're on Linux you're using a rewrite (GNU coreutils ls), and if you're running BusyBox you're using yet another rewrite.
All of these different rewrites and forks aren't really compatible, and you can't reliably use anything beyond what's in the POSIX standard if you want your scripts to run on multiple OSes.
I'm not dissing "ls" - it's an impressive, if old, piece of software that served us well, but it's not inherently more survivable because it's old. It died (in terms of being "forked by another maintainer") many times over, enough to make exa and eza blush.
ls survied because people need it, and I that most of the highly popular rewrite-in-Rust programs are here to stay for the same reasons. Ripgrep, exa, bat and fd are probably part of the club now. "ls" is probably not going to die either. The POSIX standard is going to keep at least the least common denominator version alive for a long time. But for many people it could go the way that "ed" or "more" have gone.
And here is a good story: "ed" still survived in POSIX as-is, while "vi" died and had to be replaced by stevie and and elvis, and then by vim. Nowadays vim is also been replaced by neovim in many circles. And yet, how many people keep using "ed"? Who cares if it's stable, when vi and its descendants run circles around it?
However, being "modern" is not a good reason. The gnu authors were not motivated to write the coreutils simply for the sake of modernity. And that is why their fork of ls has much greater staying power than all the "modern" forks.
I wouldn't install use exa on my CICD pipelines, but on my own machine? Sure. I like the pretty colors. If it breaks moving back to ls is fine.
It's worth pointing out that while exa uses the term "modern" to describe itself, fd and bat currently do not. And I can say with certainty that ripgrep never used the word "modern" to describe itself. I didn't like that strategy even back in 2016 personally, and specifically tried to avoid it.
With that said, to try to argue the point more directly, I do think this is a somewhat shallow concern. It's unclear to me how much predictive power using the word "modern" to describe a piece of software is. I don't like it because it's vague and its meaning is somewhat of a moving target. But broadly speaking, it does convey some things: non-POSIX, does bolder things in the name of user experience and maybe some other stuff. It's a pithy signal. But I'm not sure it has much to do with "staying power."
Presumably coreutils has staying power because there is purportedly a specification covering their behavior (kinda, not really, lol) and organizations responsible for maintaining them. So if you want staying power, stick with the stuff that has a high bus factor and is well funded. That's totally fine.
My point is that all the FUD about "exa" being deprecated is just that - FUD. It's still open source and it can be forked and carried on, just like vi did. The "exa/eza" forks might even be more compatible with each other than the various vi forks/rewrites out there, although admittedly exa is a much simpler tool.
I think we're witnessing a weird fetishization of POSIX and/or GNU coreutils, like they are the epitome of stability, compatibility and continuity, but if you look at them historically, they are not so different from all these Rust rewrites.
The reason ls works perfectly fine today is no one dares fuck with the interface in case they break everything that depends on 30 years of assumptions even if they do suck a little bit. That includes all the forks and rewrites.
This is almost entirely missing in "modern" software development. And I don't think any of us have time or energy really to track down varying different forks of something which needs to work like it did in 1990 when you run that shell script you wrote 15 years ago.
Back in the day it was navigating all the crap between SunOS vs SysV, HPUX, AIX, BSD, etc and then later Solaris, Linux, etc Now it's OS X vs Linux coreutils vs busybox etc. They all have subtle different interfaces and while there is a common basis the reality is that 'ls' is a strange hill to die on for the point you're trying to make. Like 'ps', it's something people have messed with the flags and output a bunch of times...
As others have pointed out, there is no single `ls`, and it's been "replaced" in various systems many times. Yes, we have a contiguous usage of the GNU version for some time, but only really in Linux.
Homogeneity has never been the name of the game in Unix culture, I don't understand why people would insist on it now.
I say: Bring on the "modern alternatives". I just installed lsd. I used to keep a shell alias from lsd -> ls for years anyways :-)
I spent a good deal of time working on SunOS (right back to m68k stuff), Solaris, HP/UX, Linux and FreeBSD over the years and use macOS now and am more than aware of the inconsistencies.
My point is that we pretty much standardised on some basic semantics around each command and what is portable and what is not. And now we're considering moving away from those learnings back to the wild west again.
I consider GNU to be a particularly bad variety of the wild west here for reference. I'm old enough to have been fucked by the differences between gawk and awk.
exa actually does support both, so in a way it's more compatible with my usage of (GNU) ls than (MacOS) ls is.
A better what?
Am I perhaps a genius or is it just not that difficult to know two tools?
I've been using `exa` for years, and my aliases work regardless if it's installed or not. I just get a better UX if it is.
Huh. I always use plain ls with flags and deliberately unset aliases like ll.
I guess I'm weird.
Here are my aliases:
if type exa >/dev/null 2>&1; then
alias l='exa -alg --color=always --group-directories-first --git'
alias ll='exa -aliSgh --color=always --group-directories-first --git'
alias lt='exa -@alT --color=always --git'
alias lr='exa -alg --sort=modified --color=always --group-directories-first --git'
else
alias l='ls -alh --group-directories-first'
alias ll='ls -al --group-directories-first'
alias lr='ls -ltrh --group-directories-first'
fi
Aliases are not just a way to type less. They also serve as a way to define configuration. If I ever need to tweak the output for all my usage of `ls`, I can just add it to all aliases, as I've done for `--group-directories-first`.
The “inertial hump,” the learning curve, is going to be like 30 minutes, if you take 15 of those minutes to eat a sandwich.
If you want to reduce it even more, do this:
1. Install new tool.
2. In your .bashrc define some flag combinations that make it even more like your use of old tool, with similar-sounding aliases or even ones commonly used for old tool.
3. Now in the unlikely scenario that new tool goes away, you’ll still be current w old tool from those lookalike commands.
> "\" compared to "/"
Powershell :)
exa's great; it's a polished, feature-rich ls(1) that broadly improves on GNU ls. The --tree view is awesome; I wish more tools used that UX pattern. The only other one I can immediately remember is pstree.
I'll go try lsd instead (and then I'll try the other ls rewrite, har har)
- just add a backward compat alias
- make eza a transitive dependency so that exa can be sunset cleanly and adds a NEWS file entry that every user will see on upgrade to the version that drops the exa binary.
# WAS
alias ls='exa ...'
# IS
alias exa='eza ...'
alias ls='exa ...' if command -v exa &> /dev/null; then
alias ls='exa'
fi alias vim='$(command -v nvim || echo vim)'I can bear to pay that cost for "fd" (fdfind) and ripgrep but exa didn't really offer me enough.
If you spend a ton of time on remote machines you won't get control of, I can absolutely get it though. I think as long as you know the backup and you can adapt, we'll be fine most of the time. Knowing the idioms to get you part of the way there to the convenient functionality is a good enough mental polyfill.
In THAT situation the constant pain of differences in behaviour was reduced by selecting a common nonstandard tool. It is really the same argument that you're making: that being able to work roughly the same everywhere has great value.
Here are the aliases I use:
et() { exa -alT --git -I'.git|node_modules|.mypy_cache|.pytest_cache|.venv' --color=always "$@" | less -R; }
alias et1='et -L1'
alias et2='et -L2'
alias et3='et -L3'
You can use it just like the original tree tool too: https://dystroy.org/broot/tricks/#replace-tree
(disclaimer: broot author)
https://github.com/c-blake/lc/blob/master/extensions/fe1 does `du` (like your example) as a f)ormat e)xtension, but you could use `ffprobe` to do the run-time in hours:minutes:seconds for media files (or maybe 0sec for non-media) or number of git commits or age of last VC commit as an extra timestamp or numerous other things.
It almost works to replace the way I use exa tree, with these caveats:
- I want to not have it elide files ("7 unlisted") at each level. I have my et1, et2, etc. aliases to customize how many levels of detail I get with exa's tree replacement, and then I scroll that with my pager.
- I want it to support LS_COLORS so the files look the same as they do in `ls`
- I want the git status display that exa gives (eg. it shows I if the file is ignored).
- is it possible to customize the order in which the stats are shown? It'd be nice if they match ls more closely. Exa feels like `ls` with extra colors and a tree, broot feels different.
To not elide files, the easiest solution is to provide a max height: `tree --height 5000`
No support of LS_COLORS exactly.
No option today to show on a file whether it is gitignored (never considered this: my users either show gitignored files or don't).
You can completely customize file properties order: https://dystroy.org/broot/conf_file/#columns-order
(it's hard to answer complex questions and rfc here, maybe come to the chat for an interactive discussion ?)
exa --long --no-permissions --no-user --no-time --no-filesize --git --tree --color=always | rg -v -- '--' $argv
lsd --tree
> A new minor release, and the first minor release in the lifetime of eza. Why a minor release? Because we just landed windows support, that's why!
Windows support, woohoo!
ls: 38 years and counting.
Long live ls.
Luckily, of course, it's open source, so I just added the options I needed.
https://github.com/torstenvl/betterls if anyone is interested
exa seemed like overkill for my needs, and it was easier to add a couple lines of code than to learn a whole new tool.
I specifically wanted to stay close to stock because macOS `ls` is designed for the system it runs on. Installing coreutils would be counterproductive.
There might be enough other new functionality such as abbreviation or multi-attribute colorization schemes to motivate learning a new tool. E.g., neither "dot-ness" nor "directory-ness" in the above is hard-coded. They could be any other convenient elements of the typology / taxonomy.
alias ls='LC_COLLATE=C \ls -F'
exa is dead. People can move to yet another ls replacement, but they can't stay on exa.
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/ls...
Then again, ls is much more popular than exa.
the sharp stick of metal my dad gave me: 38 years and counting
long live the sharp stick of metal ?
What a terrible take. Yes, ls is maintained. Although, maintained is a very strong word. It exists. It's getting a few maintenance commits here and there, and in the mean time, it's feature done. It won't evolve anymore. Just like how exa will keep existing, and won't evolve anymore. Exa also does a hell of a lot more than ls, so will LSD, Eza and others. But keep using the sharp stick of metal if it makes you feel better.
Why would it be a strong word? Here it is, in src/ls.c: https://github.com/coreutils/coreutils
It is then packaged by tens of operating system distributions, who themselves maintain extra patchsets, some of which are then upstreamed.
It is installed and used on millions (billions?) of devices, for 3 decades.
It's a very reliable and trusty "sharp stick of metal" :)
However, when a new project arrives and does more, suddenly it's dogshit because it's stopped evolving despite doing infinitely more than ls.
Unixheads have a weird inferiority complex when it comes to anything not in coreutils.
Also, learn to use ls -F under an alias. You get the 99% of the functionality with very little.
Calling it having your tools rug-pulled from you is, quite frankly, the most moronic thing I've read today.
The screenshots should probably show underlined hard-links or italicized symlinks or other examples of "multi-file-attribute" -to- "multi-text-attribute" mapping. That kind of multi-ness seems generally neglected in this report generation space.
I don’t mind a fork was necessary; that’s pretty common with open source projects. Looking forward to eza.