42 ms·

There seems to be a lot of projects that is now competing to replace ls (for people preferences) For reference, those are the ones I am familiar with. They are

There seems to be a lot of projects that is now competing to replace ls (for people preferences) For reference, those are the ones I am familiar with. They are somehow active in contrast to things like exa which is not maintained anymore. eza: (https://github.com/eza-community/eza https://github.com/eza-community/eza) lsd: (https://github.com/Peltoche/lsd https://github.com/Peltoche/lsd) colorls: (https://github.com/athityakumar/colorls https://github.com/athityakumar/colorls) g: (https://github.com/Equationzhao/g https://github.com/Equationzhao/g) ls++: (https://github.com/trapd00r/LS_COLORS https://github.com/trapd00r/LS_COLORS) logo-ls: (https://github.com/canta2899/logo-ls https://github.com/canta2899/logo-ls) - this is forked because main development stopped 4 years ago. Any more? Personally I prefer eza and wrote a zsh plugin that is basically aliases that matches what I have from my muscle memory.

dhruvkb 2y ago
I wanted to plug `pls`[1], a tool that I wrote and maintain. It does a few things that `eza` (another great tool nonetheless, and a massive inspiration) cannot do[2]. [1]: https://pls.cli.rs https://pls.cli.rs [2]: https://pls.cli.rs/about/comparison/ https://pls.cli.rs/about/comparison/
iroddis 2y ago
I’ve tried a few of these, but most of them seem to be following the trend of folding other shell functionality into one tool. Searching for contents (find + grep -H, or ripgrep), filtering (grep), sorting (ls does it natively, or you can use sort, sort -h for sorting human readable sizes), the list goes on and on. I guess this is a mini lament that many of these tools are moving away from the Unix philosophy of do one thing well, and make it easy to chain. And a last very small lament that BeOS didn’t succeed, and their filesystem-as-a-database approach didn’t become more standard.
- burntsushi 2y ago
  You can still chain ripgrep. I specifically designed it so that you can chain it just like you would a normal grep. It does indeed also include other functionality that might traditionally be left to other tools (like filtering files). But this is nothing that GNU grep wasn't already doing itself anyway. IMO, it's better to view the Unix philosophy as a means to an end and not an end to itself. And IMO, it's important to weigh the benefits of coupling to the user experience.
  - fsckboy 2y ago
    >view the Unix philosophy as a means to an end and not an end to itself it won't be a means to an end any more if you don't preserve it, so not breaking that aspect of it has to be one of your ends. if you use it to take ls to a new place but that place is not within the ecosystem, it will be an evolutionary dead end, or worse, the first meteor in the meteor storm that ends all life. current/traditional unix may not be the be-all/end-all, but replacing it/changing it requires viewing it comprehensively and changing all the tools at once or having a plan to. A good example of this is Plan9
    - burntsushi 2y ago
      I don't know what you're trying to say and I don't see how it's in conflict with anything I've said.
      - fsckboy 2y ago
        >not an end to itself it is an end to itself. the reason it's a means to an end is because that was its end goal. in being a means to an end, it is an end (its end) unto itself, opposite to what you said, imho
        burntsushi 2y ago
        I still can't parse what you're saying. The Unix philosophy is a means to an end, where the ultimate end is improved user experience. The means is de-coupling and composition. But there are other means to improving the user experience. > in being a means to an end, it is an end (its end) unto itself This either makes zero sense or is vacuously true and clearly not in conflict with what I'm saying.
  - L3viathan 2y ago
    I think ripgrep specifically is counted in the comment you reply to as a tool that _does_ do one thing well, and that one should use it (or grep) in combination with an ls, instead of giving ls filtering abilities.
- Retr0id 2y ago
  vanilla ls has never been particularly chainable - https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs
  - machinestops 2y ago
    A lot of this post hinges on the fact that newlines in filenames were legal, and that people wrote shell without handling quoting correctly. While quoting (as well as ls altering filenames) is still an issue, find -print0, read -d '', and similar are no longer neccessary. Newlines are now forbidden in filenames: https://blog.toast.cafe/posix2024-xcu https://blog.toast.cafe/posix2024-xcu
    - CJefferson 2y ago
      Linux isn't POSIX compliant, and as far as I know has no plans to ban newlines in filenames, or even add an option to disable newlines.
      - pyuser583 2y ago
        I know Linux allows newlines in filenames, but every time I hear it I want to drink.
      - machinestops 2y ago
        In past, there have been Linux-based operating systems that have been certified as Single Unix Specification compliant, and part of said specification is POSIX. I would imagine GNU and Busybox and Musl will be willing to implement the changes proposed by POSIX 2024, which inevitably leads down the road of newlines being banned.
        CJefferson 2y ago
        Howw would that work? Checking strings passed to open and rejecting them? Would we then have undeletable files, as we can't refer to their filenames?
    - 2y ago
- eviks 2y ago
  They don't do one thing well since it's all text, not structured data, which makes chained analysis a challenge, which leads to the desire for integration
  - bayindirh 2y ago
    ls is tabular data, and you can format it (ls -1, ls -l, ls -w, plus sorting, field formatting, and more), and you can cut/parse/format in a standard way. Every field sans the filename is fixed length, can be handled with awk/cut/sed according your daily mood and requirements, etc. etc. So, ls can be chained very nicely, which I do every day, even without thinking. You don't need to have a "structured data with fields" to parse it. You just need to think it like a tabular data with line/column numbers (ls -l, etc.) or just line numbers (ls -1). So, as long as ls does one thing well, it's alright. Ah, some of the "enhanced" ls tools can't distinguish between pipe and a terminal, and always print color/format escape codes to pipe too, doubling the fun of using them. So, thanks, I'll stick with my standard ls. That one works.
    - eviks 2y ago
      > You don't need to have a "structured data with fields" to parse it. You do if you want to have nice things like being able to format your output without having to worry about breaking the dumb tools down the pipe, which can't sort the numbers they don't see: - 2.1K (this isn't the same as the second) - 2.1K - 2.1M Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size"? > print color/format escape codes to pipe too A problem that would disappear with... structured data! > Ah, some of the "enhanced" ls tools so use the other "some" that can?
      - bayindirh 2y ago
        > which can't sort the numbers they don't see Then you sort at the point you can see the numbers and discard them later. > Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size" awk can sort the columns for you. Plus, ls can already sort by size. Try "ls -lS " for biggest file first, or "ls -lSr" for smallest file first. Add "-h" to make human readable. > A problem that would disappear with... structured data! No. A problem that would disappear with "a small if block which asks which environment I'm in". If you're in a shell "-t" test in sh/bash will tell you that. If you're coding a tool, there are standard ways to do that (via termcap IIRC). Standard UNIX tools are doing this for decades now. IOW, structured data is not a cure for laziness... > so use the other "some" that can? Yes, because their authors are not that lazy.
