bach-sh/bach

"No Arguments" descriptor is annoying to use

hanneskaeufler-bmw opened this issue · 4 comments

Since 447edb6
there is a visualization for "no arguments passed".

Some tests written against this library before this commit now fail with things like:
Bildschirmfoto 2022-04-21 um 19 26 55

Making those tests pass again is annoying, because the descriptor that is to be pushed
into the verification is using a lot of escape sequences.

The only way I found to make those test pass is to

BACH_NO_ARGUMENTS_SIGN=$'\x1b\x5b31m\u2205\x1b\x5b0m'
pushd"  "$BACH_NO_ARGUMENTS_SIGN

Maybe I'm missing something, but this I don't find ergonomic. Copy&pasting the
sign from terminal into the editor did not work due to the "red" escape sequence
not being copied.

Hi, thank you for this issue.

Yes, the name can be a bit confusing, but it is mainly used within Bach. A better name for this sign would be "empty argument" or "empty string"

It happens when we pass an empty string to a command

test-pass-an-empty-string() {
    foobar ""
}
test-pass-an-empty-string-assert() {
    foobar
}

Another case is we want to assign output from a command to a variable, but we forgot to mock that command

test-forgot-to-mock-a-command() {
    foobar "$(forgot-to-mock-this-command param1 param2)"
}
test-forgot-to-mock-a-command-assert() {
    foobar
}

Hi, thanks for your quick response. Your example is a perfect example of the issue, this happens if you run it:
Bildschirmfoto 2022-04-22 um 09 13 21

but it is mainly used within Bach

So that's not true, it immediately bubbles to the end-user, who then has to find an ugly workaround.

Greetings!

Aahh thanks again, yeah, so the "" is needed to make the test pass, not the cryptic escape sequence. Works fine now 👍 I guess this is more of a documentation issue then.