Because the dominant use case for an editor is pasting an exact
identifier or string from code, where $, ., ( are common and
regex-escaping them is exactly the sed pain ripsed exists to remove.
Searching (rg) skews toward patterns; replacing skews toward literals.
Add -e when you want regex.
Replacement strings on the CLI are literal apart from $1-style
capture references — \n is two characters. Pass a real newline from
your shell ($'\n' in bash) or use a .rip script, where "\n"
inside double quotes is interpreted. (Find patterns with -e do
understand \n, because the regex engine interprets it.)
ripgrep's convention: 0 = made (or previewed) changes, 1 = ran
cleanly but nothing matched, 2 = error. Errors win over partial
success — if any file errored, the run exits 2 even when other files
were changed.
Advisory-lock sentinels. Mutual exclusion between concurrent ripsed
processes uses kernel file locks (flock/LockFileEx) on a sentinel
that is deliberately never deleted — removing it would let another
process lock a different inode at the same path and race. They're
empty-ish, harmless, and safe to gitignore (*.ripsed.lock).
A file is skipped as binary if its first 8 KB contains a NUL byte —
unless it starts with a UTF-16 byte-order mark, in which case it's
decoded, edited, and re-encoded byte-compatibly (BOM preserved). UTF-8
BOMs are stripped before matching (so ^ anchors work on line 1) and
re-attached on write. UTF-16 without a BOM and other encodings
(Latin-1, Shift-JIS, …) are out of scope: undetectable cheaply, and
guessing wrong corrupts files.
.ripsed/undo.jsonl in the directory you ran from — written 0600
because it contains pre-edit file contents, entry count capped via
.ripsed.toml. Undo restores original bytes exactly, including
encoding and BOM. Because each entry stores the full original text,
files larger than undo.max_file_bytes (default 4 MiB, 0 =
unlimited) are edited but not recorded — you get a one-line stderr
note when that happens. --no-undo (JSON: "record_undo": false)
skips recording entirely for bulk runs.
For tree-wide refactors with discovery, yes — and when most files don't match, the whole-buffer prescreen rejects them at substring-search speed. For a single multi-hundred-MB file, GNU sed is currently faster (measured honestly in BENCHMARKS.md). Use the right tool.
ripsed-cli is the binary (cargo install ripsed-cli puts ripsed
on your PATH). ripsed is the library facade for embedding the engine
(apply_to_file, apply_to_files) in your own tools; ripsed-core,
ripsed-fs, and ripsed-json are its layers.
No — it prompts on a TTY between preview and write, so it's
interactive by definition (and forces single-threaded processing).
For automation, use --dry-run to inspect and JSON mode's
dry_run/atomic options to gate writes.