1.0 bug fixes

[jasonkarns]

(transferring bugs list from sstephenson/bats#196)

• Empty output lines are missing from ${lines[@]}.
  IFS broken after first run sstephenson/bats#89
  saving $IFS in run() not altered for code using it - fix #89 sstephenson/bats#90
  Revert "saving $IFS in run() not altered for code using it" sstephenson/bats#92

  saving $IFS in run() not altered for code using it - fix #89 sstephenson/bats#90 has already been merged to master

• Use POSIX compliant options with head for better compatibility (e.g. Busybox support).
  Avoid undocumented usage of the head utility. sstephenson/bats#163

  closed by Transfer bats#163 - Avoid undocumented usage of the head utility. #17

• Incorrect TAP format for skipped tests.
  format of TAP output for skipped tests is incorrect sstephenson/bats#141
  This commit corrects the problem of incorrect TAP format for skipped tests. sstephenson/bats#142

  will be closed by Transfer bats#142 - This commit corrects the problem of incorrect TAP format for skipped tests #19

• set -o nounset breaks bats-exec-test.
  Support for "unofficial strict mode"? sstephenson/bats#171

• bats-preprocess breaks when translating a @test line that uses tabs for white space, instead of plain spaces.
  @test: command not found if tab is used after test name sstephenson/bats#98
  Fixed issue #98 sstephenson/bats#122

• Bats failing on OS X 10.11.2.
  let: count+=: Syntax Error on OS X 10.11.2 sstephenson/bats#140

[mbland]

Corresponding to each of the above:

• Actually, empty output lines are still missing from lines. I've got a split_bats_output_into_lines helper (and its __split_bats_output_into_lines helper for speed reasons) that would be trivial to apply—but it would be a breaking change for a lot of tests. I'd vote for that to go into v1.0, with a corresponding bats_strip_blank_lines helper or other mechanism to help people migrate from the old behavior to the new.

• I've noticed test breakages on Alpine, which I believe would fall into the Busybox compatibility bucket, although Transfer bats#163 - Avoid undocumented usage of the head utility. #17 did resolve the one issue. I'll try taking a look at them momentarily.

• I'll be reviewing Transfer bats#142 - This commit corrects the problem of incorrect TAP format for skipped tests #19 shortly.

• Haven't looked at the set -o nounset issue closely yet. Some definite subtleties there.

• The whitespace solution from Fixed issue #98 sstephenson/bats#122 should now apply to the definition of BATS_TEST_PATTERN in libexec/bats, but otherwise should just work.

• I'm pretty sure let: count+=: Syntax Error on OS X 10.11.2 sstephenson/bats#140 was fixed by f5acd28 from Fix macOS/Bash 3.2 breakage; eliminate subshells from exec-test, preprocess #8. I'm also pretty sure the issue was the one identified by @mstade in let: count+=: Syntax Error on OS X 10.11.2 sstephenson/bats#140 (comment), whereby set -e is in effect, and an error causes $(bats-exec-test -c "$filename") to evaluate to the empty string, resulting in the syntax error. The new code isn't susceptible to this.

[mbland]

Update on the Alpine/Busybox business: Per #16, the failures I saw were due to ncurses not being installed and tput being missing, not due to any further Busybox compatibility issues.

[mbland]

Just opened #23 to address the bats-preprocess tabs issue.

[mbland]

#26 addresses the set -o nounset issue.

[mbland]

#23 addresses the bats-preprocess breaks on tabs in @test lines issue.

So the last one is empty output lines missing from ${lines[@]}. @jasonkarns I'm happy to start tackling this one (later this week/weekend, most likely), but I'm wondering if we'd consider this a new "feature" at this point, to be postponed. Of the six issues listed in this thread, the other five clearly were bugs, but this last one is debatable.

[jasonkarns]

I sorta agree. And depending on the solution would be most likely to introduce a breaking change... I'd like to see about tagging some releases with the bugs that have already been released and see if we're good to tag it 1.0!

[mbland]

@jasonkarns @btamayo How and when do y'all want to proceed? Should we ship what we've got? Do we want to get #9 in first? I'll have a little bandwidth this weekend to help keep 'er movin'.

[btamayo]

@mbland @jasonkarns Sorry, work has kept me very busy, but bandwidth has opened up again. Phew.

I'm glad the project's buzzing! Just quickly scanned through this last issue and I think that backwards-compat for this release is top priority, and anything that will likely break that should be pushed. That way when people migrate from the fork point to this repo (0.4 to 1.0), it will be a seamless (theoretically) transition with no breaking behaviors.

If we lean towards this idea for 1.0, we can more easily zap bugs introduced between sstephenson/bats@0.4 and bats-core/bats-core@1.0 (including gathering reports and test cases). It makes the transition easier for users as well and makes the demarcation more clear.

Also it gives us a handy way to test out distributing the new package and announcing changes/deprecations for the next major version!

So yep, happy to ship what we got. :)

[mbland]

Per my comment in #16, we're set to release v1.0.0 soon without the empty lines in ${lines[@]}. Closing.