Hacker News Reader

Comment by noobermin | Hacker News Reader

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

View on HN

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

built in to the shell, not the kernel lol

/bin/sh is a POSIX requirement though.

sh is, but not the location.

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

Oh interesting. I assumed that since even Nix has a hard-coded /bin/sh, it must be required. Probably _essentially_ required.

There is also (at least): https://en.wikipedia.org/wiki/Stand-alone_shell

Then you will be unhappy to learn that exa itself isn't deprecated, only the original github is because the owner isn't reachable.

That isn't a metaphor; maybe you mean irony.

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.

Ummm, your comment is true, but unrelated to the parent comment you're responding to.

They're saying the word "metaphor" is incorrect, and that the original comment is describing "irony".

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

    man 2 stat

it's not rocket science.

Except it doesn't work fine, its poor design is one of the reasons for the modern replacements

I can't say I've found anything particularly wrong with it in the last 40 years.

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.

Have you tried:

    alias ls='ls -U'

? I find my ^C usually makes it through if I need it. Sometimes minimizing the terminal or switching desktops also helps.

(it probably helps that I use a filesystem - btrfs - that is fundamentally append-based so gives a meaningful order even with -U)

I have not -- thanks for the tip. Having to ^C out of an ls is sub-optimal, to say the least.

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.

I'm annoyed that ls is not the same depending on the OS

POSIX options and behaviours are the same, not extra stuffs.

And I could immediately see issues with its design, from cross-platform support to ease of configuration.

It's not wise to accept broken tools just because they persist, that's just mindless conservatism

Reply on news.ycombinator.com