Not taking anything away from the tools that have been written. Just for me, the pain of learning a new tool is greater than the convenience I’d gain from using it.
That's because `-i`, while incredibly useful, is not POSIX. So when you say "POSIX tools," what you actually probably mean is, "superset of POSIX tools."
There is some agreement among the same tools as what the options in the superset actually mean, but not always, as is the case with `sed`.
Compare, for example, what `man grep` says on your system with the POSIX definition: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g...
As for whether flags are consistent across different tools, well that's a total crapshoot. `find` uses `-L` for following symlinks while `grep` uses `-R`. Ironically, both `fd` and ripgrep use `-L`, so they are more consistent than the relevant superset-plus-POSIX tooling on at least that front.
To be clear, I mean this somewhat narrowly. Namely
> I’m too old and too lazy
I totally get that. I have a bunch of things I kinda want to learn and do, but just not enough time in the day. But I do still try to make time for these things. I did it for `tmux` (previously, `screen`) and `zsh` (previously, `bash`) and I am very happy I did. Each one cost me about a Sunday and a half, but they've been paying rewards ever since.
I have. But that’s one inconsistency and an edge case I rarely need to worry about.
Plus we are talking about grep here, not sed. I created my own “sed” because I got fed up with dealing different implementations of existing seds. If others use it or don’t use it then that’s their choice, not mine.
> As for whether flags are consistent across different tools, well that's a total crapshoot. `find` uses `-L` for following symlinks while `grep` uses `-R`. Ironically, both `fd` and ripgrep use `-L`, so they are more consistent than the relevant superset-plus-POSIX tooling on at least that front.
UNIX tools are a mess too. My point wasn’t that their flags are more sane than modern tools. It’s that I’ve already committed to memory the flags for the tools I use daily.
> Each one cost me about a Sunday and a half, but they've been paying rewards ever since
I spend my free time writing open source tools that solve problems I run into (like fixing the limitations with existing UNIX shells, and presently writing a new terminal emulator with a ton of features existing ones neglect). So I don’t have time to learn new tools to solve problems I don’t have.
Edit:
I just want add to my previous comment that some of my open source tools do make use of your fantastic Go libraries, such as the Unicode width library.
So I’ve really valued your contributions to open source even though I don’t personally use ripgrep specifically.
> To be clear, I mean this somewhat narrowly. Namely
>
>> I’m too old and too lazy
>
> I totally get that.I am not sure I have ever gotten traditional "find" to do what I want on the first try, and I've had a lot of first tries. At some point you have to ask yourself, if I haven't achieved zen in X years with Y tool, maybe the problem is the tool and not me?
Why are we acting like we’re still in the 80’s and can only use tools that existed then?
I have two young children plus maintain several open source projects (like yourself) and a full time job too.
Time isn’t infinite so I focus my energy on the stuff that makes the biggest impact.
It’s not like I’m ungrateful for your contributions to open source and if you’d look at some of the stuff I’ve been building you’d see we are pretty like minded with regards to modernising the command line.
I guess it does make sense now that I think about it that ripgrep wouldn't do in-place edits. If ripgrep never performs writes, there's never a chance of a mistake in usage or bug in the software clobbering files in bulk.
I've switched to sd[1] because it basically just works as I expect every time.
its legit as simple as "fd -e png -x optimize-png {}" the only thing I dont like about fd is that for some reason it kind of forces you to do 'fd . Downloads' if you just want everything in "Downloads" which equates to 'fd {pattern} Dir1 dir2" I wish you could omit the pattern sometimes.
Overall, I use AI shell completion so it's much smoother.
What’s the workflow like for AI shell completion?
How does it know which flag to complete for you? Do you write a description in native language (eg English) and it completes the entire command line? Or is it more one flag at a time?
Got it from here
That gives me some ideas to try myself.
For example, I'm used to glob patterns but the glob flag (-g) works differently in fd and rg. I think that fd's -g flag does not use "full-path" globbing while rg's -g does (or the other way around). To get fd to use rg style globs, it also needs the -p flag, which rg also recognizes but it has a completely different meaning for rg and has nothing to do with how globbing/filename matching works.
I guess I'm used to the warts at this stage, like I had gotten used to the warts on find and grep all those years ago.
Difficult or impossible to fix these inconsistencies at this stage without breaking backward compatibility.
Since I believe the correlation of usage of these tools is high, I think they could benefit from having similarly named flags.