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.
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.
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
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
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.
> 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.
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.
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.
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.
What's the point of suffering everywhere if you don't enjoy it? It's not like using a better alternative prevents you from knowing how to use ls, but only in those cases where there is no better alternative
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.
I assume this is tongue-in-cheek, but I don't think the comparison works at all.
I spend maybe 1% of my working hours (being generous) using `ls` and something like 50% (likely more) using my editor.
If there is some alternative to `ls` that makes my `ls` workflows 2x faster, my productivity increases by 0.5%. If I use a sub-optimal editor that makes my workflow 2x slower, I lose 25% of my productivity.
When I need to login to a remote box, I am also very likely to need to use `ls` since I am less familiar than on my own machine, whereas I am unlikely to do any sort of heavy development work (typically I just need to edit a couple configuration files, or do some git operations).
I’ve been on machines in the last few years that didn’t have screen either. Maybe it was a minimal install or something, but I specifically remember having to install it to get some long running stuff going.
(Thinking it was Ubuntu server, but guessing someone will correct me)
Tmux vs screen is an odd one; it kinda feels like screen was included in the era when people were actually trying to make the default install on servers kind of nice to use with a functional set of assumed programs. And now, it is fairly widespread just due to legacy.
Nowadays, and possibly for the better (every line of code is a potential bug and every bug is a potential vulnerability) it seems like systems don’t want to include this sort of stuff. So, I’m sure if the decision were made today, tmux or screen, tmux would win. Unfortunately, “none” seems like the real future option…
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)
lsd: (https://github.com/Peltoche/lsd)
colorls: (https://github.com/athityakumar/colorls)
g: (https://github.com/Equationzhao/g)
ls++: (https://github.com/trapd00r/LS_COLORS)
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.
reply