[HN Gopher] I made an ls alternative for my personal use
___________________________________________________________________
I made an ls alternative for my personal use
Author : triyanox
Score : 67 points
Date : 2024-11-24 17:23 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hobs wrote:
| This github page doesn't say anything about why it turned out to
| be amazing, seems like a fun side project.
| fellowniusmonk wrote:
| Yeah, why use this instead of ls? What makes it worthwhile as a
| daily driver?
| netsharc wrote:
| 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 wrote:
| 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 wrote:
| brew support?
| triyanox wrote:
| Great idea! I will be working on it!
| dbacar wrote:
| 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 wrote:
| 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)
|
| 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.
| iroddis wrote:
| 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 wrote:
| 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 wrote:
| > _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
| L3viathan wrote:
| 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 wrote:
| vanilla ls has never been particularly chainable -
| https://mywiki.wooledge.org/ParsingLs
| machinestops wrote:
| 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
| CJefferson wrote:
| 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.
| threePointFive wrote:
| > Newlines are now forbidden in filenames
|
| No. To quote that article
|
| > A bunch of C functions are now encouraged to report
| EILSEQ if the last component of a pathname to a file they
| are to create contains a newline
|
| This, yes, makes newlines in filenames effectively
| illegal on operating systems strictly conforming to the
| new POSIX standard. However, older systems will not be
| enforcing this and any operating system which exposes a
| syscall interface that does not require libc (such as
| Linux) is also not required to emit any errors. The only
| time even in the future that you should NOT worry about
| handling the newline case is on filesystems where it's is
| expressly forbidden, such as NTFS.
| eviks wrote:
| 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 wrote:
| 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.
| amelius wrote:
| 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 wrote:
| Look into far2l
| from-nibly wrote:
| If you like that philosophy check out nushell. They go pretty
| hard core on that and they can because of structured output
| vunderba wrote:
| Eza is great. I was pleasantly surprised at how nice the mime
| type icons meshed with the terminal.
| treve wrote:
| 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 wrote:
| lc: https://github.com/c-blake/lc (in Nim).
| medv wrote:
| Also "walk" is great for interactive navigation.
|
| - https://github.com/antonmedv/walk
| bawolff wrote:
| 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.
| roywashere wrote:
| Well, recursive display is nice, I guess, as well as
| searching on partial filenames
| mbivert wrote:
| Has been roughly doing the job since the 70s (?):
| $ du -a | grep blbl
| benrutter wrote:
| 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 wrote:
| 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
| abnry wrote:
| > I barely ever even use the -la options.
|
| Certainly I use these less than plain "ls," but digging
| through hidden files and folders and looking at timestamps is
| very important for me.
| bastardoperator wrote:
| I also used eza to replace the tree command with the --tree
| flag.
| triyanox wrote:
| 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!
| imoverclocked wrote:
| 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 wrote:
| > 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.
| yjftsjthsd-h wrote:
| It's not really that, but have you tried ranger?
| rphln wrote:
| There's already `ls --hyperlink` for clickable results, but
| that depends on your terminal supporting the URL escape
| sequence.
| westurner wrote:
| $ man ls | grep '\--hyperlink' -A 1 --hyperlink[=WHEN]
| hyperlink file names WHEN
| db48x wrote:
| This is nice, but a poor substitute for what Genera was
| doing.
|
| You see, Genera knows the actual type of everything that is
| clickable. When a program needs an input, objects of the
| wrong type _lose their interactivity_ for the duration. So if
| you list the files in some directory, the names of those
| files are indeed links that you can click on. Clicking on one
| would bring up a context menu of relevant actions (view,
| edit, print, delete, etc). If a program asks for a filename
| as input then clicking on a file instead supplies the file
| object to the program. Clicking on objects of other types
| does nothing.
| Rendello wrote:
| That's one aspect I prefer in playing with TempleOS over
| Linux. The rest of the command line is a bit of a pain,
| with no history, C-as-a-shell, etc.
| mbivert wrote:
| Maybe some aspects of the Plan9 UI? (rio/9term, plumber; acme
| as well).
|
| You should be able to get this to work on Unix with plan9port.
| bornfreddy wrote:
| 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.
| SoftTalker wrote:
| Even _ls_ isn 't standard on all machines. GNU _ls_ is
| different from BSD _ls_.
| mshockwave wrote:
| 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.
| easton wrote:
| 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)
| bee_rider wrote:
| 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...
| deredede wrote:
| 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).
| eviks wrote:
| 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
| iwontberude wrote:
| The things I take for granted. This is a breath of fresh air! Way
| to rethink the fundamentals!
| skrebbel wrote:
| I can't tell if you're being sarcastic or not.
| vunderba wrote:
| 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 wrote:
| 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.
| inquisitive-me wrote:
| But it's written in rust so it's super fast. Did you take
| that into account when running your benchmarks? /s
| monroewalker wrote:
| 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
| zvr wrote:
| Creating command-line utilities is nice, but I personally lament
| the lack of man pages when people write something new.
| triyanox wrote:
| 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
| mellosouls wrote:
| 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
| eviks wrote:
| Excellent new idea re plugins, a lot of these tools are too
| inflexible !
| cb321 wrote:
| `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
| yasser_kaddoura wrote:
| 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.
| p2detar wrote:
| 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.
| triyanox wrote:
| 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 wrote:
| 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
|
| highlights:
|
| - showing progress in `cp` equivalent
|
| - Easy cli interface to freedesktop trash (!)
|
| - tree command
|
| - filesystem changes monitor (inotify wrapper)
___________________________________________________________________
(page generated 2024-11-24 23:01 UTC)