fix: capture raw output in the synchronous command path [patch]

[matt-edmondson]

Fixes #23

The problem

NativeCommandExecutor has two capture paths that disagreed about the bytes of the child's output.

ExecuteAsync reads the redirected streams raw, preserving exactly what the child wrote. The synchronous primitive captured line by line through OutputDataReceived/ErrorDataReceived and reassembled with StringBuilder.AppendLine, which appends Environment.NewLine after every line — including the last — after the Process line splitter has already discarded the child's own terminators.

On Linux, printf 'a\r\nb':

call	StandardOutput
ExecuteAsync(cmd).Result	"a\r\nb"
Execute(cmd)	"a\nb\n"

ICommandExecutor documents the synchronous overload as the primitive "every other synchronous member composes over", which implies it agrees with the asynchronous path. Callers that compare output exactly, hash it, or parse output that is not line-oriented silently got different data depending on which overload they used, and ExecuteAndGetOutput is affected too since it composes over the same primitive.

The fix

Each redirected stream is now read to the end by its own dedicated thread (StreamDrain), and the captured text is returned unmodified.

This keeps both properties the callback approach was chosen for:

• No deadlock — neither stream can fill its buffer while the other is being read, which is what reading one to the end on the calling thread would cause.
• No pool thread held — a dedicated thread rather than a pooled one, which is the cost the synchronous primitive exists to avoid (ICommandExecutor.Execute blocks on .Result, so sync callers see AggregateException #17). The calling thread also stays free to keep polling the cancellation token, so a silent child no longer blocks cancellation.

On the cancelled path the drains are abandoned rather than waited for, but are given a bounded join so they stop touching the streams before the process is disposed.

Test

CommandExecutor_Sync_Captures_The_Same_Bytes_As_Async asserts both paths return exactly what the child wrote, for a command whose output ends without a terminator and (on POSIX) embeds a \r\n foreign to the platform, so a path that normalizes terminators cannot pass by coincidence. No existing assertion could observe this — they all compare with Trim().Contains(...).

Verified by reverting the fix and re-running:

failed CommandExecutor_Sync_Captures_The_Same_Bytes_As_Async
  expected: "a\r\nb"
  actual:   "a\nb\n"

Full suite with the fix applied: 890 passed, 0 failed. Release build of the provider across all six target frameworks (net10.0 → netstandard2.1): 0 warnings, 0 errors.

CLAUDE.md is updated, since it described the now-removed BeginOutputReadLine mechanism.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R28xwrsRuiwGs84jahEDh3

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud