[unscaled]

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?

[dahfizz]

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.

[burntsushi]

Author of ripgrep here.

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.

[koromak]

Sometimes its just for fun.

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.

[baz00]

That's mostly rubbish though.

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.

[cmrdporcupine]

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 :-)

[baz00]

I think you're reading me wrong.

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.

[Macha]

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.

[baz00]

--help doesn't do anything functional so that's not a good example.

[Macha]

-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.

[baz00]

-R does work on macOS. It's part of POSIX and macOS is actually certified Unix.

[gpm]

ls (specifically the version used on just about every linux distro) had a huge breaking change in 2016, so this is objectively false.

https://www.gnu.org/software/coreutils/quotes.html

[baz00]

I refer to my comment made before this about GNU being the wild west https://news.ycombinator.com/item?id=37419333

[drivers99]

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.

[gnubison]

Vi is in POSIX, it has been open source since 2002, and some version of it truly is on every UNIX system.

[unscaled]

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.

[Ferret7446]

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.