I've been using LSD instead of Exa, so I'm lightly relieved that I don't have to change over.
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 absolutely love the trend of rewriting classic Unix utilities
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.
> I absolutely love the trend of rewriting classic Unix utilities
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.
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.
I much prefer lsd over exa, as lsd has better backwards compatibility with the flags. Specifically `-t` for sorting by time, exa has it specify the time field used.
I use a white terminal background, and lsd outputs yellow, which is unreadable on white. I've so far failed to stop this; e.g. it didn't seem to respect my LS_COLORS.
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 wish there was a better way for the community to handle this situation without the original author doing what we see here. Sometimes the original author dies unexpectedly for example and it's very hard to salvage the work into a maintained fork.
A nice metaphor when the "modern replacement" for something as basic as a directory listing is deprecated while the original means (the built-in ls) still works fine and isnt.
EDIT: ls on linux is apparently an executable part of GNU and not a built-in
On most Unix flavors it is not built-in. The only shell I know that has "ls" built-in is BusyBox.
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.
`ls` doesn't have a 'parent' in the hierarchy. `exa` does, it's `ls` itself, so there's a fallback. When there's no fallback, it cannot be deprecated; there's nothing to use otherwise. So it's either kept alive or forked indefinitely.
And so will exa, probably. And if it won't, it will be forked.
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?
And it will still lack many of the features that exa has. Although it's no longer maintained, I suspect it will also continue to work for a long time. There's also a fork that is still maintained.
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.
I use `exa` (and now `eza`) because it provides a better experience than GNU `ls`, IMHO. Sure, I don't _need_ it, but it's nice. I don't see any downside, especially since I've aliased it to `ls` since time immemorial and thus I only need to re-alias eza to ls again.
I've seen this take a lot in the thread but I don't really get it. Exa is a drop in ls replacement- if it breaks (which it hasn't), go back to using ls? As long as there's a reliable built in, I'm pretty happy having the possibility of needing to switch it out for some added convenience.
There's a hint of a belief in this thread - common also in threads about alternative shells and Vim setups - that someone who uses a tool like this will irrevocably lose the knowledge of how to use ls.
Am I perhaps a genius or is it just not that difficult to know two tools?
Most people don't type `ls` directly either. Aliases like `l`, `ll` and `la` are very common, in which case it really doesn't matter which tool you're using.
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.
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.
The problem is not ls. You use hundreds, thousands of commands, tools, programs, libraries every day, today is exa, tomorrow could be a different one, and then a different one. In 5 years you update your linux distribution and exa stop working, but it is not maintained anymore so there will be no fix, and then you curse yourself for building all your scripts using exa and having to update then. The probability for each individual tool in negligible, but it is multiplied by every new one you use.
Flipping tools has a cost because we have to think more about it. I don't know if you've tried flipping between the windows commandline and bash several times a day but it can be quite annoying just with things like "\" compared to "/" where the automatic part of your brain cannot take over for you and you have to do everything consciously.
This might affect me and other Debian stable users in the year 2025. The conservative side of the FOSS world rocks.
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 have the opposite feeling about package lethargy, I don't want to remember that exa is now eza at the time that my distro finally gets around to packaging eza, I want to do it now when it's right in front of me.
I'll go try lsd instead (and then I'll try the other ls rewrite, har har)
I never used exa as a general `ls` replacement, but I did use it as a `tree` replacement. Its tree view that gives you file stats from ls alongside a `tree`-like view I haven't found replicated in any other tool.
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'
exa never handled git ignores correctly so I had to manually provide common ignores with -I. But the above alias provides a scrollable tree view, with files colorized according to LS_COLORS, with file stats like `ls -l`, that I haven't found provided by any other tool. Suggestions for replacements welcome.
Seems a bit unfair to call it dead, exa's maintainer is unreachable, but the whole thing lives on as eza and is very much alive. That's a bit like saying that any company/product that changes it's name is dead at that point.
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.
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.
eza seems not like a pretty good replacement, when the first thing I see are broken icons and colors. I guess staying with exa is ok, at least it's doing it's job.
Oh never stop HN. I should never use anything except 30 year old gnu tools because they've definitely never gone through development lulls, or changed ownership. Etc. "They'll still work in years", as if exa doesn't still work just fine. People here just say the stupidest shit without an ounce of consideration of how ignorant it is.
arjvik|2 years ago
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.
bachmeier|2 years ago
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.
cb321|2 years ago
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.
Night_Thastus|2 years ago
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.
scoopr|2 years ago
UkiahSmith|2 years ago
cglong|2 years ago
da39a3ee|2 years ago
oweiler|2 years ago
elp|2 years ago
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.
renewiltord|2 years ago
jnsaff2|2 years ago
well-rustomized
There, fixed it for you.
l00sed|2 years ago
basedrum|2 years ago
l00sed|2 years ago
goku12|2 years ago
sillysaurusx|2 years ago
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.
boxed|2 years ago
I wrote about this in 2018: https://kodare.net/2018/06/25/salvaging-abandoned-projects.h...
noobermin|2 years ago
EDIT: ls on linux is apparently an executable part of GNU and not a built-in
unscaled|2 years ago
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.
monsieurbanana|2 years ago
mpalmer|2 years ago
diarrhea|2 years ago
eviks|2 years ago
dahfizz|2 years ago
unscaled|2 years ago
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?
michaelmior|2 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.
sod|2 years ago
The active maintainers moved the project to a shared repository with a different name 2 years after the creator was seen anywhere.
qalmakka|2 years ago
benrutter|2 years ago
devnullbrain|2 years ago
devnullbrain|2 years ago
Am I perhaps a genius or is it just not that difficult to know two tools?
imiric|2 years ago
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.
julianeon|2 years ago
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.
mercenario|2 years ago
t43562|2 years ago
perihelions|2 years ago
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.
broodbucket|2 years ago
I'll go try lsd instead (and then I'll try the other ls rewrite, har har)
vermaden|2 years ago
queuebert|2 years ago
ducktective|2 years ago
[1]: https://github.com/sharkdp/vivid
otterpro|2 years ago
Otek|2 years ago
kbd|2 years ago
Here are the aliases I use:
exa never handled git ignores correctly so I had to manually provide common ignores with -I. But the above alias provides a scrollable tree view, with files colorized according to LS_COLORS, with file stats like `ls -l`, that I haven't found provided by any other tool. Suggestions for replacements welcome.dystroy|2 years ago
You can use it just like the original tree tool too: https://dystroy.org/broot/tricks/#replace-tree
(disclaimer: broot author)
Macha|2 years ago
grantcarthew|2 years ago
lsd --tree
robertlagrant|2 years ago
rumdz|2 years ago
> 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!
zaptheimpaler|2 years ago
https://github.com/eza-community/eza
shapeshed|2 years ago
blueflow|2 years ago
ls: 38 years and counting.
Long live ls.
minorannoyance2|2 years ago
torstenvl|2 years ago
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.
ohgodplsno|2 years ago
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.
frou_dh|2 years ago
stavros|2 years ago
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src/ls...
Then again, ls is much more popular than exa.
zanellato19|2 years ago
cb321|2 years ago
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.
froh|2 years ago
https://github.com/eza-community/eza
baz00|2 years ago
alwillis|2 years ago
I don’t mind a fork was necessary; that’s pretty common with open source projects. Looking forward to eza.
ldelossa|2 years ago
theCodeStig|2 years ago
activitypea|2 years ago
pkulak|2 years ago
Arcuru|2 years ago
PurpleRamen|2 years ago
dvektor|2 years ago
TheDesolate0|2 years ago
[deleted]
lolrustasusual|2 years ago
[deleted]
timeon|2 years ago
It seems that you have beef with the language so you extrapolate lack of maintenance of one project to whole ecosystem?
Is that right?
predictabl3|2 years ago