- amelius 2y ago
  I agree with this. If they want something that is easy to use in a non-scriptable way, maybe they should replicate Norton Commander instead.
  - darkest_ruby 2y ago
    Look into far2l
- from-nibly 2y ago
  If you like that philosophy check out nushell. They go pretty hard core on that and they can because of structured output
vunderba 2y ago
Eza is great. I was pleasantly surprised at how nice the mime type icons meshed with the terminal.
treve 2y ago
It's a rite of passage. I had some colorful 'dir' alternatives on MS-DOS 5 and eventually made my own with Turbo Pascal. Easy & fun afternoon project
cb321 2y ago
lc: https://github.com/c-blake/lc https://github.com/c-blake/lc (in Nim).
medv 2y ago
Also “walk” is great for interactive navigation. - https://github.com/antonmedv/walk https://github.com/antonmedv/walk
bawolff 2y ago
Tbh, i dont understand why people want to rewrite ls of all things. Like don't get me wrong, if they had fun, that's great. But all i use ls for is getting a list of files. I barely ever even use the -la options. There just doesn't seem like a lot of room for improvement in something so simple.
- dhruvkb 2y ago
  Hi, author of `pls`[1] here. I started `pls` as a hobby project to scratch a personal itch: a "prettier" alternative to `ls`, with more colors and customisable icons. I also wanted to learn Rust as a secondary motivation. But as I added more and more features to it, it has become a good tool that does a number of things that `ls` doesn't do (unless you chain it with other tools like `sort` or `grep`) and even other `ls` replacements don't do. So even though `ls` is fantastic as-is, it's always fun to build something of your own, add a little more polish in areas that matter to you and put it out there to see if it resonates with more people. [1]: https://pls.cli.rs https://pls.cli.rs
