Solution

I will always stress that your solution can be written however you like as long as it passes the provided test suite. In the following find_files function, I choose to use the imperative approach of manually pushing to a vector rather than collecting from an iterator. The function will either collect a single error for a bad path or flatten the iterable WalkDir to recursively get the files. Be sure you add use std::fs and use walkdir::WalkDir for this code:

fn find_files(paths: &[String], recursive: bool) -> Vec<MyResult<String>> {
    let mut results = vec![]; 

    for path in paths { 
        match path.as_str() {
            "-" => results.push(Ok(path.to_string())), 
            _ => match fs::metadata(path) { 
                Ok(metadata) => {
                    if metadata.is_dir() { 
                        if recursive { 
                            for entry in WalkDir::new(path) 
                                .into_iter()
                                .flatten() 
                                .filter(|e| e.file_type().is_file())
                            {
                                results.push(Ok(entry
                                    .path()
                                    .display()
                                    .to_string()));
                            }
                        } else {
                            results.push(Err(From::from(format!( 
                                "{} is a directory",
                                path
                            ))));
                        }
                    } else if metadata.is_file() { 
                        results.push(Ok(path.to_string()));
                    }
                }
                Err(e) => { 
                    results.push(Err(From::from(format!("{}: {}", path, e))))
                }
            },
        }
    }

    results
}

Initialize an empty vector to hold the results.

Iterate over each of the given paths.

First, accept a dash (-) as a path, for STDIN.

Try to get the path’s metadata.

Check if the path is a directory.

Check if the user wants to recursively search directories.

Add all the files in the given directory to the results.

Iterator::flatten will take the Ok or Some variants for Result and Option types and will ignore the Err and None variants, meaning it will ignore any errors with files found by recursing through directories.

Note an error that the given entry is a directory.

If the path is a file, add it to the results.

This arm will be triggered by nonexistent files.

Next, I will share my find_lines function. The following code requires that you add use std::mem to your imports. This borrows heavily from previous functions that read files line by line, so I won’t comment on code I’ve used before:

fn find_lines<T: BufRead>(
    mut file: T,
    pattern: &Regex,
    invert_match: bool,
) -> MyResult<Vec<String>> {
    let mut matches = vec![]; 
    let mut line = String::new();

    loop {
        let bytes = file.read_line(&mut line)?;
        if bytes == 0 {
            break;
        }
        if pattern.is_match(&line) ^ invert_match { 
            matches.push(mem::take(&mut line)); 
        }
        line.clear();
    }

    Ok(matches) 
}

Initialize a mutable vector to hold the matching lines.

Use the BitXor bit-wise exclusive OR operator (^) to determine if the line should be included.

Use std::mem::take to take ownership of the line. I could have used clone to copy the string and add it to the matches, but take avoids an unnecessary copy.

In the preceding function, the bitwise XOR comparison (^) could also be expressed using a combination of the logical AND (&&) and OR operators (||) like so:

if (pattern.is_match(&line) && !invert_match) 
    || (!pattern.is_match(&line) && invert_match) 
{
    matches.push(line.clone());
}

Verify that the line matches and the user does not want to invert the match.

Alternatively, check if the line does not match and the user wants to invert the match.

At the beginning of the run function, I decided to create a closure to handle the printing of the output with or without the filenames given the number of input files:

pub fn run(config: Config) -> MyResult<()> {
    let entries = find_files(&config.files, config.recursive); 
    let num_files = entries.len(); 
    let print = |fname: &str, val: &str| { 
        if num_files > 1 {
            print!("{}:{}", fname, val);
        } else {
            print!("{}", val);
        }
    };

Find all the inputs.

Find the number of inputs.

Create a print closure that uses the number of inputs to decide whether to print the filenames in the output.

Continuing from there, the program attempts to find the matching lines from the entries:

    for entry in entries {
        match entry {
            Err(e) => eprintln!("{}", e), 
            Ok(filename) => match open(&filename) { 
                Err(e) => eprintln!("{}: {}", filename, e), 
                Ok(file) => {
                    match find_lines( 
                        file,
                        &config.pattern,
                        config.invert_match,
                    ) {
                        Err(e) => eprintln!("{}", e), 
                        Ok(matches) => {
                            if config.count { 
                                print(
                                    &filename,
                                    &format!("{}\n", matches.len()),
                                );
                            } else {
                                for line in &matches {
                                    print(&filename, line);
                                }
                            }
                        }
                    }
                }
            },
        }
    }
    Ok(())
}

Print errors like nonexistent files to STDERR.

Attempt to open a file. This might fail due to permissions.

Print an error to STDERR.

Attempt to find the matching lines of text.

Print errors to STDERR.

Decide whether to print the number of matches or the matches themselves.

At this point, the program should pass all the tests.

Going Further

The Rust ripgrep tool implements many of the features of grep and is worthy of your study. You can install the program using the instructions provided and then execute rg. As shown in Figure 9-1, the matching text is highlighted in the output. Try to add that feature to your program using Regex::find to find the start and stop positions of the matching pattern and something like termcolor to highlight the matches.

Figure 9-1. The ripgrep tool will highlight the matching text.

The author of ripgrep wrote an extensive blog post about design decisions that went into writing the program. In the section “Repeat After Me: Thou Shalt Not Search Line by Line,” the author discusses the performance hit of searching over lines of text, the majority of which will not match.

Summary

This chapter challenged you to extend skills you learned in Chapter 7, such as recursively finding files in directories and using regular expressions. In this chapter, you combined those skills to find content inside files matching (or not matching) a given regex. In addition, you learned the following:

• How to use RegexBuilder to create more complicated regular expressions using, for instance, the case-insensitive option to match strings regardless of case.

• There are multiple syntaxes for writing regular expressions that different tools recognize, such as PCRE. Rust’s regex engine does not implement some features of PCRE, such as look-around assertions or backreferences.

• You can indicate a trait bound like BufRead in function signatures using either impl BufRead or <T: BufRead>.

• Rust’s bitwise XOR operator can replace more complex logical operations that combine AND and OR comparisons.

In the next chapter, you’ll learn more about iterating the lines of a file, how to compare strings, and how to create a more complicated enum type.