4 ms·

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

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

unscaled 3y ago
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.
- retrac 3y ago
  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.)
  - whimsicalism 3y ago
    built in to the shell, not the kernel lol
  - pkulak 3y ago
    /bin/sh is a POSIX requirement though.
    - rascul 3y ago
      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/sh.html#tag_20_117_16 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.
      - pkulak 3y ago
        Oh interesting. I assumed that since even Nix has a hard-coded /bin/sh, it must be required. Probably _essentially_ required.
- cb321 3y ago
  There is also (at least): https://en.wikipedia.org/wiki/Stand-alone_shell https://en.wikipedia.org/wiki/Stand-alone_shell
eviks 3y ago
Except it doesn't work fine, its poor design is one of the reasons for the modern replacements
- baz00 3y ago
  I can't say I've found anything particularly wrong with it in the last 40 years.
  - queuebert 3y ago
    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.
    - o11c 3y ago
      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)
      - queuebert 3y ago
        I have not -- thanks for the tip. Having to ^C out of an ls is sub-optimal, to say the least.
- JeremyNT 3y ago
  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.
mpalmer 3y ago
That isn't a metaphor; maybe you mean irony.
- sremani 3y ago
  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.
  - KingMob 3y ago
    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".
diarrhea 3y ago
`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.
- sanderjd 3y ago
  `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.
  - anthk 3y ago
    man 2 stat it's not rocket science.
monsieurbanana 3y ago
Then you will be unhappy to learn that exa itself isn't deprecated, only the original github is because the owner isn't reachable.

unscaled 3y ago

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.

retrac 3y ago
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.)
- whimsicalism 3y ago
  built in to the shell, not the kernel lol
- pkulak 3y ago
  /bin/sh is a POSIX requirement though.
  - rascul 3y ago
    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/sh.html#tag_20_117_16 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.
    - pkulak 3y ago
      Oh interesting. I assumed that since even Nix has a hard-coded /bin/sh, it must be required. Probably _essentially_ required.
cb321 3y ago
There is also (at least): https://en.wikipedia.org/wiki/Stand-alone_shell https://en.wikipedia.org/wiki/Stand-alone_shell

eviks 3y ago

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

baz00 3y ago
I can't say I've found anything particularly wrong with it in the last 40 years.
- queuebert 3y ago
  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.
  - o11c 3y ago
    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)
    - queuebert 3y ago
      I have not -- thanks for the tip. Having to ^C out of an ls is sub-optimal, to say the least.
JeremyNT 3y ago
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.

mpalmer 3y ago

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

sremani 3y ago
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.
- KingMob 3y ago
  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".

diarrhea 3y ago

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

sanderjd 3y ago
`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.
- anthk 3y ago
  man 2 stat it's not rocket science.

monsieurbanana 3y ago

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