Add `--in`/`--in0` options to read input paths from files or stdin by ltrzesniewski · Pull Request #3462 · BurntSushi/ripgrep

ltrzesniewski · 2026-07-05T19:12:36Z

This PR adds --in and --in0 command-line options, which read files or directories to be searched from their arguments, similar to as if they were specified on the command line. ~~If the file contains relative paths, their paths are resolved relatively to the input file.~~ The value - means the list of files should be read from stdin.

e.g. having a file files.txt with the following content:

foo.txt
bar.txt

Then running rg pattern --in files.txt is equivalent to running rg pattern foo.txt bar.txt.

--in reads from a text file (supporting LF and CRLF line terminators), while --in0 reads from a null-delimited file. Both flags can be used multiple times. ~~Empty entries are ignored.~~

These features are designed for reusing input files and ripgrep calls chaining, such as:

$ rg foo -l | rg bar --in=- -l | rg baz --in=-
$ rg foo -l0 | rg bar --in0=- -l0 | rg baz --in0=-

These commands will find all the files that contain foo, bar and baz, and will highlight all of the baz matches, with headings and line numbers. The second one is equivalent to:

rg -0l foo | xargs -0 rg bar -0l | xargs -0 rg baz

Implementation notes:

Currently, the paths read from the input file are treated exactly as if they were specified on the command line, which means relative paths are relative to the current working directory, not the directory of the input file. This may be surprising behavior, but is consistent with the way xargs works. Please tell me if you'd prefer for the paths to be relative to the input file instead (or the CWD when stdin is used). I really don't know which one is better TBH, so I defer to your opinion.
Decision: interpret everything as if it were a command-lime argument.
This implies the exit code will always be 2 if there's any non-existent path in an input file.
There is no data streaming: all the paths are read into memory before searching. This keeps the implementation relatively simple.
The implementation is loosely based on --file, but I was reluctant to create a grep_cli::input module similar to grep_cli::pattern for this kind of functionality, so I put everything in rg::flags::hiargs::Paths::read_from_input. This feels a bit messy/unidiomatic to me TBH, don't hesitate to suggest some other approach if you think it would be better.
There is a little mixup between std::io::Result and anyhow::Result in read_from_input due to the signatures bstr::io::BufReadExt expects. I'm not sure if that's ok or not.
If a file passed to --in contains a NUL byte, it's almost certainly an error, and is reported as such.

Related issues:

ltrzesniewski · 2026-07-06T21:26:45Z

Actually I think I prefer the paths to be relative to the input file, as this makes more sense to me. I pushed a second commit which changes the behavior. Feel free to drop it if you'd rather have the xargs behavior.

BurntSushi

Nice work for an initial pass!

BurntSushi · 2026-07-08T01:58:50Z

+.sp
+When this flag is used multiple times or in combination with the \flag{in0}
+flag, then all provided files are searched in addition to the paths in the
+positional arguments.


I think this should be a little more specific. Something like:

When this flag is used, it behaves as if the file paths in the file provided were passed as positional arguments in the same order as they are in the file and relative to other positional arguments.

BurntSushi · 2026-07-08T02:04:31Z

+flag, then all provided files are searched in addition to the paths in the
+positional arguments.
+.sp
+Empty lines are ignored, and newlines (both LF and CRLF) are not counted as


find does not ignore empty lines and instead errors. I think we should do the same here. The one exception is that we should treat this file as line (or NUL) terminated, not delimited. That is, if the file has a trailing newline or NUL, then that's fine and doesn't indicate the start of another file path if nothing follows it.

(I note that empty lines are not ignored with ripgrep's -f/--file flag. They are treated as an empty string, which creates a regex that matches at all positions.)

For this flag, I think an empty line is just something we should error on. It's also the conservative choice. We can change an error into something else that isn't an error later, but we can't do the reverse.

BurntSushi · 2026-07-08T02:04:56Z

+Empty lines are ignored, and newlines (both LF and CRLF) are not counted as
+part of the path. The rest of the path name is decoded as UTF-8 on Windows
+and taken as-is on Unix systems.
+Use the \flag{in0} flag to use \fBNUL\fP as separator.


I would use the word "terminator" instead.

BurntSushi · 2026-07-08T02:05:58Z

+Empty entries are ignored. The path names are decoded as UTF-8 on Windows
+and taken as-is on Unix systems.
+.sp
+When \fIINPUTFILE\fP is \fB-\fP, then \fBstdin\fP will be read for the files.


Same comments apply as above.

BurntSushi · 2026-07-08T02:07:56Z

+            InputSource::TextFile(PathBuf::from("baz")),
+        ],
+        args.inputs
+    );


Can you add tests that mingle --in, --in0 and other positional paths?

