Open carols10cents opened 3 years ago
Would it be more appropriate to compare by bytes?
let expected = String::from_utf8_lossy(&buffer);
will convert the single byte read from expected/*.txt to 3-bytes UTF8 string.
As I understand, head -c1 should only read one byte from input file, without doing any UTF8 conversion, am i wrong? or it will do some special charset handing if it's stdin is connected to terminal?
The iimplemention use file.lines() to get data, which convert bytes into utf-8 String, it's better to use read(buf: &[u8]) to read bytes directly from file when -c is specified if I understand correctly.
I think I finally have a good solution in using "pretty_assertions::assert_eq" instead of assert_cmd's "stdout" comparison. It's a tiny bit more work, but the output is much more helpful. I'm using it on the "clap_v4*" branches.
Putting this as an issue on this repo rather than commenting on the book because this problem isn't actually anything to do with the book text; it only exists in this repo.
I realize that because headr in chapter 3 is demonstrating how splitting UTF-8 codepoints when requesting a number of bytes results in invalid UTF-8, you can't match on Rust strings and you have to use
predicate::eq(&expected.as_bytes() as &[u8])
. Buuut it makes trying to figure out why a test is failing rather frustrating :(For example:
Or a different one where I am printing the invalid UTF-8 correctly (but messed up the newlines, but it's hard to tell that from this message):
The problem is that it prints the expected bytes but prints the actual stdout as string.
I wanted to send this as a PR rather than an issue, but I haven't found a great solution and wanted to brainstorm some ideas with you...
run
function, usetry_stdout
instead ofstdout
and, if the result is_err, do some custom printing instead of, or in addition to, what assert_cmd printsWhat do you think?