- roywashere 2y ago
  Well, recursive display is nice, I guess, as well as searching on partial filenames
  - mbivert 2y ago
    Has been roughly doing the job since the 70s (?): $ du -a | grep blbl
- benrutter 2y ago
  I think the standard ls doesn't have much in terms of color/icons, so its simplicity probably makes it a great side project for improving on. Not a big surface area, some easy improvements. A whole lot less stressful than rewriting grep (although I'm massively grateful Burnt Sushi did such a crazy thing)
  - triyanox 2y ago
    Thanks @benrutter! You nailed it - ls is like the "Hello World" of system tools. Simple enough that you won't tear your hair out, but meaty enough to learn a ton. Started with "ooh, pretty colors!" and before I knew it I was deep in filesystem APIs and terminal wizardry. Way less scary than tackling grep. Sometimes the best projects are the ones where you can't mess up too badly... well, unless you accidentally delete everything while testing
bastardoperator 2y ago
I also used eza to replace the tree command with the --tree flag.
triyanox 2y ago
Thanks for the great list! Yep, eza and g are fantastic - I actually use eza daily and love how g handles git integration. What made me excited to experiment with lla was playing with the plugin architecture. While these other tools have great built-in features, I wanted to see if I could make something where the community could easily add their own capabilities without touching the core code. Kind of like how vim and neovim handle plugins. Got inspired by how people keep building these ls alternatives to scratch their own unique itches. Figured why not make it easier for everyone to scratch their own itch through plugins? Still very much an experiment, but it's been fun seeing what's possible!
deleted 2y ago
[deleted]
ZoomZoomZoom 2y ago
Take a look at lc (but not the terminal screenshots! ;)): https://github.com/c-blake/lc https://github.com/c-blake/lc lc is a highly configurable "multi-dimensional"[1] file lister written in Nim focused on flexibility and configurability. Key features: - Multi-level sorting by combinations of attributes like size, time, and file type, with user-defined precedence - Configurable file kind sorting order - Value-dependent coloring for file attributes such as timestamps, permissions, or sizes. - Abbreviations: Automatically shorten filenames, user/group names or symlink targets. - File type classification: Integrates libmagic for file type inspection. - Hyperlink support - Per-directory configs: custom behaviors for specific directories using local tweak files (.lc). - Lightweight (~900 lines of code) with only author's CLI library "cligen" and Nim's stdlib as dependencies. and more. [1]: https://github.com/c-blake/lc#vector-typemulti-dimensionalityattribute-layers https://github.com/c-blake/lc#vector-typemulti-dimensionalit...

dhruvkb 2y ago

I wanted to plug `pls`[1], a tool that I wrote and maintain. It does a few things that `eza` (another great tool nonetheless, and a massive inspiration) cannot do[2]. [1]: https://pls.cli.rs https://pls.cli.rs [2]: https://pls.cli.rs/about/comparison/ https://pls.cli.rs/about/comparison/

iroddis 2y ago

I’ve tried a few of these, but most of them seem to be following the trend of folding other shell functionality into one tool. Searching for contents (find + grep -H, or ripgrep), filtering (grep), sorting (ls does it natively, or you can use sort, sort -h for sorting human readable sizes), the list goes on and on. I guess this is a mini lament that many of these tools are moving away from the Unix philosophy of do one thing well, and make it easy to chain. And a last very small lament that BeOS didn’t succeed, and their filesystem-as-a-database approach didn’t become more standard.

burntsushi 2y ago
You can still chain ripgrep. I specifically designed it so that you can chain it just like you would a normal grep. It does indeed also include other functionality that might traditionally be left to other tools (like filtering files). But this is nothing that GNU grep wasn't already doing itself anyway. IMO, it's better to view the Unix philosophy as a means to an end and not an end to itself. And IMO, it's important to weigh the benefits of coupling to the user experience.
- fsckboy 2y ago
  >view the Unix philosophy as a means to an end and not an end to itself it won't be a means to an end any more if you don't preserve it, so not breaking that aspect of it has to be one of your ends. if you use it to take ls to a new place but that place is not within the ecosystem, it will be an evolutionary dead end, or worse, the first meteor in the meteor storm that ends all life. current/traditional unix may not be the be-all/end-all, but replacing it/changing it requires viewing it comprehensively and changing all the tools at once or having a plan to. A good example of this is Plan9
  - burntsushi 2y ago
    I don't know what you're trying to say and I don't see how it's in conflict with anything I've said.
    - fsckboy 2y ago
      >not an end to itself it is an end to itself. the reason it's a means to an end is because that was its end goal. in being a means to an end, it is an end (its end) unto itself, opposite to what you said, imho
      - burntsushi 2y ago
        I still can't parse what you're saying. The Unix philosophy is a means to an end, where the ultimate end is improved user experience. The means is de-coupling and composition. But there are other means to improving the user experience. > in being a means to an end, it is an end (its end) unto itself This either makes zero sense or is vacuously true and clearly not in conflict with what I'm saying.
