run with options overwrites the value of i

[kolyshkin]

Describe the bug

The value of a variable i gets overwritten if run uses any flags.

To Reproduce
Steps to reproduce the behavior:

1. Create the file a.bats:

bats_require_minimum_version 1.5.0

@test i {
  for ((i=0; i<3; i++)) {
    echo before $i
    run ! false
    echo after $i
  }
}

2. Run it:

bats --show-output-of-passing-tests a.bats

3. See what happens:

   before 0
   after 2

Expected behavior

I have expected the following output:

   before 0
   after 0
   before 1
   after 1
   before 2
   after 2

Environment (please complete the following information):

• Bats Version: 1.9.0
• OS: Linux
• Bash version: 5.2.15

Additional context
A variable i is not declared as local in a few functions in common.bash.

[kolyshkin]

Should be fixed by #727 (tested locally).

[kolyshkin]

I was thinking about how to detect such thing (adding/replacing variables) in general, and wrote this:

@test varcheck {
	# collect variables
	before="$(declare -p)"
	
	# run some commands
	run true
	run ! false
	run -0 echo foo

	# check
	diff -u <(echo "$before" | grep -vE ' BATS_') <(declare -p | grep -vE ' before=|lines=|output=|status=| BATS_')
}

In my setup, it changes the value of SHELLOPTS and BASH_REMATCH, which is probably ok.

[martin-schulze-vireso]

There is something similar in https://github.com/bats-core/bats-core/blob/3e30d37383db7e527f57d02101d84a4ffa9c30a2/test/bats.bats#LL1216 for the debug trap. With run and other bats internals like run it becomes harder to capture all options.

I'd hoped for shellcheck to catch this sort of problem, but there is koalaman/shellcheck#468

[debarshiray]

I spent the better part of a few days banging on the wall over this. In my case run --separate-stderr was always setting i to 1. That made my for loop run, which had a limit of 5 infinitely, and gave the impression that the test case was stuck.

This happened while I was cleaning up various rough edges in my test suite, and I kept thinking that I made a mistake somewhere until I took a close look at the value of the loop counter (ie., i). A bit of head scratching and some Git forensics brought me here. :)

Thanks!