hermes-admin/hermes-agent
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity

test(update): runtime unicode docstring matches the ProcessStartInfo UTF-8 capture

Browse Source 
Review R8 m7: after the merge with main's 732b63d61a the probe decodes launcher
stdout as UTF-8 through ProcessStartInfo.StandardOutputEncoding and never touches
[Console]::OutputEncoding, so the test docstrings no longer claim the call sites
scope and restore it. runtime.ps1 keeps a one-line #124526 pointer at the
encoding line. Behaviour and assertions are unchanged.
This commit is contained in:
Teknium
2026-10-04 15:40:21 -07:00
parent 4f8fb4b263
commit 3bb4e87775
2 changed files with 10 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
scripts/desktop-update/runtime.ps1
View File

@@ -24,6 +24,7 @@ function Invoke-HermesProbe {
$psi.RedirectStandardInput = $true
$psi.RedirectStandardOutput = $true
$psi.RedirectStandardError = $true
# Launchers print UTF-8; PowerShell 5.1 would decode with the OEM code page (#124526).
$psi.StandardOutputEncoding = [System.Text.Encoding]::UTF8
$process = [System.Diagnostics.Process]::Start($psi)
try { $process.StandardInput.Close() } catch {}

16
tests/scripts/desktop_update/test_desktop_update_runtime_unicode.py
View File

@@ -10,10 +10,12 @@ decodes captured native stdout with the console OEM code page, mojibaking the
path (``á`` → ``├í``, ``ł`` → ``┼é``) so the returned command cannot run and the
legacy identity check never matches.
Both call sites now scope ``[Console]::OutputEncoding`` to UTF-8 around the
capture and restore it. These tests drive the REAL script against a REAL
published launcher under non-ASCII paths, across three console code pages, and
assert the caller's encoding is restored. They never read the script's text.
Both captures go through ``Invoke-HermesProbe``, which decodes the child's
stdout as UTF-8 via ``ProcessStartInfo.StandardOutputEncoding`` and never
touches ``[Console]::OutputEncoding``. These tests drive the REAL script against
a REAL published launcher under non-ASCII paths, across three console code
pages, and assert the caller's console encoding is left unchanged. They never
read the script's text.
"""
from __future__ import annotations
@@ -79,8 +81,8 @@ def test_runtime_command_survives_a_non_ascii_profile_path(tmp_path: Path, code_
The launcher JSON is ASCII-escaped today, so this is the round-trip
contract for the boundary every other consumer (hermes_cli.windows_ssh_
runtime, the Electron updater, the Rust bootstrap) already decodes as
UTF-8: the scoped capture must return the path byte-exact and restore
the caller's console encoding, whatever code page the console carries.
UTF-8: the capture must return the path byte-exact and leave the caller's
console encoding unchanged, whatever code page the console carries.
"""
profile = tmp_path / PROFILE
install = profile / 'hermes-agent'
@@ -104,7 +106,7 @@ def test_runtime_command_survives_a_non_ascii_profile_path(tmp_path: Path, code_
lines = _run_helper(script, home, {'HERMES_RUNTIME_DIR': str(store)}, tmp_path / 'answer.txt')
assert lines[0] == str(python), (
f"interpreter path was mojibaked under code page {code_page}: {lines[0]!r}")
assert int(lines[1]) == code_page, 'the capture must restore the caller console encoding'
assert int(lines[1]) == code_page, 'the capture must leave the caller console encoding unchanged'
@pytest.mark.platforms('windows')