bug: Don't try to handle SIGINT when prompting for passwords

[dwahler]

This PR disables the SIGINT handler in cliui.Prompt when the Secret option is set. This handler tries to run at the same time as the one installed by speakeasy.Ask, and if it wins the race condition, it causes the program to exit before speakeasy can correctly restore the terminal settings.

We keep the signal handler when prompting for non-password inputs so that we can print a newline and give the user a clean prompt after we exit.

Fixes #1378

[deansheather]

You could have methods for input and output file instead of a single method, which would make it Windows compatible. And then for the file descriptor just have another method for that as well (the windows.Handle is a file descriptor and can be cast to uintptr)

[kylecarbs]

It might be cleaner to expose the readWriter interface and add a File function to it! readWriter could be renamed to pipe, since that's pretty much what it's doing.

[deansheather]

It would be good to see a Windows test too, shouldn't be too hard to get the console mode:

var state uint32
err := windows.GetConsoleMode(handle, &state)
if err != nil {
	return err
}

[dwahler]

I spent way too much time today trying to get this test to run on Windows and wasn't successful, so unless someone else has the time or the deep knowledge of Win32 to make it work, I think we'll have to be satisfied with testing on Linux.

As far as I've been able to determine, the problem boils down to a core difference between Unix pty devices and Windows ConPTY. On Linux, the kernel creates "master" and "slave" pty devices as a pair, and they behave as though they're connected by a bidirectional pipe. The slave device is what keeps track of the local echo state, and although the simplest thing you would do with it is let a child process inherit it as its TTY, there's nothing stopping the parent process from also keeping a reference to it and monitoring its state.

But on Windows, there are at least three distinct sets of handles:

1. A pair of pipes created by the parent; the parent holds onto one end of each of these, and they play roughly the same role as a Unix "master" pty
2. A "pseudoconsole handle" which the parent passes as a parameter to CreateProcess, encapsulating the other ends of the pipes (corresponding to data read/written by the child)
3. A "console input buffer" and "console screen buffer" handle, which the child process receives as its stdio handles

Of these, 3 seems to be the only one that supports GetConsoleMode which allows you to query the echo status. (The pipes are just streams of bytes that happen to contain terminal escape codes, and the pseudoconsole handle is an opaque reference that isn't actually usable for I/O.) But there seems to be no good way for the parent to use 1 or 2 to get a reference to 3. The child's handles are created automatically at process creation time, without the parent ever being able to see them.

see also:

https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

microsoft/terminal#262 (comment)

It might be that testing this on Windows would require a totally different approach.

[kylecarbs]

@dwahler I went down a similar rabbit hole with ConPTY when creating the pty package. Even our PTYs on Windows in testing aren't real PTYs, because ConPTY requires attaching to a command.