Repository navigation
Fix #5 (live view + playback): UTF-8 console output codepage management (Bsn.Host 0.2.3) - #18
Merged
Merged
Conversation
Field regression from v0.2.2: the CAST is clean (every capture test passes), but the LIVE view - what the user watches while recording - still turns box-drawing text into CP437 mojibake on OEM-codepage consoles (cmd, Windows PowerShell 5.1 hosts, fresh hidden consoles). Reported with OpenCode after installing 0.2.2 from the gallery. Root cause: PtyRecorder proxies the ConPTY stream to the real console as raw UTF-8 bytes (WriteFile on the console handle). The console decodes those bytes with its own OUTPUT codepage; at the OEM codepage the UTF-8 box borders (E2 94 80 ...) render as 'Gamma-ohmega-acute'. The recorder never re-encodes, so no cast-side fix can help: the outer console is the decoder. Fix: the engine saves the console output codepage, switches it to UTF-8 (65001) for the duration of the recording - the proxied stream is UTF-8, matching the cast - and restores the original value in finally, alongside the existing console-input-mode restore. Consoles already at 65001 (pwsh 7 hosts) are untouched. Test: new Windows system test reproduces the exact topology end to end. conlog wraps a runner whose console sits at the OEM codepage while a byte-writing child records; the conlog capture IS the live view the user would see. Verified locally against a pre-fix build (test red: corner count 0, mojibake soup) and the fixed build (green: glyphs byte-for-byte, console codepage restored to 437). Runs on CI whenever the console-logger build step succeeds; skips gracefully otherwise. Also adds the redirected-stdio skip guard the existing console-logger cross-check was missing (conlog cannot run when its own stdin is redirected). Bsn.Host 0.2.3 (C# engine + docs + version stamp); Bsn.Common and Bsn.SystemManagement are unchanged.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
…w-InteractiveTranscript Second half of the viewer bug: the recorded cast is lossless UTF-8, but Show-InteractiveTranscript in Windows PowerShell 5.1 (.NET Framework) writes [Console] output through the console OUTPUT CODEPAGE (WriteFile), so heavy box-drawing characters that do not exist in CP437 - OpenCode's U+2503 border and U+2579 corner - degraded to literal '?' in the viewer while ASCII and CP437 blocks (the logo, the text) survived. pwsh 7 uses WriteConsoleW and was never affected, which is why the pwsh-only tests did not catch it. Show-InteractiveTranscript now saves the console output encoding, switches it to UTF-8 for the playback, and restores the original afterwards (same save/switch/restore discipline the recording engine uses for the live proxy view). Consoles already at UTF-8 are untouched; hosts that refuse the switch fall back to the previous behavior via a guarded setter. Tests: - Unit: playback restores the console output encoding it found. - Unit (discriminating): a child pwsh with redirected stdout encodes [Console]::Write through [Console]::OutputEncoding - the same lossy path as an interactive 5.1 host. With a cast containing U+2503/U+2579 and the console forced to CP437, the output must contain the UTF-8 characters and no '?' (red on the unfixed cmdlet, green with the fix). - System (end to end): a real recording played back through powershell.exe 5.1 inside a conlog pseudoconsole at the OEM codepage - corners, borders and markers must render with zero rendered '?', and the console codepage must be restored (red unfixed, green fixed). - Also adds the redirected-stdio skip guard the console-logger cross-check test was missing (conlog cannot run when its own stdin is redirected).
soroshsabz
changed the title
…tionally so the lossless-playback test runs on Linux/macOS CI (both failed with NotSupportedException there).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ITNOA
What you hit
After installing 0.2.2 from the gallery, OpenCode recordings rendered
box-drawing borders as CP437 soup in two places:
(
Gamma-ohmega-acuteeverywhere).Show-InteractiveTranscriptstill showed acolumn of blue
?where OpenCode draws its blue left border - whilethe logo, the text and the blocks rendered fine.
Root causes (two different layers, both fixed)
1. Live view (
PtyRecorder): the ConPTY proxy writes the stream tothe real console as raw UTF-8 bytes, and the console decodes those
bytes with its own output codepage (OEM 437 in cmd / Windows PowerShell
5.1 hosts / fresh hidden consoles). The engine now saves the console
output codepage, switches it to UTF-8 (65001) for the duration of the
recording, and restores the original in
finally.2. Playback (
Show-InteractiveTranscript): the recorded cast islossless UTF-8 (every capture test passed - the borders are
U+2503heavy vertical in the cast), but Windows PowerShell 5.1 (.NET Framework)
writes
[Console]output through the console output codepage(
WriteFile), so characters that do not exist in CP437 (the heavyborder
U+2503, cornerU+2579, cornersU+256D...) became literal?while ASCII and CP437 blocks (U+2580/U+2584/U+2588- thelogo) survived. pwsh 7 uses
WriteConsoleWand was never affected -which is why the pwsh-only tests could not catch it. The playback now
switches the console output encoding to UTF-8 for its duration and
restores it afterwards.
A char-level analysis of a real recorded OpenCode cast drove the
diagnosis: every character that rendered in the broken screenshot is in
CP437; every character that became
?is not.What ships (Bsn.Host 0.2.3)
PtyRecorder: save console output codepage -> 65001 during recording -> restore infinallyShow-InteractiveTranscript: save[Console]::OutputEncoding-> UTF-8 during playback -> restore infinally(guarded; falls back gracefully on hosts that refuse)powershell.exe 5.1inside a conlog pseudoconsole at OEM 437; corners/borders/markers must render with zero rendered?, codepage restoredVerified locally
soup); fixed build -> GREEN.
┃degraded to?,corner count 0); fixed cmdlet -> GREEN.
system tests running (not skipped).
Please verify on your machine
from the same console that showed the mojibake and the
?column.