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.
If the owner is outright missing, to the point where the newer fork owners can't even get the repo archived, one would reasonably assume that they'd need to rename/rebrand the tool in order to publish it elsewhere.
It frankly doesn't seem like a deprecation in the traditional sense.
Either way, it still speaks to the maintainability of these modern replacements, many of which are personal projects.
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.
I just have in my personal systems ls aliased to exa (with some of my preferred options like group-directories-first) and on other systems it's still ls. So my usage is the same regardless of whether it's exa or ls. This isn't a programming language or a complicated tool like jq vs competitors where what I need to do changes. I just get the nicer presentation on my local machine and "graceful degradation" back to the defaults of GNU ls on remote machines which don't have my preferred setup installed on them.
Exa is an interactive utility. It doesn't make much sense to put it in a script like that. If you were to use rg or ug instead of grep, branching like that would probably be worthwhile, though.
Yes but people did not find it daunting to create a fork.
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.
OK. Then we interpreted that comment differently. To me the point was that with ls, you don't need to worry about what happens when it's abandoned. You know it's going to be there in ten years. And probably fifty too.
Your interpretation is what I intended. Thing is, I don't anticipate ever needing to touch the code if I use the utilities installed by default on whatever Linux distribution I'm using (which includes Windows, which I use as an interface for WSL). Even if I was comfortable with Rust, which I'm not and haven't used in years, it would still take a lot of time to understand the code well enough to make changes.
Yeah, I totally get the longevity argument. But that precludes any useful new tools, and I'm personally never happy with the status quo; I don't think the software developers of the 60s and 70s discovered the perfect final set of useful userspace tools. And none of them would have thought they had either, and would have scoffed at the idea of being stuck indefinitely on a static set of commands. Their whole philosophy was about making it easy to make and cobble together little tools like this!
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.
This is a GitHub ownership model problem, not a problem with the Rust toolchain or the concept of creating modern, user-friendly command-line software.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
FWIW, my mileage definitely varied: autotools--which is quite easy if you bother to learn how it works and is then almost infinitely flexible--has pretty much never failed me (I think there was one incident for a while related to building stuff for iOS? regardless this was fixed long ago), but I have had to file and participate in a number of bugs on cargo, most of which are still open :/, and I haven't even developed anything in Rust myself yet... I've merely tried to compile and use stuff other people wrote and run into myriad ridiculous problems.
We'll just have to agree to disagree about autotools :) But I feel like I did try to bother to learn how it works, but nonetheless failed, and I think you're right that it is almost infinitely flexible, but I think that is not a good thing.
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!
Try getting autotools to work on Windows. Then try getting it to compile with Visual Studio. Then try getting it to cross-compile 32-bit binaries on a 64-bit system. If you aren't bald already I promise you'll tear your hair out.
lol, as a distro package maintainer, I've literally stopped packaging and stopped using software that uses autotools. Given me meson or give me a software compiled in a respectable language, or preferably, death. I'd take cargo and its crates.io namespace warts every day over autotools, and twice on every day of the week.
> My primary reason for using classic Unix utilities is trusting that they'll still work in a few years
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 the first utility program to segfault on me in over a decade. Brought me a useful dose of realism about the maturity of these projects, so I'm much more measured and careful about adopting them now.
For what it's worth, I'm using several Rust tools replacing classic UNIX programs for at least 3 years now and they never crashed.
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.
> 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.
> I'm not sure what this paragraph is doing in this context. I was specifically talking about my own experience.
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.
Wow. Assuming that is true/not due to a misunderstanding, that really brings a dose of reality to the "Rust is safe!" selling point. Doesn't matter if the language is technically safe, if in real world use it still segfaults (even if due to programmer misuse).
> 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.
Sounds like you probably don't want any more headaches setting up LSD, but in case anyone else is reading this, LSD will let you specify in a config to use unicode symbols, or none at all, instead of nerd font style icons which would avoid your font issues
As far as I know, Command Prompt, Powershell, WSL, etc all use the same underlying font system, TTF. And not many fonts have a TTF version. If you try using an OTF it won't be detected.
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.
So, the issue with nerdfonts is the project, itself, is broken and flawed.
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).
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).
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.
Yeah occasionally mixing a singular "they" that way is very common in english in certain contexts. Particularly when its short clear paragraphs talking about a single person. But that's still a distinction from being used as a pronoun everywhere, which can definitely get confusing quickly, even for non-ESL readers... which is all that really matters in writing/communication.
I'm seeing it more often in journalism now where multiple people or organizations are referred to through out an article and then "they" gets thrown in liberally for social etiquette. It takes serious mental effort to keep track of who they are referring to. Might as well just always use their name at that point to avoid both conflict and confusion shrug.
In this context, it could read as he and his family, or just people around him. We're all not one person, we're a reflection of people we interact with. Hence, "they".
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.
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.
We've started a non-profit to deal with such issues. It's a lot of work, but well worthwhile in the long term because part of the process is clarifying such issues, and the organization keeps on existing regardless of any individual member.
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".
Oh, I mean we started a non-profit to support our particular project (https://overte.org/), not that we've got a general purpose organization providing service to whoever needs it.
So I'm not sure we're we're a good fit, in that we're neither something comparable to Code Shelter, nor unmaintained.
> "Hey, maintainer isn't active anymore but there's still interest in the project, maybe we should do something about this"
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.
The idea is good. There's a couple of things I'd like to see. Is CodeShelter community-owned and driven? Or is it a company? The website codebase has no license and the Github application code is not open-source (or I overlooked). There's no privacy policy, ToS, and CoC. What is the maintainer vetting process? How is matchmaking taking place? What can I expect after giving away control? This may all be well-organized, but you can only find out in chat. So asking "Give us access to the repository" is a big step.
Hi. Just looking at the site. Under "adopted projects" you list Light Table. But the link just goes to the old, unmaintained repo. It would be great if you could also link to the maintained versions of repos.
The list has repos that Code Shelter has access to (ie ones that you can request to join). We don't have access to the new Light Table repo, so it wouldn't be apt to add there.
Apologies if I'm being dumb, but I'm confused. I assumed "adopted" implied that Code Shelter has some alternative repo that it (Code Shelter's community) is maintaining. Is that not the case? If not, then why list it at all?
No, "adopted" means that you gave Code Shelter permission to add contributors to your repo (the same repo you've always used). Otherwise, there wouldn't be a need for CS, since anyone can fork any repo.
CS is there to ensure continuity for the original repo (and releases).
That's very true, but that's another chicken and egg problem. GitHub won't add you if you don't have the numbers (they'd just implement this themselves, if anything).
> it's very hard to salvage the work into a maintained fork.
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.
I ready it before commenting actually...don't assume what you don't know, right? (it's against the rules: Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".https://news.ycombinator.com/newsguidelines.html ;p ;))
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.
> No, but it means that if you argue with me about what I say without having read it, then that makes you kinda silly.
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!
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.
Worth noting that the Unix shell itself is not a "built-in". The kernel is agnostic about the user interface, which is left entirely to userspace programs to implement. (That was one of Unix's major innovations.)
> 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.
Lindy effect. ls is likely to be around 40 years from now since its already been around 40 years (I am assuming it's been around since 80s correct me if I am wrong).
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.
`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.
`ls` does have a 'parent' in the hierarchy: the system calls used to implement directory listings. If `ls` were deprecated (eg. if GNU decided to deprecate it and GNU/Linux distributions actually decided to go along with that), then you or someone else would need to write a new implementation using the system calls, in order to have a useful system.
I've never had a problem with ls. What about it doesn't "work fine?"
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.
The only problem I ever have with 'ls' is accidentally listing very large directories, but that is almost always an OS and filesystem issue at the core.
If an ls replacement could somehow handle directories with >10^4 files faster, then I'd switch.
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?
I am not anti-rewrite or anti-port. There exist good reasons to rewrite software.
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.
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.
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.
Tell me that you don't/haven't worked across a variety of Unix*en without telling me that you haven't...
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.
ls does not have a consistent interface beyond the basics. And honestly, for the "portable subset", you may not even realise that ls is aliased to exa or lsd or whatever. This is why on why of my systems I'm sitting at right now, (MacOS) ls --help reports "unrecognized option `--help`" and on the other (GNU) ls reports a list of options so long that the entire alphabet is accounted for in both lower and upper case.
-R, --group-directories first are some notable, frequent options I use on GNU ls that are missing from MacOS ls. Along with every "long" option, which I like to prefer in scripts to make them more self documenting.
exa actually does support both, so in a way it's more compatible with my usage of (GNU) ls than (MacOS) ls is.
They made the change only take effect outputting directly to a tty, so it won't break scripts. This is similar to how multi-column output and color output work.
And non of them is the original vi by Bill Joy, which has been "deprecated" for years now.
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.
I don't know the state of Rust stability, so this may reveal my ignorance, but I have strong doubts that exa will continue to build let alone work in 20 years.
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.
(Not to take away from your point.) According to https://bsago.me/tech-notes/feed.json the creator was active in September 2022, one year ago. So it’s probably best to assume they’re ok.
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.
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.
> 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.
Huh. I always use plain ls with flags and deliberately unset aliases like ll.
It's hardly one character. I never need the plain output of `ls` in interactive sessions.
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
I still retain `ls -ltrh` in my muscle memory, but after years of typing it, `lr` has saved me a lot of time and effort.
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.
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.
I switch between WSL/Powershell, US/UK keyboard layouts and Ubuntu/Windows/Mac shortcuts frequently. It only usually takes one mistake to context switch. It usually harder for me to switch to things I use infrequently - but they also matter less.
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)
Ehh, I guess I'm your opposite. I want to be insulated from exciting upstream developments, especially for stable, boring stuff like coreutils. I want those to be boring. I don't want "exa is now eza" or whatever push-notified to my command line on a random Tuesday.
The Debian maintainer of the exa package can, and probably will, either:
- 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.
This is the problem with all tools outside the most basic and you have to keep muscle memory for grep and ls to deal with it. Thus the fancy replacement tools have a cost.
I can bear to pay that cost for "fd" (fdfind) and ripgrep but exa didn't really offer me enough.
I used to subscribe to this idea too, but I've since tried to leave it behind. I ended up just not using tools that gave me a benefit the majority of the time. Ripgrep is a great example. So much better than grep IMO but not going to be on that remote machine. When I need to, I'll adapt to egrep. Same with vim plugins. I ended up just not using stuff I liked so I wouldn't get used to it. Felt backwards to me.
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.
There was a time when I was working on AIX, Solaris and HPUx as well as Linux. In that situation it paid to install gnu tools everywhere (especially bash, make and sed!!) or build versions of them in my home dir so I could have them on any machine.
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.
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.
Thanks for your comment. I have broot installed, but it never sticks in my workflow. I didn't know you could use it as a tree replacement like that, adding file stats & exiting.
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.
The ability to have broot immediately exit is based on its ability to receive commands, either at start or through sockets. So in this case we're just doing `br --cmd :print_tree`. The same strategy can be used to add searches, filters, toggles, etc. before printing the tree (or printing a path).
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).
This kind of thing should probably be generalized so that any new parameter can be seamlessly woven into your `ls-like` reports.
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.
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.
This seems to heavily exaggerate the problem IMHO. Most sane people don't replace any of the basic tools like exa on critical infra that is expected to be low maintenance. Exa is a tool you install in terminals you personally use, purely for your personal comfort. And due to this situation it needs to be manually updated to a new name/new source, it's a one time operation. Surely not ideal, but hardly an unsurmountable obstacle. People using tools like this aren't exactly the sort of audience that is unfamiliar with having to install/uninstall a package.
It's also a whole other tool and in Nim to boot, but https://github.com/c-blake/lc allows you to group "dot-directories" before "dot-files" before "non-dot directories" before non-dot files.
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.
Last I checked, GNU coreutils don't know anything about, e.g., macOS extended attributes.
I specifically wanted to stay close to stock because macOS `ls` is designed for the system it runs on. Installing coreutils would be counterproductive.
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.
I like how people are arguing that ls is alive, like there is active work being done on it over 38 years. A Unix tool that does one thing well can be considered finished and sit for years without anything going on. That doesn't mean it's dead. Sure, maybe people want fancy new stuff, but again, doesn't mean dead. If it had security problems for years, then one could argue that it's dangerous for it not to be updated and if it isn't, then proclaim it dead so people will move to something safer, but this trend to call something dead because it isn't in rust and doesn't have colors and git awareness? Meh
Exactly! ls is alive, and just exists, mostly. The commits done on it are extremely minor changes to save up 0.0001% of performance and because the APIs it was using are sometimes deprecated. And that's fine!
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.
Is exa gone ? Can you not download exa anymore ? Are the binaries deleted from the internet ? Is the source completely overwritten ? Has it been removes from crates.io and from package managers ? Has it suddenly stopped listing files in your folders?
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.
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.
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.