-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another attempt of support pty on windows with ConPTY api #155
base: master
Are you sure you want to change the base?
Conversation
This looks very promising, I will try it out to see if it works in our system |
I just tried this out, and works perfectly for my use case (an SSH server that must work on UNIX and Windows) 👍 |
Trying this now. Would be really nice if this works on go 1.18 too :) considering repo is still pointing to 1.13 :D |
It worked on Go 1.18 for me |
It just passed our ci too. Worked like a charm too :)
…On Thu, Jul 28, 2022, 7:49 PM Pete Woods ***@***.***> wrote:
It worked on Go 1.18 for me
—
Reply to this email directly, view it on GitHub
<#155 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTREGNBTBOT5HCXFTO3ATVWK23LANCNFSM54T43GUQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@creack if you have time to look at this, it would be most appreciated, I found the API break to be extremely unintrusive (in that I didn't need to change any code) |
I’ll take a look over the weekend. Quite a few tickets in backlog, sorry
about that.
On Thu, Jul 28, 2022 at 10:51 AM Pete Woods ***@***.***> wrote:
@CrEaK <https://github.com/CrEaK> if you have time to look at this, it
would be most appreciated, I found the API break to be extremely
unintrusive (in that I didn't need to change any code)
—
Reply to this email directly, view it on GitHub
<#155 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD7LZMFPY36MECEUL42SDDVWK3CBANCNFSM54T43GUQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
--
Guillaume J. Charmes
|
Worked for me on 1.18 and 1.17.1, thanks @photostorm 👏👏👏 |
@creack Is there anything we can do to help with this PR getting reviewed? Windows support is a really big deal for a bunch of users of your library. |
I'm happy this PR exists. However, it introduces a breaking change: |
FWIW I agree there should be a high bar to justify incompatible changes to the interface. It's not immediately clear to me why that would be necessary to add Windows support. |
There should be high bar to justify incompatible changes to the interface. Due to the return type of Start, I do not see a way to pass the handles. I think this API change would make it possible for other systems in future to be added. |
Would it be possible to use a Unix socket on Windows instead of a pair of pipes? Each end of a socket is full-duplex, which might mean the exported interface can be a single os.File object. https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ |
ok, I will look into it. Thanks for your feedback. @kr |
@kr I do not think I can used that. there is window handle that I need access to also. |
Ultimately we will have to defer to @creack, it's his library. My feeling is, it might be worth breaking the API, if that's absolutely necessary to support Windows. Even in that case, I think any new interface should undergo careful design review (which I could participate in). But we haven't exhausted all the strategies to maintain compatibility. For instance, maybe the window handle could be stored on the side in a global lookup table, and the *os.File pointer or a file descriptor or something could be used to look up the window handle when it's needed. var (
windowHandles = map[*os.File]windows.Handle{}
windowHandlesMu sync.Mutex
) Choosing a suitable value to use as the map key could be tricky. The fd might not work if the client code calls dup or something. I don't have great knowledge of the Windows API and its semantics so I don't know offhand if there's a good value to use. Is there a stable way to identify a pty in Windows? Maybe something available via os.FileInfo.Sys? Also, this would probably need to use a finalizer to delete map entries. What do you think? |
That seems like a plausible strategy to me, but without input from @creack I don't thing we can realistically progress |
@creack have you gotten the chance to review this PR? My team could definitely use this. At the moment we are relying on @photostorm's fork (which has worked perfectly so far) |
Don't close consoleR & consoleW in Windows
Thankyou for continuing to plug away at this |
I don't mean to disrupt the discussion about this PR, but perhaps you could take a look at aiopty/pty/conpty/conpty_windows.go and aiopty/term/term_windows.go. |
thank you all very much for implementation tty on windows! |
Sorry for the delay, I have been swamped recently, I'll take a look as soon as I can. |
Great news! 👍 |
Getting an error when running the tests (go1.22.3)
|
When commenting out the SetDeadline section which cause the build to fail, I get test errors:
Running the tests as Administrator yields the same result, including Access is denied. |
I still working on fixing invalid handle with get size, but just been busy with work. |
Any update on this ? |
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
Adds Windows to the test matrix. We'll see what breaks. For creack/pty, we need to use the currently-unmerged change in `creack/pty#155` for Windows support.
This adds support for using git-spice with Windows. I'm pretty sure it already works, but testing it is a bit difficult, especially since I don't have a Windows system to test on. All terminal prompt use creack/pty to create a fake terminal. Until creack/pty#155 is merged, these tests cannot be run on Windows. We'll skip the prompt tests on Windows for the time being.
This is why I am here too 😢 Any updates? It seems without this, LazyGit cannot allow using a custom pager like delta for git diffing things. Would be super useful. Thanks so much for everyone's work on this! |
Hope is still high for this PR |
I am still here. Just been busy with my work. I hope to get back to soon. If any one can help me with looking into invalid handle problem that would be great. |
it works fine for , thanks. @photostorm |
Running the tests yield somme failures, cf my last message. @photostorm mentioned he still needs some work on this. |
compared with *nix, I find main issue is its performace is too poor under window |
Could you please add more details? |
https://github.com/wellcomez/lspvi/releases/tag/v100test my project
|
This is an another attempt to support pseudo-terminal on windows using ConPty API (should resolve issue #95)
This pull request does introduce major api change for Start method (*os.File -> Pty),
I have tested this code with remote terminal application that I wrote. It would be great to get some additional testing with other use cases.