Absolutely nothing… but for some reason I find it interesting when people rewrite things that I didn’t know needed rewrites. Sometimes these projects are doing someting really interesting. Grep is one such example, noone was saying that grep needed a replacement. In fact, it was used as a benchmark for regex (which is how rg started, to compare rust regex against grep), then someone creates rg that outperforms grep and is much nicer to use. That is also why I keep an eye on GitOxide, since nobody ever accused git of being slow, yet there are someone rewriting git with amazing performance improvements.
From your experience have you felt these people had researched their reasonings for the rewrites extensively prior. Or did they discover these improvements along the way sort of, simply an off shoot of simply being a hobby when wanting to build their tooling to define existing flows/actions
That varies quite a lot… but in general, the small tools seems to start as someone adding color and bling, possibly some nice things like automatic pager (like in bat). Still often nice additions though. For larger stuff like rg and gitoxide the authors seems to have done quite a lot of research and are really experts in their field. You don’t improve grep and git by accident.
GNU ls has those features too (except knowing about Git). I’d be surprised if BSD ls doesn’t at least have color support.
…not that I’m not going to check out eza and probably switch to it! But it’s often worth knowing what features the GNU/BSD coreutils do or do not support…especially when comparing other tools against them.
Edit: I just checked, and this set of options works on both BSD and GNU ls, in case anyone wants better ls behavior on a system where you can’t install eza for some reason:
ls -FH --color=auto
F appends sigils indicating executables, symlinks, or directories, and H follows any symlinks in the argument list.
What’s wrong with
ls?Absolutely nothing… but for some reason I find it interesting when people rewrite things that I didn’t know needed rewrites. Sometimes these projects are doing someting really interesting. Grep is one such example, noone was saying that grep needed a replacement. In fact, it was used as a benchmark for regex (which is how rg started, to compare rust regex against grep), then someone creates rg that outperforms grep and is much nicer to use. That is also why I keep an eye on GitOxide, since nobody ever accused git of being slow, yet there are someone rewriting git with amazing performance improvements.
From your experience have you felt these people had researched their reasonings for the rewrites extensively prior. Or did they discover these improvements along the way sort of, simply an off shoot of simply being a hobby when wanting to build their tooling to define existing flows/actions
That varies quite a lot… but in general, the small tools seems to start as someone adding color and bling, possibly some nice things like automatic pager (like in bat). Still often nice additions though. For larger stuff like rg and gitoxide the authors seems to have done quite a lot of research and are really experts in their field. You don’t improve grep and git by accident.
From eza’s readme, on why it’s better than ls:
GNU
lshas those features too (except knowing about Git). I’d be surprised if BSDlsdoesn’t at least have color support.…not that I’m not going to check out
ezaand probably switch to it! But it’s often worth knowing what features the GNU/BSD coreutils do or do not support…especially when comparing other tools against them.Edit: I just checked, and this set of options works on both BSD and GNU
ls, in case anyone wants betterlsbehavior on a system where you can’t installezafor some reason:ls -FH --color=autoFappends sigils indicating executables, symlinks, or directories, andHfollows any symlinks in the argument list.exa(which OP’s readme saysezais built on) supports creation times. Actual creation time (the “Birth” line instatoutput), notctime.It’s not cool. :)