Open kjpgit opened 1 year ago
Tagging subscribers to this area: @dotnet/area-system-console See info in area-owners.md if you want to be subscribed.
Author: | kjpgit |
---|---|
Assignees: | - |
Labels: | `area-System.Console`, `untriaged` |
Milestone: | - |
I think conflating tty mode setting with readkey was not a good design.
I agree, but how can we implement Console.ReadKey(interept: true)
without it?
I have a full-screen, interactive console app in C#, started by bash. There is a background thread constantly polling ReadKey(interept=True). Those key events, plus posix signal events, go into an input queue that is consumed by the main thread.
The main thread consumes a keypress event like 'enter' and knows it needs to launch a process like 'vim' and then exit (ideally it would just use execve, but that's another issue I opened). But vim needs to start with a 'clean' (i.e. echo mode) tty settings, because that's what it will restore to when it exits back to bash.
Right now, what's happening is when vim exits, bash is using no-echo mode, because that's how c#'s last state was. And that's annoying, not being able to see what you type 😀
I don't see a good way to force the .Net Console back to 'normal/echo' mode before calling Tmds.Libc.execve() or Mono.Posix Syscall.execve().
It seems the only controls on this are Read/ReadKey, but the user is done pressing keys at this point. There won't be any more.
I think conflating tty mode setting with readkey was not a good design. Those should be orthogonal settings. And even mono.unix doesn't seem to have an ioctl to override this.