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.
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.
Related: the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect)
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
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?
The muscle memory of `ls -alt` and `ls -alrt` was too powerful for me to switch to `-snew`, even after literal years.
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.
well-rustomized
There, fixed it for you.
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.
I wrote about this in 2018: https://kodare.net/2018/06/25/salvaging-abandoned-projects.h...
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.
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".
Maybe I'm bad at marketing, it seems like a pity.
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.
How is it hard? Just fork it.
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.
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.
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.
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.
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.
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.
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.
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 ...'I can bear to pay that cost for "fd" (fdfind) and ripgrep but exa didn't really offer me enough.
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)
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.
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.
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.
exa is dead. People can move to yet another ls replacement, but they can't stay on exa.
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.
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'
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" :)
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/ls...
Then again, ls is much more popular than exa.
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.