portable-pty 0.9.0 doesn't work on windows

[sigmaSd]

What Operating System(s) are you seeing this problem on?

Windows

Describe the bug

pty.read is returning garbage in windows starting with version 0.9.0

To Reproduce

I created a repo so you can see the issue easily https://github.com/sigmaSd/ptybug1

• pty 0.9.0 fails https://github.com/sigmaSd/ptybug1/actions/runs/13788144015
• pty 0.8.1 works https://github.com/sigmaSd/ptybug1/actions/runs/13788032694

[wez]

I think perhaps your program's expectations are not correct. The test program is way too large for me to dig into it, but the output you shared from the pty 0.9.0 case doesn't look like garbage. Windows ConPTY will emit various escape sequences on start up and your terminal emulation logic needs to be able to handle that.

You should keep in mind that wezterm uses this code in its nightly builds on Windows and that is working correctly.

There's not really enough information here for me to understand the expectation, the outcome and how it differs. Additionally, I do not use Windows very frequently at all any more, so it is rare that I have time to sit down and run code on Windows directly these days, so I'm unlikely to get time to more actively debug this issue.

[sigmaSd]

Thanks I don't have windows that's why I'm using GitHub ci, I'll try to minimize the reproduction and report back

[sigmaSd]

@wez I reduced the reproduction as much as possible now it have no dependencies and is just 100~= lines of straight forward code https://github.com/sigmaSd/ptybug1/blob/master/src/lib.rs

I still think there is an issue here

https://github.com/sigmaSd/ptybug1/actions/runs/15089400561/job/42415986052

IF you compare linux/macos/windows runs

you can see linux/macos reads deno output correctly

but windows output that sequence (which maybe not garbage but some control terminal stuff) but then doesnt output anything after it, changing the version to 0.8.1 make it work like the other 2 again

[wez]

The \u{1b}[6n escape sequence you see there is conpty asking your terminal implementation to report some data about the current cursor position. It sounds to me like you have a deadlock because you are not responding to that request.

https://github.com/search?q=repo%3Awezterm%2Fwezterm%20RequestActivePositionReport&type=code shows the code within wezterm that handles that sort of thing.

Why did this change? I think it may be due to 9d83458632640e662e3bac6d1d693e4a0cad6e2a which was part of https://github.com/wezterm/wezterm/pull/4982

Is it a bug? I don't think so. I think this is dependent on the program that is being run inside the terminal and what it is asking the terminal to do, perhaps indirectly, via the conpty layer in windows. If you run something other than deno you might see a different behavior.

[sigmaSd]

It does say so indeed

https://learn.microsoft.com/en-us/windows/console/createpseudoconsole

I don't grasp this fully yet but maybe this is because of the github action terminal, maybe it works on normal windows I'll have to try it

If its specifically a deno behavior that would be weird because it means that deno doesn't work in wezterm nightly I'll have to also test that

[sigmaSd]

I changed the code to not run deno and instead just run cmd /c cd and I still get the same issue https://github.com/sigmaSd/ptybug1/actions/runs/15093468910/job/42425059890

@Cammisuli do you have some feedback on this ? I saw your code here https://github.com/nrwl/nx/blob/202f14177833e021f86d646969fd2e2fee8dbb97/packages/nx/src/native/command.rs#L129-L217 and its basically the same I'm using in this reproduction

I think it would be great if this becomes an option instead

[sigmaSd]

I tested on an actual windows 10 machine with windows terminal and the same issue happen