bashunit
bashunit copied to clipboard
Multi-line strings not supported for assert_equals
| Q | A |
|---|---|
| OS | macOS / Linux / Windows |
| Shell | bash |
| bashunit version | 0.12.0 |
Summary
Discovered: https://github.com/TypedDevs/bashunit/pull/266#issuecomment-2176591645
Current behavior
Would it make sense to emit an error in case of multi-line strings telling the user that its not supported?
I wish that would be possible (or know how to do that...), however, at this point:
function assert_equals() {
local expected="$1"
local actual="$2"
# ... etc ...
The issue is that there is no possibility to know if the second argumnet is a line that belong the text from the first argument or is a real new argument. Does it make sense? Therefore, for example, in here:
function assert_contains() {
local expected="$1"
local actual_arr=("${@:2}")
local actual=$(printf '%s\n' "${actual_arr[@]}")
if ! [[ $actual == *"$expected"* ]]; then
# ... etc
what I am doing is to gather together all args (starting from the 2nd), store it into actual_arr and then concat all items with a new line \n into actual and so I can manipulate them easier. Does it makes sense and helps understand the intrinsic issue coming from bash? At least, I didn't find another way around to make this work so far... Maybe at a future time we find a better way to do this, but for now, I think it's good enough if this works in your PHPStan CI 😄
Expected behavior
Either allow the functionality to work OR notify the user that it's not supported
I wonder whether this problem is related to IFS:
https://unix.stackexchange.com/questions/184863/what-is-the-meaning-of-ifs-n-in-bash-scripting
?
Just curious: this issue is by design, isn't it? Docs of assert_equals quote:
Reports an error if the two variables expected and actual are not equal ignoring the special chars like ANSI Escape Sequences (colors) and other special chars like tabs and new lines.
@carlfriedrich correct. That is how I designed the original logic for this function as a trade of based on my bash skills and something that I considered OK by the time. I created this issue to don't forget about it and in case someone would ever know if this would be possible or even by using a different design.
@Chemaclass Thanks for the reply. Then I actually don't see what the issue is. All of these assertions pass, and according to the docs that is expected behavior:
function test_equals_with_newline() {
assert_equals "a
b" "ab"
assert_equals "ab" "a
b"
assert_equals "a
b" "a
b"
}
@carlfriedrich oh, you're 100% right, now I get it. I thought back then when I created this issue this was not possible, but now as you display in your test_equals_with_newline all of them are passing, which means this issue does no longer make sense 🥳 thank you!