terminal::tests::open_pty_shell_spawns_a_real_shell_and_round_trips_a_command fails on Windows, and I could not work out why. Filing it with what is known rather than leaving it as an unexplained red test.
Visible only now that the library test binary can start on Windows — see #98.
What happens
src/terminal.rs:269
expected echoed output, got: ""
The test spawns the platform's default shell through the PTY, writes echo hello_gitcat_terminal\n, and waits for that string to come back on the master side. On Windows nothing at all arrives — not the echoed command, not the shell's own banner, not a prompt. collected is empty, so the reader thread never delivered a single byte before the timeout.
What has been ruled out
- Not slowness. Raising the wait from 5s to 20s changes nothing; the read produces nothing rather than arriving late.
- Not the harness. Every other test in the same binary passes (255 of 256). The failure is specific to this one.
- Not
#98's delay-load. The test never calls into comctl32, and the same failure appears whichever way the binary is linked.
What has not been tried
- Sending
\r or \r\n instead of \n. cmd.exe submits a line on CR, and ConPTY's input translation is not obviously the same as a unix pty's — but an unsubmitted command would still leave the shell's banner in the buffer, and there is no banner either, so this alone does not explain an empty read.
- Reading the master side before writing anything, to see whether the PTY produces output at all on this platform.
- Whether the app's built-in terminal drawer actually works on Windows. If it does, the difference between it and this test is the interesting part; if it does not, this test is reporting a real bug rather than a test-environment problem.
That last one is the question worth answering first — it decides whether this is a test to fix or a feature to fix.
Note
open_pty_shell's other test (..._refuses_a_dubious_ownership_path_before_ever_touching_a_pty) passes on Windows, so the trust gate and the error path are fine; this is specifically about reading PTY output.
Found while making cargo test runnable on Windows (#98). Windows 11 / MSVC 14.50; cargo test -j 2 --lib.
terminal::tests::open_pty_shell_spawns_a_real_shell_and_round_trips_a_commandfails on Windows, and I could not work out why. Filing it with what is known rather than leaving it as an unexplained red test.Visible only now that the library test binary can start on Windows — see #98.
What happens
src/terminal.rs:269The test spawns the platform's default shell through the PTY, writes
echo hello_gitcat_terminal\n, and waits for that string to come back on the master side. On Windows nothing at all arrives — not the echoed command, not the shell's own banner, not a prompt.collectedis empty, so the reader thread never delivered a single byte before the timeout.What has been ruled out
#98's delay-load. The test never calls into comctl32, and the same failure appears whichever way the binary is linked.What has not been tried
\ror\r\ninstead of\n. cmd.exe submits a line on CR, and ConPTY's input translation is not obviously the same as a unix pty's — but an unsubmitted command would still leave the shell's banner in the buffer, and there is no banner either, so this alone does not explain an empty read.That last one is the question worth answering first — it decides whether this is a test to fix or a feature to fix.
Note
open_pty_shell's other test (..._refuses_a_dubious_ownership_path_before_ever_touching_a_pty) passes on Windows, so the trust gate and the error path are fine; this is specifically about reading PTY output.Found while making
cargo testrunnable on Windows (#98). Windows 11 / MSVC 14.50;cargo test -j 2 --lib.