Closed dimo414 closed 4 years ago
Thanks for the suggestion. This was suggested in the past, where I made a case for keeping the standard [
since not much is gained by switching to [[
.
Thanks, it makes sense that it would have come up before :)
Simply put, we're using [ everywhere where [[ is not needed, and [[ is only superior when it comes to pattern matching and complex boolean expressions. In every other case, [ is just fine
For the project's code itself I agree it's not worth churning conditionals that already work just to use [[
, but for the README I think there's value in consistently suggesting patterns that are less error-prone and work consistently. Needing to swap between the different syntaxes is confusing, especially for folks who don't spend all their time in the shell.
the advantage of expressions written in a simpler way is that people can study them and copy into a POSIX-compatible shell and they will still work.
I confess this doesn't make much sense to me; Bats is a "testing framework for Bash", not for POSIX-compatible shells. What's the advantage for Bats to being POSIX-compatible here? Users who need POSIX-compatibility (which I'll contend is relatively rare) should know how to transform [[
tests into POSIX-compatible commands.
In adition to the Wooledge FAQ entry linked in the previous issue, the Google Style Guide [also discourages [
](https://google.github.io/styleguide/shell.xml#Test,_%5B_and_%5B%5B) (not that you're bound to their style guide, of course).
One final rationale, which is also why I sent the pull-request in the first place: [
looks antiquated, and often implies code that is dated or not following best-practices. Using modern syntax is a hint to readers that a project is maintained and high-quality.
Anyways, I won't lose a lot of sleep over it if you don't want this PR, I just learned about Bats and am excited to use it!
[ ... ]
(akatest
) can be confusing and error-prone. The[[ ... ]]
and(( ... ))
constructs are easier to work with.Also add a test that the
$lines
array has the expected number of lines; otherwise it's easy to accidentally check only the lines you expect and miss any subsequent output.