12 ms·

Show HN: I made an ls alternative for my personal use

197 points by triyanox 2y ago

ivanjermakov 2y ago
Does UNIX philosophy holds anymore? Most of the modern CLI tools I've seen here try to be all at once: file manager, git client, grep. I wonder if it was always like this or we're getting further and further from the idea of keeping programs simple and open.
- Cthulhu_ 2y ago
  I would say it does; those tools rarely reimplement the functions you mention, but are abstractions on top of existing CLIs or libraries that do follow the UNIX philosophy. This project in particular is not being sold as a drop-in replacement for ls.
- deleted 2y ago
  [deleted]
dhruvkb 2y ago
While you've specifically labeled this as "personal use", it is a commendable project that introduces some interesting new ideas. I might steal some ideas from it for my own `ls` alternative, `pls`[1]. [1]: https://pls.cli.rs https://pls.cli.rs
- Cthulhu_ 2y ago
  "pls" as in "please give me a list of files"? Does `sudo pls` negate the "please"? :p
Koshkin 2y ago
I didn't know that ls was missing plugins.
hobs 2y ago
This github page doesn't say anything about why it turned out to be amazing, seems like a fun side project.
- fellowniusmonk 2y ago
  Yeah, why use this instead of ls? What makes it worthwhile as a daily driver?
- netsharc 2y ago
  Yeah, talk about hiding the headline... I see a screenshot that looks like the output of ls, ok it has colors, and some filenames have "!!" behind it. Great success?
  - triyanox 2y ago
    Haha! Aren't all rust rewrites about colors take `bat` for example! Btw "!!" are from the git plugin, a quick way to see my workspace git status
tambourine_man 2y ago
brew support?
- triyanox 2y ago
  Great idea! I will be working on it!
dbacar 2y ago
Categorization and hashes seem to be good ideas, yet you could do all of these with other tools already. You could be knowing the tool 'exa', a similar ls alternative. Just wanted to mention.
elashri 2y ago
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.
imoverclocked 2y ago
Did anyone here use Genera on an original lisp machine? It had a pseudo-graphical interface and a directory listing provided clickable results. It would be really neat if we could use escaping to confer more information to the terminal about what a particular piece of text means. Feature-request: bring back clickable ls results! Bonus points for defining a new term type and standard for this.
- dotancohen 2y ago
  > Feature-request: bring back clickable ls results! Doesn't your desktop (or distro) have a graphical file manager? On KDE it's Dolphin, which ex-Windows users absolutely love. I don't know what it would be on Gnome or other desktops.
  - shakna 2y ago
    My ssh client also supports mouse events, though.
  - mabster 2y ago
    I'm not going to speak for Linux, but on Mac the Finder is annoying enough that I ended up using CLI for file manipulation (ranger).
- yjftsjthsd-h 2y ago
  It's not really that, but have you tried ranger?
- rphln 2y ago
  There's already `ls --hyperlink` for clickable results, but that depends on your terminal supporting the URL escape sequence.
  - westurner 2y ago
    $ man ls | grep '\--hyperlink' -A 1 --hyperlink[=WHEN] hyperlink file names WHEN
  - 2y ago
bornfreddy 2y ago
I use git command line interface. Not because it is good (it isn't) or because I enjoy suffering (I think I don't), but because it is a standard on all the machines that have, you know, git. What good is a ls alternative if I need to install it everywhere I need ls? I'd prefer using the standard ls even if it is not ideal. But maybe that's just me.
- matheusmoreira 2y ago
  Ubiquitousness is certainly a major selling point. The GNU coreutils are everywhere. I've made my peace with bash and make because I know they're always gonna be there. This doesn't mean there's no value in developing one's own tools. Contributing to other projects can be quite difficult and time consuning. GNU projects are even more so. We shouldn't limit ourselves to POSIX stuff either. Better software and tools can and should be built. Every attempt is valuable. And who knows? It might just turn into a staple of Linux distributions some day.
- SoftTalker 2y ago
  Even ls isn't standard on all machines. GNU ls is different from BSD ls.
