To be honest, this is one of the reasons I usually stick with POSIX tools, I’m too old and too lazy to want to learn a whole new set of flags for a whole new set of tools that are very close to but not quite the same as what’s already part of my muscle memory now.
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.
As the author of ripgrep, I find this unconvincing personally. Have you ever tried to use `sed` with its `-i` flag?
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`.
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.
> As the author of ripgrep, I find this unconvincing personally. Have you ever tried to use `sed` with its `-i` flag?
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.
I mean that seems pretty reasonable? I find your philosophy a little disappointing, but you do you. But it is reasonable. I think you ignored this part of my comment:
> To be clear, I mean this somewhat narrowly. Namely
>
>> I’m too old and too lazy
>
> I totally get that.
Yeah, I think your explanation is pretty reasonable. I am also old and lazy and still find time to try new tools.
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?
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.
Oh, no, definitely disappointing! At least to me it is. I totally believe in learning new things for the sake of it, because it sometimes leads to serendipitously good things. Otherwise it's really easy to end up in local optima. Without that philosophy, I would have never built ripgrep.
I'm not trying to convince you to do that. I already told you that your philosophy is reasonable. But I absolutely find it disappointing.
Anyway, yes, I have a kid. And all sorts of other things competing for my time. So I don't get much time to do serendipitous learning. But I try when I can. I cited two examples, but that's over a period of many years. I don't have time to do it often.
> you’d see we are pretty like minded with regards to modernising the command line
I bet we are. Maybe you are a lot more open to learning new things than you are letting on in your comments here. :-)
> I bet we are. Maybe you are a lot more open to learning new things than you are letting on in your comments here.
Oh absolutely I’m open to learning new things.
Just recently I’ve been learning about tmux control mode (eg what iTerm2 uses for tmux integration) because I wanted to bypass tmux terminal emulation for specific escape codes, meaning I can then draw native elements inside a terminal window, such as spreadsheets, images, and code folding, while still having full tmux capabilities.
That was a “fun” ride. I plan on writing a blog about it at some point because there’s some features about tmux that I think others would be surprised to learn.
Oh man that's nowhere near fair! ripgrep is one tiny little command that is mostly compatible with GNU grep. Lots of the flags are the same. And its default usage is really easy: `rg whatever`.
Yeah I started with the shell script route because it felt like the best way to get familiar with it quickly. Then I'd probably go backwards to interactive usage.
The error messages did look very nice.
I have been considering dipping my toes into a less standard shell over the past few years. It is so so so hard to break away from the ubiquitous bullshit that most of us are stuck with. I have no love for the Bourne shell and its derivatives, although zsh is some nice lipstick on a very ugly pig.
The other candidates I'm aware of are fish, nushell and oils. I think nushell is the "most" different, but the last time I tried it, I bounced off of it for reasons I can't remember.
Yeah, switching shell is a major time investment. I couldn’t blame you for sticking with the default, after all, I was initially unwilling to invest time into learning ripgrep :D
And you’re right that it wasn’t a fair a trade asking you to look at Murex in exchange for ripgrep (which is nice by the way!) but I respect that you did take a look nonetheless.
I’m happy you gave ripgrep an option to perform replacements so I don’t have to worry about sed and its lack of a standard way to change files in-place. I realize on my Mac I could install GNU sed, but if I’m going to install an extra utility anyway, why not go with something that is overall nicer?
Hah, well, hate to break it to you, but ripgrep never writes files, only reads them. So its `-r/--replace` option only controls ripgrep's output, but doesn't actually replace data inside a file.
I could swear I used it to do just that a handful of times in the past. But my brain's been a bit scrambled recently so I'm probably misremembering now. I know for sure I made use of the replace option and was happy it was there and that using it felt better than using sed.
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.
sed has to be one of the worst POSIX tools. It sounds simple enough, but everytime I reach for sed it doesn't do what I want, either because it doesn't align with how I do things, or because it just doesn't support doing it (especially multiline replacements for example).
I've switched to sd[1] because it basically just works as I expect every time.
ripgrep solves a really annoying part of the unix toolbox: inconsistency in how to correctly search a bunch of files for a string. Are you supposed to `find -name -exec`? Or are you supposed to `find -name | xargs -n 1`? Oh, but files can have spaces, so you might try `find -name -print0 | xargs`, but careful—`-print0` is not POSIX and you won't find it on some unixen! (let's not even discuss locate vs slocate vs mlocate.... ugh! Files are worse than everything but all the other options.)
this is what tab completion and tldr is for. 99% of use cases are well covered and clear by the name of the flag, and a good CLI tool will make that easy to understand. A quick example and self-explanatory flags with tab-completion is all you need. Then if you ever have a more complicated use case, you can grep through the man page.
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.
I’ve been thinking of adding AI completion into my CLI tools but not really sure how to implement it in a non-intrusive way. So I’ve got a few questions, if you don’t mind sharing:
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?
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.