regexp-cut VS modern-unix

I use a lot of CLI tools, but haven't written many for myself. Mostly, aliases/functions and some scripts in Bash/Python.

Extract details for command options from man/help: https://github.com/learnbyexample/command_help/blob/master/c...

cut-like syntax for field manipulations with regexp, negative indexing, etc: https://github.com/learnbyexample/regexp-cut/blob/main/rcut

simple calculator using python syntax: https://learnbyexample.github.io/practice_python_projects/ca...

rcut - my own bash+awk script, supports regexp delimiters, field reordering, negative indexing, etc

Nice, especially the format output.

See also:

* hck (https://github.com/sstadick/hck) - close to drop in replacement for cut that can use a regex delimiter instead of a fixed string

* rcut (https://github.com/learnbyexample/regexp-cut) - my own bash+awk script, supports regexp delimiters, field reordering, negative indexing, etc

I saw about `hck` recently on twitter, was impressed to see support for compressed files. From the current todo list, I hope complement is implemented for sure.

I see Negative index is currently "unlikely". I'm writing a similar tool [0], but with bash+awk. I solved the negative index support with a `-n` option, which changes the range syntax to `:` instead of `-` character.

My biggest trouble came with literal field separator [1], because FS can only be specified as a string in awk and backslash is a metacharacter for both string and regexp.

[0] https://github.com/learnbyexample/regexp-cut

[1] https://learnbyexample.github.io/escaping-madness-awk-litera...

* Could computer architectures change significantly in the future, perhaps with ASI designing hardware and software, RAM as fast as CPUs, or photonic chips?

Modern alternatives to traditional Unix tools, most of which are written in Rust, have become very popular in the past several years, here's a whole list of them: [https://github.com/ibraheemdev/modern-unix](https://github.com/ibraheemdev/modern-unix). They sort of get to learn the lessons from software history, and implement more features and some have differences in usability. Its hard to predict the future but could the cycle repeat? What are the odds of someone writing a successor to ripgrep that is as (subjectively) better than ripgrep, as ripgrep is to grep, if not more? (and the possibility of it being written in a systems language designed to succeed languages like Rust, like how Rust is used as an alternative to C, C++, etc.). Or, we have gotten all the features, performance, and ease of use as we can for a CLI that searches text in files? It seems like we don't have more ideas for how to improve that, at least with the way computers are now.

Are CLIs like Ripgrep better than grep on 70s Unix machines without much rewriting (if they can be compiled for them), or would they require lots of rewriting to run, perhaps to account for their computer architectures or very low hardware specs? Could computer architectures change much in the next 10-30 years such that Ripgrep would need rewriting to work well on them, and or a successor to Ripgrep wouldn't be out of the question? By architectures I don't mean necessarily CPU architectures, but all the hardware present inside the computers, and the relative performance of CPU RAM Storage etc. to each other. If it would take too much effort, what if someone time traveled to the 70s with a computer with ripgrep and its source code? Could Unix engineers apply any ideas from it into their Unix utils? How much of the improvements in newer tools are simply the results of better ideas for how they should work? Unix engineers did their best to make those tools but would the tools be much better if they had the ideas of these newer tools?

Also, I wonder if these newer tools would last longer because computers are accessible to the average person today unlike in the 70s, and the internet allows for many programmers with great ideas to collaborate, and easily distribute software. Correct me if I'm wrong but in the 20th century different unixy OSes have their own implementations of Unix tools like grep find etc. While that still applies to some degree, but now we have very popular successors to Unix tools on Github, If you ask online about alternatives to ones like grep and find, a lot of users will say to use ripgrep and fd, and may even post that link I mentioned above. If you want to make your own Unix OS today, you don't need to make your own implementations of these tools, at least from scratch. I only skimmed the top part but this might be worth looking at: [https://en.wikipedia.org/wiki/Unix\_wars](https://en.wikipedia.org/wiki/Unix_wars).

- Learning "modern" tools like ripgrep and fzf (There's a list here: https://github.com/ibraheemdev/modern-unix)

Nedavno mi je dobro dosla ova kolekcija toolova za unix https://github.com/ibraheemdev/modern-unix

A lot of the tools in the post build on top of standard unix tools and are like for like (better) replacements. Many of them have been pulled from the Modern Unix repo on Github.

Plug to modern unix, a collection of utilities that modernize "standard" nix utilities (combination of faster, prettier, easier to use, as well as sensible defaults like highlighting and line numbers when not piped).

I google something like "Modern Unix", open blogs, and try to find a "life-changing" tool that I haven't tried yet. Then I spend 1 day reading man how to apply this unreal tool to my current work environment setup. Ultimately, I'm sad because I wasted 1 day, but the process is fun enough to do it again tomorrow. This is like distro-hopping but tool-hopping. Now I have fzf, bat, helix, zoxide etc, but that's just the beginning of my tool-hopping :)

While this is not at all comprehensive of all the cool tools out there, there's this list which has a lot of modern alternatives to all of the modern Unix commands we know and love, most of which are written in Rust.

You might want to take some inspiration from https://github.com/ibraheemdev/modern-unix too! Neat website

Yeah, fine, since Go and Rust it is common to have this "one file app" that you put in $PATH and call it a day. Now, how many of those are not a single CLI utility (e.g. a replacement for top/ls/du or other UNIX utility), and are full blown GUI app? Not so many. None that I can think of from the top of my head, actually.