diff options
Diffstat (limited to 'src/doc/book/nostarch/chapter12.md')
| -rw-r--r-- | src/doc/book/nostarch/chapter12.md | 454 |
1 files changed, 244 insertions, 210 deletions
diff --git a/src/doc/book/nostarch/chapter12.md b/src/doc/book/nostarch/chapter12.md index 950b2e999..86e986173 100644 --- a/src/doc/book/nostarch/chapter12.md +++ b/src/doc/book/nostarch/chapter12.md @@ -26,8 +26,8 @@ Along the way, we’ll show how to make our command line tool use the terminal features that many other command line tools use. We’ll read the value of an environment variable to allow the user to configure the behavior of our tool. We’ll also print error messages to the standard error console stream (`stderr`) -instead of standard output (`stdout`), so, for example, the user can redirect -successful output to a file while still seeing error messages onscreen. +instead of standard output (`stdout`) so that, for example, the user can +redirect successful output to a file while still seeing error messages onscreen. One Rust community member, Andrew Gallant, has already created a fully featured, very fast version of `grep`, called `ripgrep`. By comparison, our @@ -37,14 +37,14 @@ background knowledge you need to understand a real-world project such as Our `grep` project will combine a number of concepts you’ve learned so far: -* Organizing code (using what you learned about modules in Chapter 7) -* Using vectors and strings (collections, Chapter 8) +* Organizing code (Chapter 7) +* Using vectors and strings (Chapter 8) * Handling errors (Chapter 9) * Using traits and lifetimes where appropriate (Chapter 10) * Writing tests (Chapter 11) We’ll also briefly introduce closures, iterators, and trait objects, which -Chapters 13 and 17 will cover in detail. +Chapter 13 and Chapter 17 will cover in detail. ## Accepting Command Line Arguments @@ -69,8 +69,8 @@ $ cargo run -- searchstring example-filename.txt ``` Right now, the program generated by `cargo new` cannot process arguments we -give it. Some existing libraries on *https://crates.io/* can help with writing -a program that accepts command line arguments, but because you’re just learning +give it. Some existing libraries on *https://crates.io* can help with writing a +program that accepts command line arguments, but because you’re just learning this concept, let’s implement this capability ourselves. ### Reading the Argument Values @@ -85,7 +85,7 @@ collection, such as a vector, that contains all the elements the iterator produces. The code in Listing 12-1 allows your `minigrep` program to read any command -line arguments passed to it and then collect the values into a vector. +line arguments passed to it, and then collect the values into a vector. Filename: src/main.rs @@ -101,7 +101,7 @@ fn main() { Listing 12-1: Collecting the command line arguments into a vector and printing them -First, we bring the `std::env` module into scope with a `use` statement so we +First we bring the `std::env` module into scope with a `use` statement so we can use its `args` function. Notice that the `std::env::args` function is nested in two levels of modules. As we discussed in Chapter 7, in cases where the desired function is nested in more than one module, we’ve chosen to bring @@ -111,20 +111,20 @@ adding `use std::env::args` and then calling the function with just `args`, because `args` might easily be mistaken for a function that’s defined in the current module. -> ### The `args` Function and Invalid Unicode +> ### The args Function and Invalid Unicode > > Note that `std::env::args` will panic if any argument contains invalid -> Unicode. If your program needs to accept arguments containing invalid -> Unicode, use `std::env::args_os` instead. That function returns an iterator -> that produces `OsString` values instead of `String` values. We’ve chosen to -> use `std::env::args` here for simplicity, because `OsString` values differ -> per platform and are more complex to work with than `String` values. +Unicode. If your program needs to accept arguments containing invalid Unicode, +use `std::env::args_os` instead. That function returns an iterator that +produces `OsString` values instead of `String` values. We’ve chosen to use +`std::env::args` here for simplicity because `OsString` values differ per +platform and are more complex to work with than `String` values. On the first line of `main`, we call `env::args`, and we immediately use `collect` to turn the iterator into a vector containing all the values produced by the iterator. We can use the `collect` function to create many kinds of collections, so we explicitly annotate the type of `args` to specify that we -want a vector of strings. Although we very rarely need to annotate types in +want a vector of strings. Although you very rarely need to annotate types in Rust, `collect` is one function you do often need to annotate because Rust isn’t able to infer the kind of collection you want. @@ -137,9 +137,6 @@ $ cargo run [src/main.rs:5] args = [ "target/debug/minigrep", ] -``` - -``` $ cargo run -- needle haystack --snip-- [src/main.rs:5] args = [ @@ -153,8 +150,8 @@ Notice that the first value in the vector is `"target/debug/minigrep"`, which is the name of our binary. This matches the behavior of the arguments list in C, letting programs use the name by which they were invoked in their execution. It’s often convenient to have access to the program name in case you want to -print it in messages or change behavior of the program based on what command -line alias was used to invoke the program. But for the purposes of this +print it in messages or change the behavior of the program based on what +command line alias was used to invoke the program. But for the purposes of this chapter, we’ll ignore it and save only the two arguments we need. ### Saving the Argument Values in Variables @@ -184,7 +181,7 @@ Listing 12-2: Creating variables to hold the query argument and file path argument As we saw when we printed the vector, the program’s name takes up the first -value in the vector at `args[0]`, so we’re starting arguments at index `1`. The +value in the vector at `args[0]`, so we’re starting arguments at index 1. The first argument `minigrep` takes is the string we’re searching for, so we put a reference to the first argument in the variable `query`. The second argument will be the file path, so we put a reference to the second argument in the @@ -212,7 +209,7 @@ capabilities instead. ## Reading a File Now we’ll add functionality to read the file specified in the `file_path` -argument. First, we need a sample file to test it with: we’ll use a file with a +argument. First we need a sample file to test it with: we’ll use a file with a small amount of text over multiple lines with some repeated words. Listing 12-3 has an Emily Dickinson poem that will work well! Create a file called *poem.txt* at the root level of your project, and enter the poem “I’m Nobody! @@ -232,7 +229,7 @@ To tell your name the livelong day To an admiring bog! ``` -Listing 12-3: A poem by Emily Dickinson makes a good test case +Listing 12-3: A poem by Emily Dickinson makes a good test case. With the text in place, edit *src/main.rs* and add code to read the file, as shown in Listing 12-4. @@ -241,26 +238,26 @@ Filename: src/main.rs ``` use std::env; -[1] use std::fs; +1 use std::fs; fn main() { - // --snip-- + --snip-- println!("In file {}", file_path); - [2] let contents = fs::read_to_string(file_path) + 2 let contents = fs::read_to_string(file_path) .expect("Should have been able to read the file"); - [3] println!("With text:\n{contents}"); + 3 println!("With text:\n{contents}"); } ``` Listing 12-4: Reading the contents of the file specified by the second argument -First, we bring in a relevant part of the standard library with a `use` +First we bring in a relevant part of the standard library with a `use` statement: we need `std::fs` to handle files [1]. In `main`, the new statement `fs::read_to_string` takes the `file_path`, opens -that file, and returns a `std::io::Result<String>` of the file’s contents [2]. +that file, and returns an `std::io::Result<String>` of the file’s contents [2]. After that, we again add a temporary `println!` statement that prints the value of `contents` after the file is read, so we can check that the program is @@ -295,9 +292,9 @@ responsibilities: generally, functions are clearer and easier to maintain if each function is responsible for only one idea. The other problem is that we’re not handling errors as well as we could. The program is still small, so these flaws aren’t a big problem, but as the program grows, it will be harder to fix -them cleanly. It’s good practice to begin refactoring early on when developing -a program, because it’s much easier to refactor smaller amounts of code. We’ll -do that next. +them cleanly. It’s a good practice to begin refactoring early on when +developing a program because it’s much easier to refactor smaller amounts of +code. We’ll do that next. ## Refactoring to Improve Modularity and Error Handling @@ -342,12 +339,12 @@ community has developed guidelines for splitting the separate concerns of a binary program when `main` starts getting large. This process has the following steps: -* Split your program into a *main.rs* and a *lib.rs* and move your program’s - logic to *lib.rs*. +* Split your program into a *main.rs* file and a *lib.rs* file and move your +program’s logic to *lib.rs*. * As long as your command line parsing logic is small, it can remain in - *main.rs*. +*main.rs*. * When the command line parsing logic starts getting complicated, extract it - from *main.rs* and move it to *lib.rs*. +from *main.rs* and move it to *lib.rs*. The responsibilities that remain in the `main` function after this process should be limited to the following: @@ -358,7 +355,7 @@ should be limited to the following: * Handling the error if `run` returns an error This pattern is about separating concerns: *main.rs* handles running the -program, and *lib.rs* handles all the logic of the task at hand. Because you +program and *lib.rs* handles all the logic of the task at hand. Because you can’t test the `main` function directly, this structure lets you test all of your program’s logic by moving it into functions in *lib.rs*. The code that remains in *main.rs* will be small enough to verify its correctness by reading @@ -368,7 +365,7 @@ it. Let’s rework our program by following this process. We’ll extract the functionality for parsing arguments into a function that `main` will call to prepare for moving the command line parsing logic to -*src/lib.rs*. Listing 12-5 shows the new start of `main` that calls a new +src/lib.rs*. Listing 12-5 shows the new start of `main` that calls a new function `parse_config`, which we’ll define in *src/main.rs* for the moment. Filename: src/main.rs @@ -379,7 +376,7 @@ fn main() { let (query, file_path) = parse_config(&args); - // --snip-- + --snip-- } fn parse_config(args: &[String]) -> (&str, &str) { @@ -431,25 +428,25 @@ Filename: src/main.rs fn main() { let args: Vec<String> = env::args().collect(); - [1] let config = parse_config(&args); + 1 let config = parse_config(&args); - println!("Searching for {}", config.query[2]); - println!("In file {}", config.file_path[3]); + println!("Searching for {}", 2 config.query); + println!("In file {}", 3 config.file_path); - let contents = fs::read_to_string(config.file_path[4]) + let contents = fs::read_to_string(4 config.file_path) .expect("Should have been able to read the file"); - // --snip-- + --snip-- } -[5] struct Config { +5 struct Config { query: String, file_path: String, } -[6] fn parse_config(args: &[String]) -> Config { - [7] let query = args[1].clone(); - [8] let file_path = args[2].clone(); +6 fn parse_config(args: &[String]) -> Config { + 7 let query = args[1].clone(); + 8 let file_path = args[2].clone(); Config { query, file_path } } @@ -459,8 +456,8 @@ Listing 12-6: Refactoring `parse_config` to return an instance of a `Config` struct We’ve added a struct named `Config` defined to have fields named `query` and -`file_path` [5]. The signature of `parse_config` now indicates that it returns a -`Config` value [6]. In the body of `parse_config`, where we used to return +`file_path` [5]. The signature of `parse_config` now indicates that it returns +a `Config` value [6]. In the body of `parse_config`, where we used to return string slices that reference `String` values in `args`, we now define `Config` to contain owned `String` values. The `args` variable in `main` is the owner of the argument values and is only letting the `parse_config` function borrow @@ -469,44 +466,43 @@ ownership of the values in `args`. There are a number of ways we could manage the `String` data; the easiest, though somewhat inefficient, route is to call the `clone` method on the values -[7][8]. This will make a full copy of the data for the `Config` instance to +[7] [8]. This will make a full copy of the data for the `Config` instance to own, which takes more time and memory than storing a reference to the string data. However, cloning the data also makes our code very straightforward because we don’t have to manage the lifetimes of the references; in this circumstance, giving up a little performance to gain simplicity is a worthwhile trade-off. -> ### The Trade-Offs of Using `clone` +> ### The Trade-Offs of Using clone > > There’s a tendency among many Rustaceans to avoid using `clone` to fix -> ownership problems because of its runtime cost. In -> Chapter 13, you’ll learn how to use more efficient -> methods in this type of situation. But for now, it’s okay to copy a few -> strings to continue making progress because you’ll make these copies only -> once and your file path and query string are very small. It’s better to have -> a working program that’s a bit inefficient than to try to hyperoptimize code -> on your first pass. As you become more experienced with Rust, it’ll be -> easier to start with the most efficient solution, but for now, it’s -> perfectly acceptable to call `clone`. +ownership problems because of its runtime cost. In Chapter 13, you’ll learn how +to use more efficient methods in this type of situation. But for now, it’s okay +to copy a few strings to continue making progress because you’ll make these +copies only once and your file path and query string are very small. It’s +better to have a working program that’s a bit inefficient than to try to +hyperoptimize code on your first pass. As you become more experienced with +Rust, it’ll be easier to start with the most efficient solution, but for now, +it’s perfectly acceptable to call `clone`. We’ve updated `main` so it places the instance of `Config` returned by `parse_config` into a variable named `config` [1], and we updated the code that previously used the separate `query` and `file_path` variables so it now uses -the fields on the `Config` struct instead [2][3][4]. +the fields on the `Config` struct instead [2] [3] [4]. Now our code more clearly conveys that `query` and `file_path` are related and that their purpose is to configure how the program will work. Any code that uses these values knows to find them in the `config` instance in the fields named for their purpose. -#### Creating a Constructor for `Config` +#### Creating a Constructor for Config So far, we’ve extracted the logic responsible for parsing the command line arguments from `main` and placed it in the `parse_config` function. Doing so -helped us to see that the `query` and `file_path` values were related and that +helped us see that the `query` and `file_path` values were related, and that relationship should be conveyed in our code. We then added a `Config` struct to -name the related purpose of `query` and `file_path` and to be able to return the -values’ names as struct field names from the `parse_config` function. +name the related purpose of `query` and `file_path` and to be able to return +the values’ names as struct field names from the `parse_config` function. So now that the purpose of the `parse_config` function is to create a `Config` instance, we can change `parse_config` from a plain function to a function @@ -523,15 +519,15 @@ Filename: src/main.rs fn main() { let args: Vec<String> = env::args().collect(); - [1] let config = Config::new(&args); + 1 let config = Config::new(&args); - // --snip-- + --snip-- } -// --snip-- +--snip-- -[2] impl Config { - [3] fn new(args: &[String]) -> Config { +2 impl Config { + 3 fn new(args: &[String]) -> Config { let query = args[1].clone(); let file_path = args[2].clone(); @@ -559,8 +555,10 @@ $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) Finished dev [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep` -thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:27:21 -note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace +thread 'main' panicked at 'index out of bounds: the len is 1 but +the index is 1', src/main.rs:27:21 +note: run with `RUST_BACKTRACE=1` environment variable to display +a backtrace ``` The line `index out of bounds: the len is 1 but the index is 1` is an error @@ -570,18 +568,18 @@ they should do instead. Let’s fix that now. #### Improving the Error Message In Listing 12-8, we add a check in the `new` function that will verify that the -slice is long enough before accessing index 1 and 2. If the slice isn’t long -enough, the program panics and displays a better error message. +slice is long enough before accessing index 1 and index 2. If the slice isn’t +long enough, the program panics and displays a better error message. Filename: src/main.rs ``` -// --snip-- +--snip-- fn new(args: &[String]) -> Config { if args.len() < 3 { panic!("not enough arguments"); } - // --snip-- + --snip-- ``` Listing 12-8: Adding a check for the number of arguments @@ -589,9 +587,9 @@ Listing 12-8: Adding a check for the number of arguments This code is similar to the `Guess::new` function we wrote in Listing 9-13, where we called `panic!` when the `value` argument was out of the range of valid values. Instead of checking for a range of values here, we’re checking -that the length of `args` is at least 3 and the rest of the function can +that the length of `args` is at least `3` and the rest of the function can operate under the assumption that this condition has been met. If `args` has -fewer than three items, this condition will be true, and we call the `panic!` +fewer than three items, this condition will be `true`, and we call the `panic!` macro to end the program immediately. With these extra few lines of code in `new`, let’s run the program without any @@ -602,19 +600,21 @@ $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) Finished dev [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep` -thread 'main' panicked at 'not enough arguments', src/main.rs:26:13 -note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace +thread 'main' panicked at 'not enough arguments', +src/main.rs:26:13 +note: run with `RUST_BACKTRACE=1` environment variable to display +a backtrace ``` This output is better: we now have a reasonable error message. However, we also -have extraneous information we don’t want to give to our users. Perhaps using -the technique we used in Listing 9-13 isn’t the best to use here: a call to +have extraneous information we don’t want to give to our users. Perhaps the +technique we used in Listing 9-13 isn’t the best one to use here: a call to `panic!` is more appropriate for a programming problem than a usage problem, as discussed in Chapter 9. Instead, we’ll use the other technique you learned about in Chapter 9—returning a `Result` that indicates either success or an error. -#### Returning a `Result` Instead of Calling `panic!` +#### Returning a Result Instead of Calling panic! We can instead return a `Result` value that will contain a `Config` instance in the successful case and will describe the problem in the error case. We’re also @@ -650,7 +650,7 @@ impl Config { Listing 12-9: Returning a `Result` from `Config::build` Our `build` function returns a `Result` with a `Config` instance in the success -case and a `&'static str` in the error case. Our error values will always be +case and an `&'static str` in the error case. Our error values will always be string literals that have the `'static` lifetime. We’ve made two changes in the body of the function: instead of calling `panic!` @@ -662,7 +662,7 @@ Returning an `Err` value from `Config::build` allows the `main` function to handle the `Result` value returned from the `build` function and exit the process more cleanly in the error case. -#### Calling `Config::build` and Handling Errors +#### Calling Config::build and Handling Errors To handle the error case and print a user-friendly message, we need to update `main` to handle the `Result` being returned by `Config::build`, as shown in @@ -674,17 +674,17 @@ called our program that the program exited with an error state. Filename: src/main.rs ``` -[1] use std::process; +1 use std::process; fn main() { let args: Vec<String> = env::args().collect(); - [2] let config = Config::build(&args).unwrap_or_else([3]|err[4]| { - [5] println!("Problem parsing arguments: {err}"); - [6] process::exit(1); + 2 let config = Config::build(&args).3 unwrap_or_else(|4 err| { + 5 println!("Problem parsing arguments: {err}"); + 6 process::exit(1); }); - // --snip-- + --snip-- ``` Listing 12-10: Exiting with an error code if building a `Config` fails @@ -693,11 +693,11 @@ In this listing, we’ve used a method we haven’t covered in detail yet: `unwrap_or_else`, which is defined on `Result<T, E>` by the standard library [2]. Using `unwrap_or_else` allows us to define some custom, non-`panic!` error handling. If the `Result` is an `Ok` value, this method’s behavior is similar -to `unwrap`: it returns the inner value `Ok` is wrapping. However, if the value -is an `Err` value, this method calls the code in the *closure*, which is an -anonymous function we define and pass as an argument to `unwrap_or_else` [3]. -We’ll cover closures in more detail in Chapter 13. For now, you just need to -know that `unwrap_or_else` will pass the inner value of the `Err`, which in +to `unwrap`: it returns the inner value that `Ok` is wrapping. However, if the +value is an `Err` value, this method calls the code in the *closure*, which is +an anonymous function we define and pass as an argument to `unwrap_or_else` +[3]. We’ll cover closures in more detail in Chapter 13. For now, you just need +to know that `unwrap_or_else` will pass the inner value of the `Err`, which in this case is the static string `"not enough arguments"` that we added in Listing 12-9, to our closure in the argument `err` that appears between the vertical pipes [4]. The code in the closure can then use the `err` value when @@ -721,12 +721,12 @@ Problem parsing arguments: not enough arguments Great! This output is much friendlier for our users. -### Extracting Logic from `main` +### Extracting Logic from main Now that we’ve finished refactoring the configuration parsing, let’s turn to the program’s logic. As we stated in “Separation of Concerns for Binary -Projects”, we’ll extract a function named `run` that will hold all the logic -currently in the `main` function that isn’t involved with setting up +Projects” on page XX, we’ll extract a function named `run` that will hold all +the logic currently in the `main` function that isn’t involved with setting up configuration or handling errors. When we’re done, `main` will be concise and easy to verify by inspection, and we’ll be able to write tests for all the other logic. @@ -739,7 +739,7 @@ Filename: src/main.rs ``` fn main() { - // --snip-- + --snip-- println!("Searching for {}", config.query); println!("In file {}", config.file_path); @@ -754,7 +754,7 @@ fn run(config: Config) { println!("With text:\n{contents}"); } -// --snip-- +--snip-- ``` Listing 12-11: Extracting a `run` function containing the rest of the program @@ -764,7 +764,7 @@ The `run` function now contains all the remaining logic from `main`, starting from reading the file. The `run` function takes the `Config` instance as an argument. -#### Returning Errors from the `run` Function +#### Returning Errors from the run Function With the remaining program logic separated into the `run` function, we can improve the error handling, as we did with `Config::build` in Listing 12-9. @@ -777,25 +777,25 @@ signature and body of `run`. Filename: src/main.rs ``` -[1] use std::error::Error; +1 use std::error::Error; -// --snip-- +--snip-- -[2] fn run(config: Config) -> Result<(), Box<dyn Error>> { - let contents = fs::read_to_string(config.file_path)?[3]; +2 fn run(config: Config) -> Result<(), Box<dyn Error>> { + let contents = fs::read_to_string(config.file_path)3 ?; println!("With text:\n{contents}"); - [4] Ok(()) + 4 Ok(()) } ``` Listing 12-12: Changing the `run` function to return `Result` We’ve made three significant changes here. First, we changed the return type of -the `run` function to `Result<(), Box<dyn Error>>` [2]. This function previously -returned the unit type, `()`, and we keep that as the value returned in the -`Ok` case. +the `run` function to `Result<(), Box<dyn Error>>` [2]. This function +previously returned the unit type, `()`, and we keep that as the value returned +in the `Ok` case. For the error type, we used the *trait object* `Box<dyn Error>` (and we’ve brought `std::error::Error` into scope with a `use` statement at the top [1]). @@ -803,7 +803,7 @@ We’ll cover trait objects in Chapter 17. For now, just know that `Box<dyn Error>` means the function will return a type that implements the `Error` trait, but we don’t have to specify what particular type the return value will be. This gives us flexibility to return error values that may be of different -types in different error cases. The `dyn` keyword is short for “dynamic.” +types in different error cases. The `dyn` keyword is short for *dynamic*. Second, we’ve removed the call to `expect` in favor of the `?` operator [3], as we talked about in Chapter 9. Rather than `panic!` on an error, `?` will return @@ -826,7 +826,8 @@ warning: unused `Result` that must be used | ^^^^^^^^^^^^ | = note: `#[warn(unused_must_use)]` on by default - = note: this `Result` may be an `Err` variant, which should be handled + = note: this `Result` may be an `Err` variant, which should be +handled ``` Rust tells us that our code ignored the `Result` value and the `Result` value @@ -834,7 +835,7 @@ might indicate that an error occurred. But we’re not checking to see whether o not there was an error, and the compiler reminds us that we probably meant to have some error-handling code here! Let’s rectify that problem now. -#### Handling Errors Returned from `run` in `main` +#### Handling Errors Returned from run in main We’ll check for errors and handle them using a technique similar to one we used with `Config::build` in Listing 12-10, but with a slight difference: @@ -843,7 +844,7 @@ Filename: src/main.rs ``` fn main() { - // --snip-- + --snip-- println!("Searching for {}", config.query); println!("In file {}", config.file_path); @@ -856,11 +857,11 @@ fn main() { ``` We use `if let` rather than `unwrap_or_else` to check whether `run` returns an -`Err` value and call `process::exit(1)` if it does. The `run` function doesn’t -return a value that we want to `unwrap` in the same way that `Config::build` -returns the `Config` instance. Because `run` returns `()` in the success case, -we only care about detecting an error, so we don’t need `unwrap_or_else` to -return the unwrapped value, which would only be `()`. +`Err` value and to call `process::exit(1)` if it does. The `run` function +doesn’t return a value that we want to `unwrap` in the same way that +`Config::build` returns the `Config` instance. Because `run` returns `()` in +the success case, we only care about detecting an error, so we don’t need +`unwrap_or_else` to return the unwrapped value, which would only be `()`. The bodies of the `if let` and the `unwrap_or_else` functions are the same in both cases: we print the error and exit. @@ -868,10 +869,10 @@ both cases: we print the error and exit. ### Splitting Code into a Library Crate Our `minigrep` project is looking good so far! Now we’ll split the -*src/main.rs* file and put some code into the *src/lib.rs* file. That way we +*src/main.rs* file and put some code into the *src/lib.rs* file. That way, we can test the code and have a *src/main.rs* file with fewer responsibilities. -Let’s move all the code that isn’t the `main` function from *src/main.rs* to +Let’s move all the code that isn’t in the `main` function from *src/main.rs* to *src/lib.rs*: * The `run` function definition @@ -895,13 +896,15 @@ pub struct Config { } impl Config { - pub fn build(args: &[String]) -> Result<Config, &'static str> { - // --snip-- + pub fn build( + args: &[String], + ) -> Result<Config, &'static str> { + --snip-- } } pub fn run(config: Config) -> Result<(), Box<dyn Error>> { - // --snip-- + --snip-- } ``` @@ -923,9 +926,9 @@ use std::process; use minigrep::Config; fn main() { - // --snip-- + --snip-- if let Err(e) = minigrep::run(config) { - // --snip-- + --snip-- } } ``` @@ -935,8 +938,7 @@ Listing 12-14: Using the `minigrep` library crate in *src/main.rs* We add a `use minigrep::Config` line to bring the `Config` type from the library crate into the binary crate’s scope, and we prefix the `run` function with our crate name. Now all the functionality should be connected and should -work. Run the program with `cargo run` and make sure everything works -correctly. +work. Run the program with `cargo run` and make sure everything works correctly. Whew! That was a lot of work, but we’ve set ourselves up for success in the future. Now it’s much easier to handle errors, and we’ve made the code more @@ -954,21 +956,21 @@ for the core functionality of our code. We can call functions directly with various arguments and check return values without having to call our binary from the command line. -In this section, we’ll add the searching logic to the `minigrep` program -using the test-driven development (TDD) process with the following steps: +In this section, we’ll add the searching logic to the `minigrep` program using +the test-driven development (TDD) process with the following steps: 1. Write a test that fails and run it to make sure it fails for the reason you - expect. -2. Write or modify just enough code to make the new test pass. -3. Refactor the code you just added or changed and make sure the tests - continue to pass. -4. Repeat from step 1! +expect. +1. Write or modify just enough code to make the new test pass. +1. Refactor the code you just added or changed and make sure the tests continue +to pass. +1. Repeat from step 1! Though it’s just one of many ways to write software, TDD can help drive code design. Writing the test before you write the code that makes the test pass helps to maintain high test coverage throughout the process. -We’ll test drive the implementation of the functionality that will actually do +We’ll test-drive the implementation of the functionality that will actually do the searching for the query string in the file contents and produce a list of lines that match the query. We’ll add this functionality in a function called `search`. @@ -977,11 +979,11 @@ lines that match the query. We’ll add this functionality in a function called Because we don’t need them anymore, let’s remove the `println!` statements from *src/lib.rs* and *src/main.rs* that we used to check the program’s behavior. -Then, in *src/lib.rs*, add a `tests` module with a test function, as we did in -Chapter 11. The test function specifies the behavior we want the `search` -function to have: it will take a query and the text to search, and it will -return only the lines from the text that contain the query. Listing 12-15 shows -this test, which won’t compile yet. +Then, in *src/lib.rs*, we’ll add a `tests` module with a test function, as we +did in Chapter 11. The test function specifies the behavior we want the +`search` function to have: it will take a query and the text to search, and it +will return only the lines from the text that contain the query. Listing 12-15 +shows this test, which won’t compile yet. Filename: src/lib.rs @@ -998,7 +1000,10 @@ Rust: safe, fast, productive. Pick three."; - assert_eq!(vec!["safe, fast, productive."], search(query, contents)); + assert_eq!( + vec!["safe, fast, productive."], + search(query, contents) + ); } } ``` @@ -1006,7 +1011,7 @@ Pick three."; Listing 12-15: Creating a failing test for the `search` function we wish we had This test searches for the string `"duct"`. The text we’re searching is three -lines, only one of which contains `"duct"` (Note that the backslash after the +lines, only one of which contains `"duct"` (note that the backslash after the opening double quote tells Rust not to put a newline character at the beginning of the contents of this string literal). We assert that the value returned from the `search` function contains only the line we expect. @@ -1017,12 +1022,15 @@ principles, we’ll add just enough code to get the test to compile and run by adding a definition of the `search` function that always returns an empty vector, as shown in Listing 12-16. Then the test should compile and fail because an empty vector doesn’t match a vector containing the line `"safe, -fast, productive."` +fast, productive."`. Filename: src/lib.rs ``` -pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { +pub fn search<'a>( + query: &str, + contents: &'a str, +) -> Vec<&'a str> { vec![] } ``` @@ -1049,16 +1057,24 @@ get this error: ``` error[E0106]: missing lifetime specifier - --> src/lib.rs:28:51 + --> src/lib.rs:31:10 | -28 | pub fn search(query: &str, contents: &str) -> Vec<&str> { - | ---- ---- ^ expected named lifetime parameter +29 | query: &str, + | ---- +30 | contents: &str, + | ---- +31 | ) -> Vec<&str> { + | ^ expected named lifetime parameter | - = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `query` or `contents` + = help: this function's return type contains a borrowed value, but the +signature does not say whether it is borrowed from `query` or `contents` help: consider introducing a named lifetime parameter | -28 | pub fn search<'a>(query: &'a str, contents: &'a str) -> Vec<&'a str> { - | ++++ ++ ++ ++ +28 ~ pub fn search<'a>( +29 ~ query: &'a str, +30 ~ contents: &'a str, +31 ~ ) -> Vec<&'a str> { + | ``` Rust can’t possibly know which of the two arguments we need, so we need to tell @@ -1069,8 +1085,8 @@ syntax. Other programming languages don’t require you to connect arguments to return values in the signature, but this practice will get easier over time. You might -want to compare this example with the “Validating References with Lifetimes” -section in Chapter 10. +want to compare this example with the examples in “Validating References with +Lifetimes” on page XX. Now let’s run the test: @@ -1086,16 +1102,17 @@ test tests::one_result ... FAILED failures: ---- tests::one_result stdout ---- -thread 'main' panicked at 'assertion failed: `(left == right)` +thread 'tests::one_result' panicked at 'assertion failed: `(left == right)` left: `["safe, fast, productive."]`, - right: `[]`', src/lib.rs:44:9 + right: `[]`', src/lib.rs:47:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: tests::one_result -test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; +finished in 0.00s error: test failed, to rerun pass '--lib' ``` @@ -1107,24 +1124,27 @@ Great, the test fails, exactly as we expected. Let’s get the test to pass! Currently, our test is failing because we always return an empty vector. To fix that and implement `search`, our program needs to follow these steps: -* Iterate through each line of the contents. -* Check whether the line contains our query string. -* If it does, add it to the list of values we’re returning. -* If it doesn’t, do nothing. -* Return the list of results that match. +1. Iterate through each line of the contents. +1. Check whether the line contains our query string. +1. If it does, add it to the list of values we’re returning. +1. If it doesn’t, do nothing. +1. Return the list of results that match. Let’s work through each step, starting with iterating through lines. -#### Iterating Through Lines with the `lines` Method +#### Iterating Through Lines with the lines Method Rust has a helpful method to handle line-by-line iteration of strings, -conveniently named `lines`, that works as shown in Listing 12-17. Note this -won’t compile yet. +conveniently named `lines`, that works as shown in Listing 12-17. Note that +this won’t compile yet. Filename: src/lib.rs ``` -pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { +pub fn search<'a>( + query: &str, + contents: &'a str, +) -> Vec<&'a str> { for line in contents.lines() { // do something with line } @@ -1143,12 +1163,15 @@ in a collection. Next, we’ll check whether the current line contains our query string. Fortunately, strings have a helpful method named `contains` that does this for us! Add a call to the `contains` method in the `search` function, as shown in -Listing 12-18. Note this still won’t compile yet. +Listing 12-18. Note that this still won’t compile yet. Filename: src/lib.rs ``` -pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { +pub fn search<'a>( + query: &str, + contents: &'a str, +) -> Vec<&'a str> { for line in contents.lines() { if line.contains(query) { // do something with line @@ -1160,8 +1183,8 @@ pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { Listing 12-18: Adding functionality to see whether the line contains the string in `query` -At the moment, we’re building up functionality. To get it to compile, we need -to return a value from the body as we indicated we would in the function +At the moment, we’re building up functionality. To get the code to compile, we +need to return a value from the body as we indicated we would in the function signature. #### Storing Matching Lines @@ -1174,7 +1197,10 @@ we return the vector, as shown in Listing 12-19. Filename: src/lib.rs ``` -pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { +pub fn search<'a>( + query: &str, + contents: &'a str, +) -> Vec<&'a str> { let mut results = Vec::new(); for line in contents.lines() { @@ -1198,7 +1224,8 @@ $ cargo test running 1 test test tests::one_result ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 +filtered out; finished in 0.00s ``` Our test passed, so we know it works! @@ -1210,7 +1237,7 @@ but it doesn’t take advantage of some useful features of iterators. We’ll return to this example in Chapter 13, where we’ll explore iterators in detail, and look at how to improve it. -#### Using the `search` Function in the `run` Function +#### Using the search Function in the run Function Now that the `search` function is working and tested, we need to call `search` from our `run` function. We need to pass the `config.query` value and the @@ -1234,7 +1261,7 @@ pub fn run(config: Config) -> Result<(), Box<dyn Error>> { We’re still using a `for` loop to return each line from `search` and print it. Now the entire program should work! Let’s try it out, first with a word that -should return exactly one line from the Emily Dickinson poem, “frog”: +should return exactly one line from the Emily Dickinson poem: *frog*. ``` $ cargo run -- frog poem.txt @@ -1244,7 +1271,7 @@ $ cargo run -- frog poem.txt How public, like a frog ``` -Cool! Now let’s try a word that will match multiple lines, like “body”: +Cool! Now let’s try a word that will match multiple lines, like *body*: ``` $ cargo run -- body poem.txt @@ -1256,7 +1283,7 @@ How dreary to be somebody! ``` And finally, let’s make sure that we don’t get any lines when we search for a -word that isn’t anywhere in the poem, such as “monomorphization”: +word that isn’t anywhere in the poem, such as *monomorphization*: ``` $ cargo run -- monomorphization poem.txt @@ -1281,7 +1308,7 @@ users enter it each time they want it to apply, but by instead making it an environment variable, we allow our users to set the environment variable once and have all their searches be case insensitive in that terminal session. -### Writing a Failing Test for the Case-Insensitive `search` Function +### Writing a Failing Test for the Case-Insensitive search Function We first add a new `search_case_insensitive` function that will be called when the environment variable has a value. We’ll continue to follow the TDD process, @@ -1306,7 +1333,10 @@ safe, fast, productive. Pick three. Duct tape."; - assert_eq!(vec!["safe, fast, productive."], search(query, contents)); + assert_eq!( + vec!["safe, fast, productive."], + search(query, contents) + ); } #[test] @@ -1330,7 +1360,7 @@ Listing 12-20: Adding a new failing test for the case-insensitive function we’re about to add Note that we’ve edited the old test’s `contents` too. We’ve added a new line -with the text `"Duct tape."` using a capital D that shouldn’t match the query +with the text `"Duct tape."` using a capital *D* that shouldn’t match the query `"duct"` when we’re searching in a case-sensitive manner. Changing the old test in this way helps ensure that we don’t accidentally break the case-sensitive search functionality that we’ve already implemented. This test should pass now @@ -1338,18 +1368,18 @@ and should continue to pass as we work on the case-insensitive search. The new test for the case-*insensitive* search uses `"rUsT"` as its query. In the `search_case_insensitive` function we’re about to add, the query `"rUsT"` -should match the line containing `"Rust:"` with a capital R and match the line -`"Trust me."` even though both have different casing from the query. This is -our failing test, and it will fail to compile because we haven’t yet defined +should match the line containing `"Rust:"` with a capital *R* and match the +line `"Trust me."` even though both have different casing from the query. This +is our failing test, and it will fail to compile because we haven’t yet defined the `search_case_insensitive` function. Feel free to add a skeleton implementation that always returns an empty vector, similar to the way we did for the `search` function in Listing 12-16 to see the test compile and fail. -### Implementing the `search_case_insensitive` Function +### Implementing the search_case_insensitive Function The `search_case_insensitive` function, shown in Listing 12-21, will be almost the same as the `search` function. The only difference is that we’ll lowercase -the `query` and each `line` so whatever the case of the input arguments, +the `query` and each `line` so that whatever the case of the input arguments, they’ll be the same case when we check whether the line contains the query. Filename: src/lib.rs @@ -1359,11 +1389,11 @@ pub fn search_case_insensitive<'a>( query: &str, contents: &'a str, ) -> Vec<&'a str> { - [1] let query = query.to_lowercase(); + 1 let query = query.to_lowercase(); let mut results = Vec::new(); for line in contents.lines() { - if line.to_lowercase()[2].contains(&query[3]) { + if 2 line.to_lowercase().contains(3 &query) { results.push(line); } } @@ -1375,8 +1405,8 @@ pub fn search_case_insensitive<'a>( Listing 12-21: Defining the `search_case_insensitive` function to lowercase the query and the line before comparing them -First, we lowercase the `query` string and store it in a shadowed variable with -the same name [1]. Calling `to_lowercase` on the query is necessary so no +First we lowercase the `query` string and store it in a shadowed variable with +the same name [1]. Calling `to_lowercase` on the query is necessary so that no matter whether the user’s query is `"rust"`, `"RUST"`, `"Rust"`, or `"rUsT"`, we’ll treat the query as if it were `"rust"` and be insensitive to the case. While `to_lowercase` will handle basic Unicode, it won’t be 100% accurate. If @@ -1384,7 +1414,7 @@ we were writing a real application, we’d want to do a bit more work here, but this section is about environment variables, not Unicode, so we’ll leave it at that here. -Note that `query` is now a `String` rather than a string slice, because calling +Note that `query` is now a `String` rather than a string slice because calling `to_lowercase` creates new data rather than referencing existing data. Say the query is `"rUsT"`, as an example: that string slice doesn’t contain a lowercase `u` or `t` for us to use, so we have to allocate a new `String` containing @@ -1403,14 +1433,15 @@ running 2 tests test tests::case_insensitive ... ok test tests::case_sensitive ... ok -test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s +test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 +filtered out; finished in 0.00s ``` Great! They passed. Now, let’s call the new `search_case_insensitive` function -from the `run` function. First, we’ll add a configuration option to the -`Config` struct to switch between case-sensitive and case-insensitive search. -Adding this field will cause compiler errors because we aren’t initializing -this field anywhere yet: +from the `run` function. First we’ll add a configuration option to the `Config` +struct to switch between case-sensitive and case-insensitive search. Adding +this field will cause compiler errors because we aren’t initializing this field +anywhere yet: Filename: src/lib.rs @@ -1461,10 +1492,12 @@ Filename: src/lib.rs ``` use std::env; -// --snip-- +--snip-- impl Config { - pub fn build(args: &[String]) -> Result<Config, &'static str> { + pub fn build( + args: &[String] + ) -> Result<Config, &'static str> { if args.len() < 3 { return Err("not enough arguments"); } @@ -1486,7 +1519,7 @@ impl Config { Listing 12-23: Checking for any value in an environment variable named `IGNORE_CASE` -Here, we create a new variable `ignore_case`. To set its value, we call the +Here, we create a new variable, `ignore_case`. To set its value, we call the `env::var` function and pass it the name of the `IGNORE_CASE` environment variable. The `env::var` function returns a `Result` that will be the successful `Ok` variant that contains the value of the environment variable if @@ -1496,7 +1529,7 @@ if the environment variable is not set. We’re using the `is_ok` method on the `Result` to check whether the environment variable is set, which means the program should do a case-insensitive search. If the `IGNORE_CASE` environment variable isn’t set to anything, `is_ok` will -return false and the program will perform a case-sensitive search. We don’t +return `false` and the program will perform a case-sensitive search. We don’t care about the *value* of the environment variable, just whether it’s set or unset, so we’re checking `is_ok` rather than using `unwrap`, `expect`, or any of the other methods we’ve seen on `Result`. @@ -1505,9 +1538,9 @@ We pass the value in the `ignore_case` variable to the `Config` instance so the `run` function can read that value and decide whether to call `search_case_insensitive` or `search`, as we implemented in Listing 12-22. -Let’s give it a try! First, we’ll run our program without the environment +Let’s give it a try! First we’ll run our program without the environment variable set and with the query `to`, which should match any line that contains -the word “to” in all lowercase: +the word *to* in all lowercase: ``` $ cargo run -- to poem.txt @@ -1518,8 +1551,8 @@ Are you nobody, too? How dreary to be somebody! ``` -Looks like that still works! Now, let’s run the program with `IGNORE_CASE` -set to `1` but with the same query `to`. +Looks like that still works! Now let’s run the program with `IGNORE_CASE` set +to `1` but with the same query `to`: ``` $ IGNORE_CASE=1 cargo run -- to poem.txt @@ -1532,14 +1565,14 @@ run the program as separate commands: PS> $Env:IGNORE_CASE=1; cargo run -- to poem.txt ``` -This will make `IGNORE_CASE` persist for the remainder of your shell -session. It can be unset with the `Remove-Item` cmdlet: +This will make `IGNORE_CASE` persist for the remainder of your shell session. +It can be unset with the `Remove-Item` cmdlet: ``` PS> Remove-Item Env:IGNORE_CASE ``` -We should get lines that contain “to” that might have uppercase letters: +We should get lines that contain *to* that might have uppercase letters: ``` Are you nobody, too? @@ -1548,7 +1581,7 @@ To tell your name the livelong day To an admiring bog! ``` -Excellent, we also got lines containing “To”! Our `minigrep` program can now do +Excellent, we also got lines containing *To*! Our `minigrep` program can now do case-insensitive searching controlled by an environment variable. Now you know how to manage options set using either command line arguments or environment variables. @@ -1573,12 +1606,12 @@ error messages. This distinction enables users to choose to direct the successful output of a program to a file but still print error messages to the screen. -The `println!` macro is only capable of printing to standard output, so we -have to use something else to print to standard error. +The `println!` macro is only capable of printing to standard output, so we have +to use something else to print to standard error. ### Checking Where Errors Are Written -First, let’s observe how the content printed by `minigrep` is currently being +First let’s observe how the content printed by `minigrep` is currently being written to standard output, including any error messages we want to write to standard error instead. We’ll do that by redirecting the standard output stream to a file while intentionally causing an error. We won’t redirect the standard @@ -1587,7 +1620,7 @@ the screen. Command line programs are expected to send error messages to the standard error stream so we can still see error messages on the screen even if we redirect the -standard output stream to a file. Our program is not currently well-behaved: +standard output stream to a file. Our program is not currently well behaved: we’re about to see that it saves the error message output to a file instead! To demonstrate this behavior, we’ll run the program with `>` and the file path, @@ -1684,3 +1717,4 @@ well tested. Next, we’ll explore some Rust features that were influenced by functional languages: closures and iterators. + |