Skip to content

End output lines only at CR, LF and CRLF [patch] - #136

Merged
matt-edmondson merged 1 commit into
mainfrom
fix/133-line-breaks-cr-lf-only
Nov 4, 2026
Merged

matt-edmondson merged 1 commit into
mainfrom
fix/133-line-breaks-cr-lf-only

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #133

What changed

LineOutputHandler.IsLineBreak also ended a line at NEL (U+0085), LS (U+2028), PS (U+2029) and form feed. That set came from the old ReplaceLineEndings code. JSON.stringify, jq -c and json.dumps(ensure_ascii=False) emit LS and PS raw inside strings, so NDJSON records were cut in half, and Latin-1 output was split at every 0x85 byte.

Lines now end only at LF, CR and CRLF, which is how Process.OutputDataReceived and StreamReader.ReadLine split them. The CR handling is unchanged: split CRLF across reads and a held-back trailing CR (#85, #128) work as before.

Behaviour change: a caller that relied on FF or NEL splitting now gets those characters inside the line. The commit message records this so it reaches the generated changelog. The README's LineOutputHandler section now says which characters end a line.

Tests

  • HandleStandardOutputDataShouldKeepAnUnusualSeparatorInsideTheLine: covers each of LS, PS, NEL and FF inside a JSON record and checks that two records arrive as two lines.
  • HandleStandardErrorDataShouldKeepAnUnusualSeparatorOnAChunkBoundaryInsideTheLine: puts the same characters at the end of a chunk, on the error stream.
  • All 8 new cases fail with the fix reverted and pass with it.
  • Full suite on net10.0 (Linux): 72 passed, 2 skipped (the elevation tests), 0 failed.

Ordering note

The triage notes that open #132 and #129 rewrite the same handler. This change touches only IsLineBreak and its doc comment, so a rebase in either direction should be trivial.


Generated by Claude Code

LineOutputHandler also split on NEL (U+0085), LS (U+2028), PS (U+2029) and
form feed, a set carried over from the old ReplaceLineEndings code. Tools
emit LS and PS raw inside JSON strings, so NDJSON records were cut in half,
and Latin-1 output split at every 0x85 byte. Lines now end where
Process.OutputDataReceived and StreamReader.ReadLine end them.

Behaviour change: a caller that relied on FF or NEL splitting now gets
those characters inside the line.

Fixes #133

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW5RAKCxdwrsVmygQDP
@sonarqubecloud

sonarqubecloud Bot commented Nov 3, 2026

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit be28dab into main Nov 4, 2026
15 checks passed
@matt-edmondson
matt-edmondson deleted the fix/133-line-breaks-cr-lf-only branch November 4, 2026 00:57
matt-edmondson pushed a commit that referenced this pull request Nov 4, 2026
Resolves the conflict in LineOutputHandler.cs: keeps this branch's
immediate CR delivery with its per-stream skip-leading-LF state, and takes
main's CreateRunHandler (#132), its class remarks, and its narrowing of
IsLineBreak to LF only (#136).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW24pNCmCLDhz6z3ZdY
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Line handler splits output on U+2028, U+2029, NEL (U+0085) and form feed, breaking NDJSON records that OutputDataReceived/ReadLine keep whole

2 participants