- mshockwave 2y ago
  This is also one of the reasons I write C++ with vim without any auto-completion nor fancy plugins (I do use syntax highlighting though, but I think it comes by default with vim nowadays), as well as using GNU screen -- not every machines install tmux by default, surprisingly. In case I need to login into some random Linux box, I'm sure I'll be almost as productive as I am on my own machine.
  - whartung 2y ago
    I did the same thing back in they day. I developed on SCO (and, later, Unixware) on a PC, all of the clients were running the gamut of Unix OSes: HPUX, DGUX, AIX, SunOS, you name it. Most of the time was spent on our box in the office, but I was constantly bouncing back and forth to client systems. Either on site, or over the modem. Having to juggle Termcaps and the whole thing. It was polyglot machine/OS world back then. Just had to learn to get the best out of a baseline set of Unix tools. vi instead of emacs, awk instead of perl. Master those and never be left wanting on a new environment, so I can hit the ground running. No need to "bootstrap" (if the client would even let you, not always). Couldn't even rely on a C compiler.
iwontberude 2y ago
The things I take for granted. This is a breath of fresh air! Way to rethink the fundamentals!
- skrebbel 2y ago
  I can't tell if you're being sarcastic or not.
  - iwontberude 2y ago
    For the record I was not being sarcastic but maybe I was feeling a bit too romantic or overly supportive of OP
    - cb321 2y ago
      I notice prior HN comments of yours mention the physical design of the NeXT cube. I cannot say it will make you not hate software, but you still might appreciate that another alternative ls, https://github.com/c-blake/lc https://github.com/c-blake/lc, both re-thinks/breaks more radically with ls-tradition and adapts well to something very similar to a terminal variant of the https://en.wikipedia.org/wiki/Miller_columns https://en.wikipedia.org/wiki/Miller_columns used in the NeXT file tree graphical browser/navigator via simple shell process substitution composition. E.g., a 3-level scenario on an 80-column looks like: paste <(lc -1m25 ../..) <(lc -1m25 ..) <(lc -1m25 .) Some shell script that uses $((COLUMNS)) arithmetic to do 2 or 4 or whatever terminal width is a pretty simple exercise for the reader and one might want to pipe to less.
vunderba 2y ago
Sounds like a fun project. However, from the readme: Efficient file listing: Optimized for speed, even in large directories What exactly is it doing differently to optimize for speed? Isn't it just using the regular fs lib?
- jeffbee 2y ago
  On my system it uses twice as much CPU as plain old ls in a directory with just 13k files. To recursively list a directory with 500k leaf files, lla needs > 10x as much CPU. Apparently it is both slower and with higher complexity.
  - matheusmoreira 2y ago
    What exactly makes ls faster?
  - triyanox 2y ago
    On the latest release the it can list a tree of 100 in depth with over 100k files in less than 100ms and if cached 40ms
  - inquisitive-me 2y ago
    But it’s written in rust so it’s super fast. Did you take that into account when running your benchmarks? /s
  - triyanox 2y ago
    Will definitely prioritize optimization in the next releases. Planning to benchmark against ls on various systems and file counts to get this properly sorted.
  - niek_pas 2y ago
    Not trying to “gotcha” you, but I would imagine that 10x the CPU of ls is still very little, or am I wrong?
    - jeffbee 2y ago
