fix(coverage): write hit records straight to disk instead of buffering them by Chemaclass · Pull Request #1103 · TypedDevs/bashunit

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass · 2026-08-13T07:58:52Z

🤔 Background

Related #1101

The trap engine collected hits into a shell variable and flushed every 100
records. A variable dies with the subshell that filled it, so anything recorded
inside a $( ) was lost unless that subshell happened to fill the buffer
first.

On Bash 5 a run reported 196 of 236 real hits, deterministically, while
Bash 3.2 lost none — the same project measured differently depending on the
Bash running it. The missing lines were ordinary code called inside command
substitutions.

💡 Changes

Records are appended as they happen; the buffer and its bookkeeping are gone
Faster too, since growing a shell string was not cheaper than an append: 8896 ms → 5898 ms on Bash 3.2, 4612 ms → 3988 ms on Bash 5 (hits 196 → 236)
Sequential and parallel runs now report the same total, and a one-line append interleaves better between workers than a multi-kilobyte flush
New tests record inside ( ) and $( ) and assert the record reached disk — all three fail against the buffered engine
The Spying on printf breaks coverage collection #724 guard (a spied printf must not shadow the write) moved with the write into record_line, and its test with it

…g them The trap engine collected hits into a shell variable and wrote them out every 100 records. A variable dies with the subshell that filled it, so anything recorded inside a $( ) was lost unless that subshell happened to fill the buffer first. On Bash 5 a run of tests/unit/assert/basic_test.sh reported 196 of 236 real hits -- deterministically -- while Bash 3.2 lost none, so the same project measured differently depending on the Bash running it. The missing lines were ordinary code: bashunit::temp_dir and friends, called inside command substitutions. Appending each record is also faster than growing the string was: 8896ms to 5898ms on Bash 3.2, 4612ms to 3988ms on Bash 5, where hits go 196 to 236. A one-line append also interleaves better between parallel workers than a multi-kilobyte flush; sequential and parallel runs now report the same total. flush_buffer keeps its name and its callers -- it means "publish what I recorded", and now only drops the stale aggregation. The #724 guard against a spied printf moved with the write into record_line, and its test with it. Closes#1101

Three tests encoded the old behaviour as a documented limitation -- a hit recorded inside ( ), <( ) or a function called from $( ) never reached the data file, so they asserted the lower count. Those lines are recorded now: 1 to 2, 3 to 4, and 2 to 4. They are skipped on Bash 3.2, which is why the local runs stayed green and CI caught them on Linux.

They were skipped on macOS with a comment saying the DEBUG trap reaches subshells on Linux for every supported Bash. The Bash 3.0 job disproves that: the counts there are the pre-#1101 ones, because before Bash 4 the trap does not reach a subshell even under set -T, so nothing is recorded to keep. Skipping on BASH_VERSINFO < 4 states the real condition and covers both the macOS system Bash and the Bash 3.0 job.

… still does The engine section documented the buffer as a known difference -- the trap engine losing hits recorded inside a command substitution while xtrace kept them. Records are written as they happen now (#1101), so that difference is gone. What remains is the shell: before Bash 4 the DEBUG trap does not reach a subshell even under set -T, so the same project can report a slightly lower percentage on Bash 3.x. Worth saying out loud, since nothing in the output hints at it. The performance note claimed capture and reporting cost about the same. After this series the report phase is a few awk passes for the whole run and capture is the dominant half.

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Chemaclass added the bug Something isn't working label Aug 13, 2026

Chemaclass self-assigned this Aug 13, 2026

Chemaclass added 3 commits August 13, 2026 10:08

Chemaclass merged commit 7760d48 into mainAug 13, 2026
37 checks passed

Chemaclass deleted the fix/1101-drop-coverage-buffer branch August 13, 2026 08:33

Uh oh!

Uh oh!

Conversation

Chemaclass commented Aug 13, 2026

🤔 Background

💡 Changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

Chemaclass commented Aug 13, 2026

🤔 Background

💡 Changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

Chemaclass commented Aug 13, 2026

🤔 Background

💡 Changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

Chemaclass commented Aug 13, 2026

🤔 Background

💡 Changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

Chemaclass commented Aug 13, 2026

🤔 Background

💡 Changes

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant