Rep and Ren: A new approach to CLI find, replace, and renaming

This is clever. I wrote a "replace_all" bash function years ago that does the "run ripgrep and replace on the result files" and while it works well 99% of the time it is annoying when it screws up things due to partial matches. I solved this by basically forcing literal matches and word boundaries but it's limiting at that point.

The rep approach to use the actual ripgrep output seems very clever, tho I wonder how well it works in practice, but I'll be sure to give it a try.

Piece by piece, we reinvent Perl, then the new Perl turns into a monstrosity, we abandon it, and the cycle begins anew.

`rg | rep` still requires repeating the pattern. 99% of the time, all I need is a simple replacement on checked-in files[1] and for that I've had `git-gsr` in my PATH for a decade or more:

https://gist.github.com/jaysoffian/0eda35a6a41f500ba5c458f02...

Of course this also repeats the pattern, but that's an implementation detail I let the script handle for me. A future improvement to `rep` could be for it to invoke `rg` directly in order to avoid needing to repeat the pattern, though I suppose that could be a shell script easily enough.

[1]: How often are folks doing a global search and replace on a mass of files that isn't checked-in to a repo? I've been a sys admin and programmer for 25+ years and I think I can count on one hand the times I've ever needed to do that. If I had to do it today, I'd very likely create a temporary repo first in order to have a quick way to verify the diff and restore to previous state if need be.

This is...brilliant.

As a vim user, I have never really gotten into the quick fix list. I want to do my stuff in the command line.

But I find that a lot of new command line tools don't match my thinking, so I struggle to use them. (One example is fzf, which it seems people love.)

I do love ripgrep, though. I also love tools where I can see what action it performs before actually doing it. I use `-n` on ZFS all the time.

But making the action itself require a flag? Brilliant. Using stsndard streams? Brilliant. Showing what it will do, not the end result? Brilliant.

I'm going to download and and start experimenting right away.

It might be worth noting that while ripgrep doesn't support in-place file editing, it's still possible to replace matches using the `-r` flag, couple that with a tool like `sponge` from moreutils[0] and you can effectively perform search and place like such:

    $ rg --passthru search -r replace file.txt | sponge file.txt

And preview changes like this:

    $ rg --passthru search -r replace file.txt | diff -u file.txt -

Of course, this is only practical when working with a single file. Though I'd imagine if one threw in the `--files-with-matches -0` flags together and piped that into `xargs`, something similar to `rep` could be be achieved. (Not that I'd encourage anyone to do this at all)

[0] https://joeyh.name/code/moreutils/

Writing a correct POSIX script to rename files programmatically in Unix is surprisingly tricky; one reason is symlinks, the other is the binary nature of pathnames (the third one is the anemic POSIX spec, but we make use of what we have). It is good that most people went with Perl for safety.

If I have time, I'll check these utils to see if they handle all pathnames correctly.

Somewhat similar to the approach taken by qmv (from the renameutils package) where file renaming is done by editing the names of the files in a text editor.

To the author: The GIFs on the GitHub pages seem to be about double the speed from the YouTube videos. I find them too fast to follow.

I like it. Generalizing this one step further, there are a bunch of actions like this that are hidden inside our IDEs (whether VSCode / Neovim plugins or built-in functionality), which might be nice to pull out into standard unix tools.

Particularly as we get more investment in AI driving tooling, this sort of lift might be more and more common.

It is great to see that the simplicity of Emacs wgrep inspires new tools. The Emacs interface is more powerful than this new tool because one can more easily do selective or arbitrary edits in the search results, but the new tool is easier to integrate into command line scripts and may be more practical in the end. I like the modality of seeing the diffs until you’re fine with them and then applying them.

This looks pretty neat! I especially like how well it composes with other tools.

Wonder how well it compares with fastmod [0]? That's what I've been using for large scale codemods/refactors. ripgrep is ofc insanely fast so ripgrep+ren would probably fare favorably.

[0]: https://github.com/facebookincubator/fastmod/

If you could pipe the ripgrep output into an editor, make changes, and have them applied, that would be great. Once you get all the text you want to change in one buffer, it should be easy to make repetitive changes quickly in your editor of choice.

The website breaks for a phone interface, the code lines are neither scrollable nor break lines:/