- L3viathan 2y ago
  I think ripgrep specifically is counted in the comment you reply to as a tool that _does_ do one thing well, and that one should use it (or grep) in combination with an ls, instead of giving ls filtering abilities.
Retr0id 2y ago
vanilla ls has never been particularly chainable - https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs
- machinestops 2y ago
  A lot of this post hinges on the fact that newlines in filenames were legal, and that people wrote shell without handling quoting correctly. While quoting (as well as ls altering filenames) is still an issue, find -print0, read -d '', and similar are no longer neccessary. Newlines are now forbidden in filenames: https://blog.toast.cafe/posix2024-xcu https://blog.toast.cafe/posix2024-xcu
  - CJefferson 2y ago
    Linux isn't POSIX compliant, and as far as I know has no plans to ban newlines in filenames, or even add an option to disable newlines.
    - pyuser583 2y ago
      I know Linux allows newlines in filenames, but every time I hear it I want to drink.
    - machinestops 2y ago
      In past, there have been Linux-based operating systems that have been certified as Single Unix Specification compliant, and part of said specification is POSIX. I would imagine GNU and Busybox and Musl will be willing to implement the changes proposed by POSIX 2024, which inevitably leads down the road of newlines being banned.
      - CJefferson 2y ago
        Howw would that work? Checking strings passed to open and rejecting them? Would we then have undeletable files, as we can't refer to their filenames?
  - 2y ago
eviks 2y ago
They don't do one thing well since it's all text, not structured data, which makes chained analysis a challenge, which leads to the desire for integration
- bayindirh 2y ago
  ls is tabular data, and you can format it (ls -1, ls -l, ls -w, plus sorting, field formatting, and more), and you can cut/parse/format in a standard way. Every field sans the filename is fixed length, can be handled with awk/cut/sed according your daily mood and requirements, etc. etc. So, ls can be chained very nicely, which I do every day, even without thinking. You don't need to have a "structured data with fields" to parse it. You just need to think it like a tabular data with line/column numbers (ls -l, etc.) or just line numbers (ls -1). So, as long as ls does one thing well, it's alright. Ah, some of the "enhanced" ls tools can't distinguish between pipe and a terminal, and always print color/format escape codes to pipe too, doubling the fun of using them. So, thanks, I'll stick with my standard ls. That one works.
  - eviks 2y ago
    > You don't need to have a "structured data with fields" to parse it. You do if you want to have nice things like being able to format your output without having to worry about breaking the dumb tools down the pipe, which can't sort the numbers they don't see: - 2.1K (this isn't the same as the second) - 2.1K - 2.1M Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size"? > print color/format escape codes to pipe too A problem that would disappear with... structured data! > Ah, some of the "enhanced" ls tools so use the other "some" that can?
    - bayindirh 2y ago
      > which can't sort the numbers they don't see Then you sort at the point you can see the numbers and discard them later. > Also, why do I need to count columns like a cave man in 'sort -k 5' instead of doing the obvious "sort by size" awk can sort the columns for you. Plus, ls can already sort by size. Try "ls -lS " for biggest file first, or "ls -lSr" for smallest file first. Add "-h" to make human readable. > A problem that would disappear with... structured data! No. A problem that would disappear with "a small if block which asks which environment I'm in". If you're in a shell "-t" test in sh/bash will tell you that. If you're coding a tool, there are standard ways to do that (via termcap IIRC). Standard UNIX tools are doing this for decades now. IOW, structured data is not a cure for laziness... > so use the other "some" that can? Yes, because their authors are not that lazy.