monroewalker 2y ago
Other than colorization, what are people getting out of ls replacements like this? I've recently started using ranger which might replace my ls usage for the most part since it not only shows everything in the directory but has vim like shortcuts for filtering, sorting, and searching the directory as well as previewing files and entering other directories
- dhruvkb 2y ago
  Hi, author of `pls`[1] here. `pls` goes above and beyond what is typically possible with `ls` without going so far as to become an entire TUI file explorer like Broot[2]. Among a few things it does that `ls` (and other alternatives like `eza` don't do) are: - icons (SVG icons in terminals that support it, Nerd Fonts otherwise) - advanced filtering using regex - advanced sorting across multiple sort bases - styles and colors using customisable rules For someone wanting to make the output of `ls` prettier (with a few extra bells and whistles) without having to relearn a new workflow, something like an `ls` replacement makes more sense. [1]: https://pls.cli.rs https://pls.cli.rs [2]: https://dystroy.org/broot/ https://dystroy.org/broot/
  - pmarreck 2y ago
    pls looks useful and I will retain it but eza is giving more icons for more things via (this is my alias for `l`, basically) `eza --long --hyperlink --header --all --icons --git --sort name` also the hyperlink thing is useful
- throwaway984393 2y ago
  [dead]
- Symbiote 2y ago
  ls does colored output. I'm surprised it's not the default for you.
  - cb321 2y ago
    If you run `dircolors --print-database|less` you will see that GNU ls only highlights/colors the path/filenames according to a simplistic scheme where a file can only resolve to one type even though on many terminals today "foreground overlays background overlays bold/italic/etc". (https://github.com/c-blake/lc#vector-typemulti-dimensionalityattribute-layers https://github.com/c-blake/lc#vector-typemulti-dimensionalit... has a more advanced idea.) This tool by triyanox -- just from the screen shot if you click through -- will also colorize permission masks and sizes, dates, user & group.
throwaway984393 2y ago
[dead]
zvr 2y ago
Creating command-line utilities is nice, but I personally lament the lack of man pages when people write something new.
- triyanox 2y ago
  That's the amazing part I'm talking about the learning experience you get from weeks of working on something like that is better than reading countless documentations
  - zvr 2y ago
    Oh, of course the development is fun and exciting and a learning experience. But before inviting others to use something, please think of how to make its use more clear. After all, I assume you post this so that people use it, not only admire your coding skills. There is a group of people who have learned to read and rely on man pages. For example, the top-level README says: > -s, --sort <CRITERIA>: Sort by "name", "size", or "date" OK, does "date" refer to creation date, modification date, access date? I can understand "size", but does it produce smallest-first or largest-first? It might not matter if... ah, no, there is no -r/--reverse flag. Can I have more than one "criteria" (since the plural is used)? Getting answers for such questions now means I have to go read the code in src/args.rs and follow to the implementation of the various functions. And in a few days, when I have the same questions again and I have forgotten the options, I will again have to dive into the code. Please consider providing a short man page. It documents the "calling interface" to your program and makes it easier to use. I usually start writing one even before implementing the whole thing, to clearly articulate what I expect the program to do.
    - triyanox 2y ago
      Fair critique about the documentation - this needs proper attention. Writing a man page first is a solid approach - it forces clear thinking about the interface before implementation. I'll prioritize adding complete documentation for all options and the plugin system. The code works, but without good docs it's not truly useful.
  - 2y ago
mellosouls 2y ago
I clicked on this (without noting "github") expecting an essay on the joys of building an alternative to ls. This is basically a Show HN without a summary I think. fwiw: https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
eviks 2y ago
Excellent new idea re plugins, a lot of these tools are too inflexible !
- cb321 2y ago
  `lc` mentioned elsethread [1] was always extensible with plugins for formatting and file-typing (but also always supported libmagic-based file-typology). There are other fairly distinctive ideas in `lc`, actually.. the README has a list. While I like it and it's a good idea, I think the reality is that developers capable enough to write shared library/DLL plugins are more likely to just submit PRs and make such stuff built-in but maybe optional. [1] https://news.ycombinator.com/item?id=42229841 https://news.ycombinator.com/item?id=42229841
  - eviks 2y ago
    "Always" is just 4 years? Lc is also one of these new tools > more likely to just submit PRs and make such stuff built-in but maybe optional. Which are more likely to just be rejected by the more conservative maintainers of the tool. That's the empowering beauty of plugins - no such barriers
    - cb321 2y ago
      Your tone is rather disputatious/critical, but we have literally no dispute here.
yasser_kaddoura 2y ago
I have these aliases for various purposes: # Different options to search for files # da=36 cyan timestamps alias ls="EZA_COLORS='da=36' eza --time-style=relative --color-scale=age" alias lsa="ls --almost-all" # ignore . .. alias l="ls --long --classify=always" # show file indicators alias la="l --almost-all" # Tree view alias ltreea="ls --tree" alias ltree="ltreea --level=2" # Sort by time or size alias lt="ls --long --sort=time" alias lta="lt --almost-all" # lsd is faster than eza alias lss="lsd --long --total-size --sort=size --reverse" alias lssa="lss --almost-all" lla seems to go beyond what ls should do for some reason. Why show git and code complexity info? Just use tools dedicated for these things, otherwise, it will be an unmaintainable mess. If you can solve a problem easily with external tools, then there's no reason to add a feature for it.
- tejohnso 2y ago
  That's a great list. I have a similar list and the aliases grow out of frequently used arguments. For example, I found myself often doing an ls -Altch and so lsth was born. I find that aliases that or born of frequently used arguments are easily remembered. Over time that one grew to include a pipe to head because most of the time I just want to see the top 20 or so most recently modified files in the directory.
- deleted 2y ago
  [deleted]
p2detar 2y ago
Coloring files of the same file-type is my favorite feature. Is the extension used to group them or a MIME-header parser? I guess the extension, since it is faster.
- Symbiote 2y ago
  This is also part of GNU ls, at least. man dir_colors I think.
  - johnisgood 2y ago
    You are right.
triyanox 2y ago
Thanks for all the feedback! Let me clarify a few things about lla. The most amazing part of this project wasn't just building another ls alternative - it was the incredible learning journey. Building a systems tool in Rust while implementing a plugin architecture taught me more in a few weeks than months of reading could have. Yes, it does more than traditional ls, and that's intentional. The plugin system came from scratching my own itch of constantly switching between different terminal tools. Each feature added was a chance to dive deeper into systems programming and Unix internals. The performance still needs work, and the documentation could be better. But that's the beauty of open source - you ship it, learn from the feedback, and keep improving. Building in public is an incredible way to level up your skills. For anyone considering a similar project: pick a common tool you use daily and try reimagining it. You'll be surprised how much you learn along the way.
porridgeraisin 2y ago
One slept on filesystem cli tool on linux is `gio`. So it comes with glib2. But today glib2 is a dependency of vte, polkit, pipewire, ffmpeg, the entire gtk ecosystem,... you get the point. So you can basically depend on it being there on most linux installs, especially desktop. Checkout the man page: https://www.mankier.com/1/gio https://www.mankier.com/1/gio highlights: - showing progress in `cp` equivalent - Easy cli interface to freedesktop trash (!) - tree command - filesystem changes monitor (inotify wrapper)
- INTPenis 2y ago
  I had no idea gio could do all those things. I've been using it to mount my smartphone from the CLI.
- compressedgas 2y ago
  All of what is in the gio command used to be the gvfs-* command set.
voidUpdate 2y ago
I know its only for personal use, but I've never had any problems with ls not being "high-performance" enough...
- deleted 2y ago
  [deleted]
darkfrancisco 2y ago
You can guess it is written in Rust before even checking the repo whenever you see that somebody made a clone of some popular systems tool like top, ls, cd, etc.
- deleted 2y ago
  [deleted]
- imp0cat 2y ago
  I know, right?! It's a common theme. But recently, there were two submissions here that actually turn the "rewrite in Rust" meme into something substantial. The two factions of C++ https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489 On "Safe" C++ https://news.ycombinator.com/item?id=42186475 https://news.ycombinator.com/item?id=42186475 Be warned that the second one is a really long read!
- Koshkin 2y ago
  I, for one, have been wishing for a high-performance, extensible alternative to emacs for a long time.
thebeardisred 2y ago
Thank you for being one of the few projects replacing a POSIX tool which properly sets the expectation that it's for personal use. It causes me no end of consternation that I see many tools introduced which provide only the barest minimum of functionality and skip over extended attributes, ACLs, and fail to keep compatibility with flags, or don't properly separate STDOUT & STDERR. While these may be sufficient for a naive developer, this oversight then breaks many downstream tools. Again though, thanks for sharing. Bringing your own spin and ideas into the world can be anxiety inducing and I'm pleased you went about this in a helpful and measured way!
- concerndc1tizen 2y ago
  Would you mind listing more common mistakes made by CLI developers?
  - telgareith 2y ago
    These days: not building this such that they can be easily spit out as json and/or xml markup.
  - two_handfuls 2y ago
    Not obeying the --help flag.
  - fragmede 2y ago
    not behaving the same as robust cli tools. -h and --help and -v and --verbose and --version
  - ksenzee 2y ago
    Julia Evans had an interesting thread recently on “social rules” of the terminal: https://social.jvns.ca/@b0rk/113540676612640547 https://social.jvns.ca/@b0rk/113540676612640547
  - sphars 2y ago
    This is a good, open-source resource for guidelines on creating CLIs, which goes over some common mistakes. https://clig.dev/ https://clig.dev/

197 points by triyanox 2y ago

Does UNIX philosophy holds anymore? Most of the modern CLI tools I've seen here try to be all at once: file manager, git client, grep. I wonder if it was always like this or we're getting further and further from the idea of keeping programs simple and open.

Cthulhu_ 2y ago
I would say it does; those tools rarely reimplement the functions you mention, but are abstractions on top of existing CLIs or libraries that do follow the UNIX philosophy. This project in particular is not being sold as a drop-in replacement for ls.
deleted 2y ago
[deleted]

dhruvkb 2y ago

While you've specifically labeled this as "personal use", it is a commendable project that introduces some interesting new ideas. I might steal some ideas from it for my own `ls` alternative, `pls`[1]. [1]: https://pls.cli.rs https://pls.cli.rs

Cthulhu_ 2y ago
"pls" as in "please give me a list of files"? Does `sudo pls` negate the "please"? :p

Koshkin 2y ago

I didn't know that ls was missing plugins.

hobs 2y ago

This github page doesn't say anything about why it turned out to be amazing, seems like a fun side project.

fellowniusmonk 2y ago
Yeah, why use this instead of ls? What makes it worthwhile as a daily driver?
netsharc 2y ago
Yeah, talk about hiding the headline... I see a screenshot that looks like the output of ls, ok it has colors, and some filenames have "!!" behind it. Great success?
- triyanox 2y ago
  Haha! Aren't all rust rewrites about colors take `bat` for example! Btw "!!" are from the git plugin, a quick way to see my workspace git status

tambourine_man 2y ago

brew support?

triyanox 2y ago
Great idea! I will be working on it!

dbacar 2y ago

Categorization and hashes seem to be good ideas, yet you could do all of these with other tools already. You could be knowing the tool 'exa', a similar ls alternative. Just wanted to mention.

elashri 2y ago

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.

imoverclocked 2y ago

Did anyone here use Genera on an original lisp machine? It had a pseudo-graphical interface and a directory listing provided clickable results. It would be really neat if we could use escaping to confer more information to the terminal about what a particular piece of text means. Feature-request: bring back clickable ls results! Bonus points for defining a new term type and standard for this.

dotancohen 2y ago
> Feature-request: bring back clickable ls results! Doesn't your desktop (or distro) have a graphical file manager? On KDE it's Dolphin, which ex-Windows users absolutely love. I don't know what it would be on Gnome or other desktops.
- shakna 2y ago
  My ssh client also supports mouse events, though.
- mabster 2y ago
  I'm not going to speak for Linux, but on Mac the Finder is annoying enough that I ended up using CLI for file manipulation (ranger).
yjftsjthsd-h 2y ago
It's not really that, but have you tried ranger?
rphln 2y ago
There's already `ls --hyperlink` for clickable results, but that depends on your terminal supporting the URL escape sequence.
- westurner 2y ago
  $ man ls | grep '\--hyperlink' -A 1 --hyperlink[=WHEN] hyperlink file names WHEN
- 2y ago

bornfreddy 2y ago

I use git command line interface. Not because it is good (it isn't) or because I enjoy suffering (I think I don't), but because it is a standard on all the machines that have, you know, git. What good is a ls alternative if I need to install it everywhere I need ls? I'd prefer using the standard ls even if it is not ideal. But maybe that's just me.

matheusmoreira 2y ago
Ubiquitousness is certainly a major selling point. The GNU coreutils are everywhere. I've made my peace with bash and make because I know they're always gonna be there. This doesn't mean there's no value in developing one's own tools. Contributing to other projects can be quite difficult and time consuning. GNU projects are even more so. We shouldn't limit ourselves to POSIX stuff either. Better software and tools can and should be built. Every attempt is valuable. And who knows? It might just turn into a staple of Linux distributions some day.
SoftTalker 2y ago
Even ls isn't standard on all machines. GNU ls is different from BSD ls.
mshockwave 2y ago
This is also one of the reasons I write C++ with vim without any auto-completion nor fancy plugins (I do use syntax highlighting though, but I think it comes by default with vim nowadays), as well as using GNU screen -- not every machines install tmux by default, surprisingly. In case I need to login into some random Linux box, I'm sure I'll be almost as productive as I am on my own machine.
- whartung 2y ago
  I did the same thing back in they day. I developed on SCO (and, later, Unixware) on a PC, all of the clients were running the gamut of Unix OSes: HPUX, DGUX, AIX, SunOS, you name it. Most of the time was spent on our box in the office, but I was constantly bouncing back and forth to client systems. Either on site, or over the modem. Having to juggle Termcaps and the whole thing. It was polyglot machine/OS world back then. Just had to learn to get the best out of a baseline set of Unix tools. vi instead of emacs, awk instead of perl. Master those and never be left wanting on a new environment, so I can hit the ground running. No need to "bootstrap" (if the client would even let you, not always). Couldn't even rely on a C compiler.

iwontberude 2y ago

The things I take for granted. This is a breath of fresh air! Way to rethink the fundamentals!

skrebbel 2y ago
I can't tell if you're being sarcastic or not.
- iwontberude 2y ago
  For the record I was not being sarcastic but maybe I was feeling a bit too romantic or overly supportive of OP
  - cb321 2y ago
    I notice prior HN comments of yours mention the physical design of the NeXT cube. I cannot say it will make you not hate software, but you still might appreciate that another alternative ls, https://github.com/c-blake/lc https://github.com/c-blake/lc, both re-thinks/breaks more radically with ls-tradition and adapts well to something very similar to a terminal variant of the https://en.wikipedia.org/wiki/Miller_columns https://en.wikipedia.org/wiki/Miller_columns used in the NeXT file tree graphical browser/navigator via simple shell process substitution composition. E.g., a 3-level scenario on an 80-column looks like: paste <(lc -1m25 ../..) <(lc -1m25 ..) <(lc -1m25 .) Some shell script that uses $((COLUMNS)) arithmetic to do 2 or 4 or whatever terminal width is a pretty simple exercise for the reader and one might want to pipe to less.

vunderba 2y ago

Sounds like a fun project. However, from the readme: Efficient file listing: Optimized for speed, even in large directories What exactly is it doing differently to optimize for speed? Isn't it just using the regular fs lib?

jeffbee 2y ago
On my system it uses twice as much CPU as plain old ls in a directory with just 13k files. To recursively list a directory with 500k leaf files, lla needs > 10x as much CPU. Apparently it is both slower and with higher complexity.
- matheusmoreira 2y ago
  What exactly makes ls faster?
- triyanox 2y ago
  On the latest release the it can list a tree of 100 in depth with over 100k files in less than 100ms and if cached 40ms
- inquisitive-me 2y ago
  But it’s written in rust so it’s super fast. Did you take that into account when running your benchmarks? /s
- triyanox 2y ago
  Will definitely prioritize optimization in the next releases. Planning to benchmark against ls on various systems and file counts to get this properly sorted.
- niek_pas 2y ago
  Not trying to “gotcha” you, but I would imagine that 10x the CPU of ls is still very little, or am I wrong?
  - jeffbee 2y ago

monroewalker 2y ago

Other than colorization, what are people getting out of ls replacements like this? I've recently started using ranger which might replace my ls usage for the most part since it not only shows everything in the directory but has vim like shortcuts for filtering, sorting, and searching the directory as well as previewing files and entering other directories

dhruvkb 2y ago
Hi, author of `pls`[1] here. `pls` goes above and beyond what is typically possible with `ls` without going so far as to become an entire TUI file explorer like Broot[2]. Among a few things it does that `ls` (and other alternatives like `eza` don't do) are: - icons (SVG icons in terminals that support it, Nerd Fonts otherwise) - advanced filtering using regex - advanced sorting across multiple sort bases - styles and colors using customisable rules For someone wanting to make the output of `ls` prettier (with a few extra bells and whistles) without having to relearn a new workflow, something like an `ls` replacement makes more sense. [1]: https://pls.cli.rs https://pls.cli.rs [2]: https://dystroy.org/broot/ https://dystroy.org/broot/
- pmarreck 2y ago
  pls looks useful and I will retain it but eza is giving more icons for more things via (this is my alias for `l`, basically) `eza --long --hyperlink --header --all --icons --git --sort name` also the hyperlink thing is useful
throwaway984393 2y ago
[dead]
Symbiote 2y ago
ls does colored output. I'm surprised it's not the default for you.
- cb321 2y ago
  If you run `dircolors --print-database|less` you will see that GNU ls only highlights/colors the path/filenames according to a simplistic scheme where a file can only resolve to one type even though on many terminals today "foreground overlays background overlays bold/italic/etc". (https://github.com/c-blake/lc#vector-typemulti-dimensionalityattribute-layers https://github.com/c-blake/lc#vector-typemulti-dimensionalit... has a more advanced idea.) This tool by triyanox -- just from the screen shot if you click through -- will also colorize permission masks and sizes, dates, user & group.

throwaway984393 2y ago

[dead]

zvr 2y ago

Creating command-line utilities is nice, but I personally lament the lack of man pages when people write something new.

triyanox 2y ago
That's the amazing part I'm talking about the learning experience you get from weeks of working on something like that is better than reading countless documentations
- zvr 2y ago
  Oh, of course the development is fun and exciting and a learning experience. But before inviting others to use something, please think of how to make its use more clear. After all, I assume you post this so that people use it, not only admire your coding skills. There is a group of people who have learned to read and rely on man pages. For example, the top-level README says: > -s, --sort <CRITERIA>: Sort by "name", "size", or "date" OK, does "date" refer to creation date, modification date, access date? I can understand "size", but does it produce smallest-first or largest-first? It might not matter if... ah, no, there is no -r/--reverse flag. Can I have more than one "criteria" (since the plural is used)? Getting answers for such questions now means I have to go read the code in src/args.rs and follow to the implementation of the various functions. And in a few days, when I have the same questions again and I have forgotten the options, I will again have to dive into the code. Please consider providing a short man page. It documents the "calling interface" to your program and makes it easier to use. I usually start writing one even before implementing the whole thing, to clearly articulate what I expect the program to do.
  - triyanox 2y ago
    Fair critique about the documentation - this needs proper attention. Writing a man page first is a solid approach - it forces clear thinking about the interface before implementation. I'll prioritize adding complete documentation for all options and the plugin system. The code works, but without good docs it's not truly useful.
- 2y ago

mellosouls 2y ago

I clicked on this (without noting "github") expecting an essay on the joys of building an alternative to ls. This is basically a Show HN without a summary I think. fwiw: https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html

eviks 2y ago

Excellent new idea re plugins, a lot of these tools are too inflexible !

cb321 2y ago
`lc` mentioned elsethread [1] was always extensible with plugins for formatting and file-typing (but also always supported libmagic-based file-typology). There are other fairly distinctive ideas in `lc`, actually.. the README has a list. While I like it and it's a good idea, I think the reality is that developers capable enough to write shared library/DLL plugins are more likely to just submit PRs and make such stuff built-in but maybe optional. [1] https://news.ycombinator.com/item?id=42229841 https://news.ycombinator.com/item?id=42229841
- eviks 2y ago
  "Always" is just 4 years? Lc is also one of these new tools > more likely to just submit PRs and make such stuff built-in but maybe optional. Which are more likely to just be rejected by the more conservative maintainers of the tool. That's the empowering beauty of plugins - no such barriers
  - cb321 2y ago
    Your tone is rather disputatious/critical, but we have literally no dispute here.

yasser_kaddoura 2y ago

I have these aliases for various purposes: # Different options to search for files # da=36 cyan timestamps alias ls="EZA_COLORS='da=36' eza --time-style=relative --color-scale=age" alias lsa="ls --almost-all" # ignore . .. alias l="ls --long --classify=always" # show file indicators alias la="l --almost-all" # Tree view alias ltreea="ls --tree" alias ltree="ltreea --level=2" # Sort by time or size alias lt="ls --long --sort=time" alias lta="lt --almost-all" # lsd is faster than eza alias lss="lsd --long --total-size --sort=size --reverse" alias lssa="lss --almost-all" lla seems to go beyond what ls should do for some reason. Why show git and code complexity info? Just use tools dedicated for these things, otherwise, it will be an unmaintainable mess. If you can solve a problem easily with external tools, then there's no reason to add a feature for it.

tejohnso 2y ago
That's a great list. I have a similar list and the aliases grow out of frequently used arguments. For example, I found myself often doing an ls -Altch and so lsth was born. I find that aliases that or born of frequently used arguments are easily remembered. Over time that one grew to include a pipe to head because most of the time I just want to see the top 20 or so most recently modified files in the directory.
deleted 2y ago
[deleted]

p2detar 2y ago

Coloring files of the same file-type is my favorite feature. Is the extension used to group them or a MIME-header parser? I guess the extension, since it is faster.

Symbiote 2y ago
This is also part of GNU ls, at least. man dir_colors I think.
- johnisgood 2y ago
  You are right.

triyanox 2y ago

Thanks for all the feedback! Let me clarify a few things about lla. The most amazing part of this project wasn't just building another ls alternative - it was the incredible learning journey. Building a systems tool in Rust while implementing a plugin architecture taught me more in a few weeks than months of reading could have. Yes, it does more than traditional ls, and that's intentional. The plugin system came from scratching my own itch of constantly switching between different terminal tools. Each feature added was a chance to dive deeper into systems programming and Unix internals. The performance still needs work, and the documentation could be better. But that's the beauty of open source - you ship it, learn from the feedback, and keep improving. Building in public is an incredible way to level up your skills. For anyone considering a similar project: pick a common tool you use daily and try reimagining it. You'll be surprised how much you learn along the way.

porridgeraisin 2y ago

One slept on filesystem cli tool on linux is `gio`. So it comes with glib2. But today glib2 is a dependency of vte, polkit, pipewire, ffmpeg, the entire gtk ecosystem,... you get the point. So you can basically depend on it being there on most linux installs, especially desktop. Checkout the man page: https://www.mankier.com/1/gio https://www.mankier.com/1/gio highlights: - showing progress in `cp` equivalent - Easy cli interface to freedesktop trash (!) - tree command - filesystem changes monitor (inotify wrapper)

INTPenis 2y ago
I had no idea gio could do all those things. I've been using it to mount my smartphone from the CLI.
compressedgas 2y ago
All of what is in the gio command used to be the gvfs-* command set.

voidUpdate 2y ago

I know its only for personal use, but I've never had any problems with ls not being "high-performance" enough...

deleted 2y ago
[deleted]

darkfrancisco 2y ago

You can guess it is written in Rust before even checking the repo whenever you see that somebody made a clone of some popular systems tool like top, ls, cd, etc.

deleted 2y ago
[deleted]
imp0cat 2y ago
I know, right?! It's a common theme. But recently, there were two submissions here that actually turn the "rewrite in Rust" meme into something substantial. The two factions of C++ https://news.ycombinator.com/item?id=42231489 https://news.ycombinator.com/item?id=42231489 On "Safe" C++ https://news.ycombinator.com/item?id=42186475 https://news.ycombinator.com/item?id=42186475 Be warned that the second one is a really long read!
Koshkin 2y ago
I, for one, have been wishing for a high-performance, extensible alternative to emacs for a long time.

thebeardisred 2y ago

Thank you for being one of the few projects replacing a POSIX tool which properly sets the expectation that it's for personal use. It causes me no end of consternation that I see many tools introduced which provide only the barest minimum of functionality and skip over extended attributes, ACLs, and fail to keep compatibility with flags, or don't properly separate STDOUT & STDERR. While these may be sufficient for a naive developer, this oversight then breaks many downstream tools. Again though, thanks for sharing. Bringing your own spin and ideas into the world can be anxiety inducing and I'm pleased you went about this in a helpful and measured way!

concerndc1tizen 2y ago
Would you mind listing more common mistakes made by CLI developers?
- telgareith 2y ago
  These days: not building this such that they can be easily spit out as json and/or xml markup.
- two_handfuls 2y ago
  Not obeying the --help flag.
- fragmede 2y ago
  not behaving the same as robust cli tools. -h and --help and -v and --verbose and --version
- ksenzee 2y ago
  Julia Evans had an interesting thread recently on “social rules” of the terminal: https://social.jvns.ca/@b0rk/113540676612640547 https://social.jvns.ca/@b0rk/113540676612640547
- sphars 2y ago
  This is a good, open-source resource for guidelines on creating CLIs, which goes over some common mistakes. https://clig.dev/ https://clig.dev/