Hacker News Reader

Comment by enricozb | Hacker News Reader

I wish fd and rg would align some of their flags. For example, both fd and rg have a --type, but for fd it means file/directory/symlink etc. For rg it means the file MIME type. Another example is that fd has an --extension flag, and rg doesn't.

Since I believe the correlation of usage of these tools is high, I think they could benefit from having similarly named flags.

View on HN

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.

It's actually because they stayed compatible that the problem arises: fd and find -type mean the same but this user wants them to be different.

Overall, I use AI shell completion so it's much smoother.

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?

Ah I do it from the other side

Got it from here

https://x.com/arjie/status/1575201117595926530?s=46

Interesting. Thanks for sharing.

That gives me some ideas to try myself.

Good luck. Do share if any are sticky!

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`.

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’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.

I maintain a pair of tools that can do in-place file replacements on ripgrep output (https://github.com/robenkleene/rep-grep) and rename files based on `fd` output (https://github.com/robenkleene/ren-find).

> If ripgrep never performs writes, there's never a chance of a mistake in usage or bug in the software clobbering files in bulk.

Yeah that's exactly why it doesn't.

It is true that the `-r/--replace` flag can replace a number of `sed` and `awk` use cases. It has for me at least.

> 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.

Not disappointing. Just pragmatic.

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. :-)

If you’re willing to commit time to learning my shell then I’m willing to commit time to learning ripgrep. ;-)

https://murex.rocks

Edit:

> 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`.

But I gave it ten minutes and ported part of https://github.com/BurntSushi/dotfiles/blob/bedf3598f2501ad5... to https://github.com/BurntSushi/dotfiles/blob/bedf3598f2501ad5...

Not much, but it took me some time to get the basics down.

One thing that stood out to me was that startup times are kinda brutal. I'm not sure if that's intended or if it's something about my environment:

    $ cat /tmp/murex-test
    #!/usr/bin/murex

    echo $ARGV
    $ time /tmp/murex-test
    [
        "/usr/bin/murex",
        "/tmp/murex-test"
    ]

    real    0.437
    user    0.491
    sys     0.110
    maxmem  106 MB
    faults  0

    $ murex --version
    murex v6.4.2063 (develop)
    GPL v2
    2018-2025 Laurence Morgan

That would probably be a deal breaker for me.

I got murex through the AUR: https://aur.archlinux.org/packages/murex

> Oh absolutely I’m open to learning new things.

Okay then I'd say this is high contrast with your comments above!

Yeah I’ve not spent time optimising start up because it’s main emphasis is the interactive shell.

I guess you could liken it to Powershell or JVM in that the start up is generally a one time cost if you’re using it interactively.

I could certainly invest a little time on the start up though. It wouldn’t be impossible to improve things there.

> Okay then I'd say this is high contrast with your comments above!

Is it though? I didn’t say I’m adverse to learning new things. Just that I don’t want to learn replacements for the tools I’ve already memorised.

But anyway, you’ve downloaded murex so I’ll give ripgrep go. I’m sure it’ll become a staple tool for me now I’ve committed time to it :)

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.

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’m old and lazy too, which is why I use eza, bat and other new tools that were created this century.

Why are we acting like we’re still in the 80’s and can only use tools that existed then?

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.

[1]: https://github.com/chmln/sd

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.

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.)

Yeah this annoys me even though I'm a daily user of both fd and rg. What makes it more confusing is that many of the flags DO align - or partially align.

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.

It's a tricky balance. To use your --type example, it isn't consistent with rg, but it is mostly consistent with find. And fd'a --type option is much more useful for fd than an equivalent would be for rg. It doesn't make a lot of sense to filter the files to grep to directories, or sockets, but that is useful if you are searching for file names, or even just all files of a certain type. Conversely, rg's --type option isn't quite as useful for fd, because fd is already matching a pattern against the file name, so you can easily just add the appropriate extension to your search pattern. Or use the --exyension flag.

I used sql instead of flags to make it easier to remember - see https://github.com/laktak/zfind

Reply on news.ycombinator.com