4 ms·

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 usefu

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/grep.html 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.

ziml77 2y ago
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?
- burntsushi 2y ago
  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.
  - ziml77 2y ago
    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.
    - robenkleene 2y ago
      I maintain a pair of tools that can do in-place file replacements on ripgrep output (https://github.com/robenkleene/rep-grep https://github.com/robenkleene/rep-grep) and rename files based on `fd` output (https://github.com/robenkleene/ren-find https://github.com/robenkleene/ren-find).
    - burntsushi 2y ago
      > 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.
hnlmorg 2y ago
> 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.
- burntsushi 2y ago
  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.
  - hnlmorg 2y ago
    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.
thiht 2y ago
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 https://github.com/chmln/sd

ziml77 2y ago

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?

burntsushi 2y ago
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.
- ziml77 2y ago
  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.
  - robenkleene 2y ago
    I maintain a pair of tools that can do in-place file replacements on ripgrep output (https://github.com/robenkleene/rep-grep https://github.com/robenkleene/rep-grep) and rename files based on `fd` output (https://github.com/robenkleene/ren-find https://github.com/robenkleene/ren-find).
  - burntsushi 2y ago
    > 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.

hnlmorg 2y ago

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

burntsushi 2y ago
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.
- hnlmorg 2y ago
  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.

thiht 2y ago

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 https://github.com/chmln/sd