ripgrep

A recurring workflow of mine is to search within an existing list of files. Currently I'm living by which is both inconvenient and inefficient. Ack does provide a option. Implementing it would allow me to type to fulfill my needs.

I'd like to suggest a new option, such as or (name TBD, the shorter the better), very similar to the existing , which would read the list of files or directories to be searched from . The value would mean the list should be read from stdin. Here are some use cases: Search from an existing (potentially long) list of files, which was previously generated, and could be reused across several calls. Search for files containing multiple patterns, but not necessarily on the same line, by chaining calls. As an example: searching for files containing , and : The output would be a nicely presented list of matches, with headings. This also shows why a short option name would be useful. This would be an equivalent to the following on Linux: But my main usage is on Windows, which doesn't have , so the same command on PowerShell would be: Not only is it less readable (IMO), but it also doesn't support long lists of files to search from, as command-line arguments are limited to 32 kb on Windows: Probably some other usages from #875 Of course, would have to be incompatible with and stdin input. I know you don't like adding more options, and for full disclosure I already have a script which handles this, but I believe this would be a useful feature for many people. If you'd like, I think I can write and submit a simple implementation in which would be based on (which handles ). The main issue I see with this approach is that stdin would need to be drained before the search begins, but this is already the case with anyway. I just wanted to check with you first if that's something you'd be willing to accept.

Filenames and file contents can contain terminal control sequences like OSC52 clipboard writes, OSC8 hyperlink injection, cursor moves that spoof output. When ripgrep prints them to a tty, the terminal acts on them. This PR sanitizes the relevant sequences before they reach the terminal. Sanitization is gated on whether stdout is an interactive tty. Pipe output is left byte-exact so , , , and similar pipelines see exactly the bytes they see today. Implementation is a 256-byte lookup table with a four-way branch. The fast path returns Cow::Borrowed without allocating. On a 50 MB / ~80k-match Rust corpus the tty path runs within the noise of the unsanitized baseline. Library API change is additive: one is_terminal(bool) method per printer (Standard, Summary, PathPrinter), default false. Existing embedders see no behavior change unless they opt in. Covers: matched-line content, printed paths in standard/summary/path-list output, and stderr error messages from .gitignore parsing (see issue #1992). JSON output is unaffected. @BurntSushi I know you had some resevationas bout filters in the past but I hope this approach with interactive vs piped matches how you want ripgrep to behave while we can also address the relevant risks. There is no measurable performance impact