amelius 2y ago
I agree with this. If they want something that is easy to use in a non-scriptable way, maybe they should replicate Norton Commander instead.
- darkest_ruby 2y ago
  Look into far2l
from-nibly 2y ago
If you like that philosophy check out nushell. They go pretty hard core on that and they can because of structured output

vunderba 2y ago

Eza is great. I was pleasantly surprised at how nice the mime type icons meshed with the terminal.

treve 2y ago

It's a rite of passage. I had some colorful 'dir' alternatives on MS-DOS 5 and eventually made my own with Turbo Pascal. Easy & fun afternoon project

cb321 2y ago

lc: https://github.com/c-blake/lc https://github.com/c-blake/lc (in Nim).

medv 2y ago

Also “walk” is great for interactive navigation. - https://github.com/antonmedv/walk https://github.com/antonmedv/walk

bawolff 2y ago

Tbh, i dont understand why people want to rewrite ls of all things. Like don't get me wrong, if they had fun, that's great. But all i use ls for is getting a list of files. I barely ever even use the -la options. There just doesn't seem like a lot of room for improvement in something so simple.

dhruvkb 2y ago
Hi, author of `pls`[1] here. I started `pls` as a hobby project to scratch a personal itch: a "prettier" alternative to `ls`, with more colors and customisable icons. I also wanted to learn Rust as a secondary motivation. But as I added more and more features to it, it has become a good tool that does a number of things that `ls` doesn't do (unless you chain it with other tools like `sort` or `grep`) and even other `ls` replacements don't do. So even though `ls` is fantastic as-is, it's always fun to build something of your own, add a little more polish in areas that matter to you and put it out there to see if it resonates with more people. [1]: https://pls.cli.rs https://pls.cli.rs
roywashere 2y ago
Well, recursive display is nice, I guess, as well as searching on partial filenames
- mbivert 2y ago
  Has been roughly doing the job since the 70s (?): $ du -a | grep blbl
benrutter 2y ago
I think the standard ls doesn't have much in terms of color/icons, so its simplicity probably makes it a great side project for improving on. Not a big surface area, some easy improvements. A whole lot less stressful than rewriting grep (although I'm massively grateful Burnt Sushi did such a crazy thing)
- triyanox 2y ago
  Thanks @benrutter! You nailed it - ls is like the "Hello World" of system tools. Simple enough that you won't tear your hair out, but meaty enough to learn a ton. Started with "ooh, pretty colors!" and before I knew it I was deep in filesystem APIs and terminal wizardry. Way less scary than tackling grep. Sometimes the best projects are the ones where you can't mess up too badly... well, unless you accidentally delete everything while testing

bastardoperator 2y ago

I also used eza to replace the tree command with the --tree flag.

triyanox 2y ago

Thanks for the great list! Yep, eza and g are fantastic - I actually use eza daily and love how g handles git integration. What made me excited to experiment with lla was playing with the plugin architecture. While these other tools have great built-in features, I wanted to see if I could make something where the community could easily add their own capabilities without touching the core code. Kind of like how vim and neovim handle plugins. Got inspired by how people keep building these ls alternatives to scratch their own unique itches. Figured why not make it easier for everyone to scratch their own itch through plugins? Still very much an experiment, but it's been fun seeing what's possible!

deleted 2y ago

[deleted]

ZoomZoomZoom 2y ago

Take a look at lc (but not the terminal screenshots! ;)): https://github.com/c-blake/lc https://github.com/c-blake/lc lc is a highly configurable "multi-dimensional"[1] file lister written in Nim focused on flexibility and configurability. Key features: - Multi-level sorting by combinations of attributes like size, time, and file type, with user-defined precedence - Configurable file kind sorting order - Value-dependent coloring for file attributes such as timestamps, permissions, or sizes. - Abbreviations: Automatically shorten filenames, user/group names or symlink targets. - File type classification: Integrates libmagic for file type inspection. - Hyperlink support - Per-directory configs: custom behaviors for specific directories using local tweak files (.lc). - Lightweight (~900 lines of code) with only author's CLI library "cligen" and Nim's stdlib as dependencies. and more. [1]: https://github.com/c-blake/lc#vector-typemulti-dimensionalityattribute-layers https://github.com/c-blake/lc#vector-typemulti-dimensionalit...