Repository navigation
Fix #5 #6 #7 #8: UTF-8 corruption, flush, cmd.exe mangling, redirected-stdio - #12
Merged
Merged
Conversation
…ng, redirected-stdio Issue #5 - Cast recordings corrupt multi-byte UTF-8 at 4096-byte boundaries: CastWriter now uses persistent Decoder instances (separate for output and input streams) that carry incomplete multi-byte sequences across chunk reads, producing complete characters instead of U+FFFD. System test records 60000 multi-byte characters (180KB burst) and asserts zero U+FFFD in the cast. Unit test verifies the PowerShell converter (ConvertTo-BsnAsciicast) handles chunked multi-byte data through timing-file boundaries. Issue #6 - Cast file loses header/tail on abnormal termination: CastWriter now uses StreamWriter.AutoFlush = true, so every line (header + events) goes to disk immediately. An abnormally terminated recording stays a valid asciicast file ending at the last completed event instead of losing everything to the character buffer. Issue #7 - -Command values with pipes/quotes mangled by cmd.exe: Get-BsnRecordingCommandLine now wraps -Command in pwsh -EncodedCommand (Base64 UTF-16LE) instead of cmd.exe /d /c. This preserves the exact command text bit-for-bit through the CreateProcess command line - no shell metacharacter interpretation. Unit tests verify Base64 round-trip for pipes, quotes, angle brackets, and carets. Issue #8 - Empty cast but success report when stdio is redirected: Test-BsnRecordingEnvironment now throws a terminating error when BOTH stdin and stdout are redirected on Windows (the recording is provably empty in this shape). Partial redirect (one handle) remains a warning. This prevents silent useless recordings from CI/scripted hosts. All 78 tests green on PS 7 and PS 5.1.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
This was
linked to
issues
Nov 6, 2026
soroshsabz
commented
Nov 6, 2026
- Renamed Issue5to8.Tests.ps1 to RecordingIntegrity.Tests.ps1 - Added comprehensive file header describing each issue with hyperlinks - Added issue hyperlinks in every Describe block and the system test - Added inline comment explaining the cmd.exe -> EncodedCommand change (issue #7 fix: cmd.exe /d /c mangled metacharacters)
Removed RecordingIntegrity.Tests.ps1 (catch-all file); the tests now live alongside the existing tests for the same functions: - Issue #7 (command encoding) + #8 (redirected stdio) tests moved to Start-InteractiveTranscript.Tests.ps1 (tests the public cmdlet's environment checks and command line construction) - Issue #5 (UTF-8 chunk boundaries) + #6 (incremental flush) tests moved to ConvertTo-BsnAsciicast.Tests.ps1 (tests the converter's decoding and output behavior) Each test block has the issue hyperlink inline.
Member
Author
…TUI (Linux) oh-my-posh test (Windows): renders 20 prompts via 'oh-my-posh print primary', producing powerline/nerd-font glyphs (3-4 byte UTF-8 in the Supplementary Private Use Area). Each prompt is 200-600 bytes; 20 prompts guarantee chunk-boundary splits mid-glyph. Asserts zero U+FFFD. vim TUI test (Linux): opens a file with UTF-8 content, box-drawing characters, and plain text in vim (alternate screen buffer, syntax highlighting, status line). Asserts alt-screen sequences present, content captured, multi-byte content survived, zero U+FFFD. Both skip gracefully when the tool is unavailable. CI installs oh-my-posh on Windows runners via winget. These tests provide real-world validation for the issue #5 fix (persistent UTF-8 Decoder in CastWriter) beyond the synthetic U+2580 blocks: actual application-generated glyphs are proven to survive recording without corruption.
|
This was referenced Nov 6, 2026
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
Fixes some bugs in first real testing
This PR
Issue #5: Cast recordings corrupt multi-byte UTF-8 at 4096-byte boundaries
Root cause: CastWriter.WriteEvent() decoded each 4096-byte chunk independently with Encoding.UTF8.GetString(), replacing truncated multi-byte sequences with U+FFFD.
Fix: Persistent Decoder instances (separate for output/input streams) that carry incomplete sequences across chunk reads. The character that spans a boundary appears at the start of the next event instead of being corrupted.
Tests:
Issue #6: Cast file loses header/tail on abnormal termination
Root cause: StreamWriter buffers ~1KB; nothing reaches disk until Dispose() runs (which never happens on crash).
Fix: AutoFlush = true — every line (header + events) goes to disk immediately.
Issue #7: -Command values with pipes/quotes mangled by cmd.exe
Root cause: cmd.exe /d /c "{command}" strips quotes and interprets |&<>^ as shell metacharacters.
Fix: Get-BsnRecordingCommandLine now wraps -Command in pwsh -NoProfile -EncodedCommand — the exact command text is preserved bit-for-bit, no shell interpretation.
Tests: Base64 round-trip verification for pipes, embedded quotes, angle brackets, carets.
Issue #8: Empty cast but success report when stdio is redirected
Root cause: Windows routes child output around the ConPTY when the caller has pipe stdio; the engine captures nothing but returns success.
Fix: Test-BsnRecordingEnvironment now throws a terminating error when both stdin and stdout are redirected on Windows. Partial redirect (one handle) remains a warning.
Validation