Option to not to normalize backslash

[MiSawa]

I noticed that this fails due to "backslash to slash normalization".

bin.name = "bin-fixture"
stdout = '\'
[env.add]
stdout = '\'

It is probably useful for things that outputs paths, but is cumbersome for other things, e.g. a tool that outputs JSON, as test has to be stdout = '"/"escaped/""' for example instead of stdout = '"\"escaped\""', and there's no way to check if the output was actually correctly escaped with \. I know that there's a bin mode, but I still want line separators normalized. It'd be great to have a way to turn off the path separator normalization feature.

[epage]

The main question with this is deciding how to expose it.

[MiSawa]

It'd be great if it is exposed via TestCases for global default configuration like

let t = trycmd::TestCases::new()
t.output_normalize_path(false); // default: true (for compatibility)
t.output_normalize_line_separator(true); // default: true

and maybe per-test override via toml configuration

output_normalize_path = false
output_normalize_line_separator = true

though I guess it'll be a bit cumbersome to handle conflict with binary = true/false...

[epage]

Is there a reason you'd want to offer control over line normalization instead of just associating that with binary?

though I guess it'll be a bit cumbersome to handle conflict with binary = true/false...

I'd just ignore or error if binary = true

btw I've been forgetting to write this up but https://github.com/assert-rs/trycmd/issues/93 might also be useful

[MiSawa]

Is there a reason you'd want to offer control over line normalization instead of just associating that with binary?

Since I still want line separators to be normalized...

I'd just ignore or error if binary = true

Yeah that sounds reasonable.

btw I've been forgetting to write this up but https://github.com/assert-rs/trycmd/issues/93 might also be useful

That'd be a great feature. But in my case, I want to verify not just as a json but some other things, like if it is properly indented and if the order of object entries are kept.

[epage]

Since I still want line separators to be normalized...

More so I was wondering is if binary = false should automatically mean normalize line endings. If we had flags for each individual part of binary = false, then the flag might start to lose its value so I was wanting to explore how the all the pieces fit together.

Granted, I don't remember if we strip BOMs but that might be the most basic binary = false behavior.

That'd be a great feature. But in my case, I want to verify not just as a json but some other things, like if it is properly indented and if the order of object entries are kept.

Yes, I want to keep this in mind and give people control over that. Could you post that to the issue both so its explicitly recorded and so you'll be subscribed so you can make sure the solution for opting out is acceptable?

[MiSawa]

More so I was wondering is if binary = false should automatically mean normalize line endings. If we had flags for each individual part of binary = false, then the flag might start to lose its value so I was wanting to explore how the all the pieces fit together.

Ah sorry, I see what you meant now. Making binary = false normalize line separator works for my use case at least, and probably that's something others would expect.

Yes, I want to keep this in mind and give people control over that. Could you post that to the issue both so its explicitly recorded and so you'll be subscribed so you can make sure the solution for opting out is acceptable?

Filed #94 and #95 :)

[kraktus]

Another solution would be to compare ouputs before normalization, and only normalize if the ouputs do not already matches (optimally even only normalise if it detects the failure is due to missing normalisation, but haven’t checked source code see if possible)

[epage]

iirc I had considered that at one point but the challenge is it doesn't scale to different normalization options. Originally when I considered this, I was also wondering about the different replacement patterns supported, etc.