BurntSushi · 2026-07-08T02:17:22Z

            if state.stdin_consumed && path == Path::new("-") {
                anyhow::bail!(
-                    "error: attempted to read patterns from stdin \
+                    "error: attempted to read patterns or inputs from stdin \


"or input file paths"

BurntSushi · 2026-07-08T02:22:34Z

        let mut paths = Vec::with_capacity(low.positional.len());
+        for input in low.inputs.drain(..) {
+            Self::read_from_input(state, &input, &mut paths)?
+        }


I think we want users to be able to mingle --in and --in0 with positional paths and have them processed in the same order as given. This means, I think, that low.positional needs to become an InputSource and InputSource needs to grow a third single-file-path variant. To do this, I think this needs to be tweaked:

https://github.com/BurntSushi/ripgrep/blob/48b0c795f4feb37343b2832d991c5c6a3900c08a/crates/core/flags/parse.rs#L259-L228

BurntSushi · 2026-07-08T02:23:24Z

+                    reader.for_byte_line(|line| {
+                        if line.contains(&0u8) {
+                            return Err(std::io::Error::other(format!(
+                                "--in {}: file contains a NUL byte, \


Error messages should just start with a file path. The --in can come after the colon.

Also, anyhow::bail! should be used here. And anywhere else you're building an io::Error like this.

The issue I have with this is that for_byte_line/for_byte_record expect a function which returns io::Result<bool>. Maybe I'm stupid, but I don't see a way to use them with anyhow...

Oh whoops, that's my bad. You aren't stupid. Thanks for pushing back. :-)

BurntSushi · 2026-07-08T02:24:24Z

+    /// A text file with newline-separated paths. Comes from the `--in` flag.
+    TextFile(PathBuf),
+    /// A text file with NUL-separated paths. Comes from the `--in0` flag.
+    BinaryFile(PathBuf),


These should be LineTerminated and NulTerminated.

BurntSushi · 2026-07-08T02:26:07Z

+        cmd.arg("--file").arg("-").arg("--in0").arg("-").arg("match");
+        cmd.assert_exit_code(2);
+    }
+);


There are enough tests here that this warrants its own module.

Can you include tests that mingle --in, --in0 and positional file paths?

okdana · 2026-07-08T18:10:02Z

    "--no-ignore-files[don't respect --ignore-file flags]"
    $no'--ignore-files[respect --ignore-file files]'

+    + input # Read input paths from file options


you can get rid of the group comment, i've removed them all now

okdana · 2026-07-08T18:15:50Z

    $no'--ignore-files[respect --ignore-file files]'

+    + input # Read input paths from file options
+    '*--in=[text file containing paths to search]: :_files'


these should both start with 'specify ...'

ltrzesniewski · 2026-07-12T15:11:25Z

Thank you for your reviews @BurntSushi and @okdana!

I took all your comments into account and rebased the PR. This version is basically a major rewrite, but it feels much better and more idiomatic to me thanks to your insights. 🙂

ltrzesniewski · 2026-07-22T17:50:07Z

I just rebased again because I noticed there were conflicts, and a new test needed an update.

Adds `--in` and `--in0` command-line options, which read files or directories to be searched from their arguments, as if they were specified on the command line. The value `-` means the list of files should be read from stdin. e.g. having a file `files.txt` with the following content: ``` foo.txt bar.txt ``` Then running `rg pattern --in files.txt` is *equivalent* to running `rg pattern foo.txt bar.txt`. `--in` reads from a text file (supporting LF and CRLF line terminators), while `--in0` reads from a null-delimited file. Both flags can be used multiple times. These features are designed for reusing input files and ripgrep calls chaining. Fixes BurntSushi#3459 and BurntSushi#273

ltrzesniewski mentioned this pull request Jul 5, 2026

Implement such --files-from option #273

Open

BurntSushi requested changes Jul 8, 2026

View reviewed changes

okdana reviewed Jul 8, 2026

View reviewed changes

BurntSushi mentioned this pull request Jul 9, 2026

support more sophisticated boolean matching operations #875

Open

ltrzesniewski force-pushed the input-file-pr branch from db18217 to bf683fc Compare July 12, 2026 15:03

ltrzesniewski requested a review from BurntSushi July 12, 2026 15:11

ltrzesniewski force-pushed the input-file-pr branch from bf683fc to 3314671 Compare July 22, 2026 17:47

ltrzesniewski marked this pull request as draft August 11, 2026 11:19

ltrzesniewski force-pushed the input-file-pr branch from 3314671 to 11df15d Compare August 11, 2026 11:20

ltrzesniewski marked this pull request as ready for review August 11, 2026 11:20

Uh oh!

Conversation

ltrzesniewski commented Jul 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ltrzesniewski commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BurntSushi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ltrzesniewski commented Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ltrzesniewski commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ltrzesniewski commented Jul 5, 2026 •

edited

Loading

ltrzesniewski commented Jul 6, 2026 •

edited

Loading

ltrzesniewski commented Jul 12, 2026 •

edited

Loading

ltrzesniewski commented Jul 22, 2026 •

edited

Loading