Permanently Deleted
Yes. The only things I use regularly that arenโt aliased to or replaced by a rust-built tool are mkdir, ln, and rsync.
- cd: zoxide
- ls: eza
- cat: bat
- grep: ripgrep
- find: fd
- sed: sd
- du: dust
- top/htop: btm
- vi: helix
- tmux: zellij (or wezterm mux)
- diff: delta
- ps: procs
Probably some others Iโm forgetting
I have a strong bias for staying with tools that are installed by default. After this many years working with new systems of my own, containers, and systems where Iโm not root, the added value of an alternativehas to be quite high for me to switch a core utility.
Thay said, Iโve found fd, ripgrep, and helix to meet that criteria. The others, not so much; they either donโt improve upon or add functionality thatโs not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.
git-delta is an exception where the syntax highlighting can make a functional difference in code diffs. Not so much that I think about installing it, or using it outside of indirect VCS configuration, but it is a good example of using style for more than just eye candy. I prefer difftastic, but they do much the same.
While itโs not a replacement for an existing tool and isnโt in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.
they either donโt improve upon or add functionality thatโs not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.
The thing I like about a lot of these is that I donโt lose familiarity with existing tools. When I end up on a cluster that doesnโt have them, Iโm a bit annoyed, but I can still operate just fine.
The principle exception to this is actually fd - I now find find (har!) almost unusable without having a man page open in a separate terminal. But thatโs because fd is so much more ergonomic and powerful, I would never give it up unless forced.
I unfortunately do not have your crystaline perfect recall. I used vi/m for nearly 20 years before drifting onto kakoune and now helix; Iโve been using them for about a year, and itโs getting harder and harder to not make reflexive mistakes when Iโm trying to use vim. sed was already odd with regex escaping (parens but not brackets? Why??), and I know the less I use it the more Iโll forget. This is crippling when I have to work on a system that doesnโt have these new tools installed.
While itโs not a replacement for an existing tool and isnโt in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.
Can you give an example on the reorganization benefits with nnn? I am using it myself but I still feel like a noob with it.
So, I did a whole asciinema demonstration to show you, but it was getting tedious. It started to turn into a whole tutorial, and I really didnโt want to go there. Thatโs why itโs taken so long for me to reply.
But there are three things I do with nnn:
- move things. I use the tabs (1-4) to open different directories, space-select multiple items, and โvโ to move selected items to directories
- bulk rename. Again, space-select and ctrl-r to bulk rename. Often, I donโt even select, I just โRโ to bulk rename the whole directory. This opens my text editor with all of the file/Dir names; edit freely, save, exit, and nnn renames whatever changed.
- move/copy to remote locations. With โcโ nnn can mount a remote directory over ssh in a tab, and it works just like a local directory, with copying, moving, and renaming seamlessly between tabs.
I donโt โliveโ in nnn; itโs a tool I open when I want to do certain things - itโs fast enough to use this way. But you certainly could, since nnn can fork shell processes in selected directories.
If the current tools work fine, have decades of historic support and battle testing, and the alternatives offer little to no net benefit, uhh, why?
What for? Even if they have improvements in some areas, the original POSIX standard utilities will continue to be needed for script compatibility. Youโre not going to swap them out - at best you can add them and then you just have an additional code base to support with additional attack surface to protect.
No. Those tools are tried and well tested. Yes there may still be bugs lurking but simply rewriting in Rust does not guarantee safety. I do hope that this: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html doesnโt get used in that repo.
That said, Iโll take a look in say five years and see how they are getting on.
