-
Notifications
You must be signed in to change notification settings - Fork 21
Provide option to not trim output strings #77
Comments
By the way, I'm not curious if this way of trimming behaves the same under Windows as it does on Unix-like systems. |
Thanks for the feedback. While trimming is a help to most people, I can see how some cases need exact handling. |
You are not curious? Then you probably don't want to read this: (:trollface:)
|
Huhu, @killercup! That was supposed to be a "now". Yeah, I think I wasn't clear about that comment. I meant the |
Hi Behnam! 👋 I have no way to test this on Windows but Do you feel like digging into libstd and friends? 'Cause I feel like it. Let's look at the code! This leads me here which in turn brings me to this and finally to this impl of self.trim_matches(|c: char| c.is_whitespace()) So, what is (Sorry, you probably knew all that. But I kinda wanted to write it down cause I like this kind of thing 😅) |
@killercup, nice writing, but for the newline matters, I'm not talking about Rust's I looked at the documentation for And I don't see any newline conversion being done outside of So, if I write an Assert::main_binary()
.with_args(&["Hello"])
.stdout().is("Hello") //.
.stdout().contains("Hello\n") //.
.unwrap(); it will be passing on Unix, but will fail on Windows. So, if the goal is to be able to support cross-platform matching for multiline outputs either a newline-less pattern should be supported (like What do you think, @killercup? Is this a goal to support any matching string (via |
Oh, I see, thanks for clarifying, @behnam! I see two options here: We just note in the docs that you need to take care of platform-specific line endings, or our matchers deal with that automatically. I'm in favor of the latter, because I don't want to deal with that kind of stuff as a user.
Adding this to the difference crate is most likely the best way to do it (even if just to avoid the (Btw, I have the feeling that most people use |
Right. Most people don't need multi-line matching. But for some applications it's necessary.
Agreed. Almost any diff library/command I know has options for ignoring newline differences, and possibly more generally, number of whitespaces (one or more). For CLI testing, I need the former, but think that some applications can use of the latter, as well. /cc @johannhof For now, I think I'll have to use |
My proposed API for this.
So the API would look like Assert::main_binary()
.stdout(contains("Music\nMagic").trim(false).normalize_newline(false))
.unwrap() |
I like the API, @epage. Just a quick reminder that at the moment, |
Correct. One benefit of changing to this is it would create consistency across different predicates. |
FYI, I just learned something about Rust on Windows:
From: So, the example I provided before, it actually does work fine in Windows. But, because my implementation depends on This could be the reason |
The responsibility for this is moving to assert_cmd and predicate-rs.
assert_cli is going to morph into a wider-focused tool, including things like assert_fs. See #41 |
https://github.com/killercup/assert_cli/blob/3bc97874a188423fcdc3252c5d677b0fb048530e/src/output.rs#L34
Writing an
echo
-like tool, I want to be able to test the output for detailed behavior on trailing newline characters. Unfortunately, it's not possible now because of the trimming done on both strings.It would be great to have an option to disable the trimming, as a config or an alternate to
is()
, likeis_exactly()
.The text was updated successfully, but these errors were encountered: