Survey.Ask always fails under git bash (Mingw64)

[rfay]

Survey.Ask() consistently returns "Incorrect function" when used under the (very common) git bash for WIndows, also known as Mingw64, it fails completely.

I tested under cmd and it worked ok.

[AlecAivazis]

Thanks for reporting this @rfay - i'll try to reproduce this on my windows machine and see if I can come up with a solution relatively soon.

[rfay]

Sorry that I haven't dived into the code, but is it possible you're using a OS-level detection instead of terminal capabilities detection? (with golang.org/x/crypto/ssh/terminal)

Thanks so much for your work on this, and for the rapid response here. We absolutely love the functionality of survey, it's beautiful, far nicer than anything we've ever worked with. We have a lot of trouble testing it, were unable to get go-expect to work with or without our binary, couldn't figure out why and couldn't figure out how one debugs go-expect.

[AlecAivazis]

@hinshun is the guy to ask about integrating with go-expect. Hopefully he can address the issues you are having. I will try to get to the bottom of the terminal issues. We're not using golang.org/x/crypto/ssh/terminal and are just relying on suffixing the name of the files with the build target. This obvously doesn't work to differentiate Mingw64 from cmd.exe. I'll try to look into this soon to get you a fix ASAP.

Would you mind posting the full list of questions and the call to survey.Ask so I can make sure that your code works as expected.

[rfay]

I opened https://github.com/Netflix/go-expect/issues/5 on go-expect, asking about timeouts, but the bottom line is if something's wrong, you can get a hang in your tests, and they're enormously difficult to debug, or see state, or figure out where to go. If you think more would be useful in this project (new issue?) or in go-expect, I'm happy to write up more. go-expect just (currently) looks like a rathole for maintenance because of these issues.

[AlecAivazis]

I think it makes a lot of sense to keep that issue as the go-to place for handling the debugging issues. I think the place where survey is impacted (apart from recommending go-expect as the testing framework) is to ensure that we support Mingw64.

[hinshun]

I think go-expect definitely have a long way to go in terms of ease of debugging. Unfortunately because go test hides away your raw os.Stdout, os.Stdin, it's hard to provide a way to interactively continue from where a test is hanging. You can definitely do this if go-expect was running as a regular go binary.

Let's continue discussing improvements about go-expect in its git repository, I'd be happy to brainstorm with you on how we can make it better.

[rfay]

Discussing testing with @hinshun over in https://github.com/Netflix/go-expect/issues/5 he mentioned that go-expect definitely does not currently support Windows. And I'm going to jump to the assumption that https://github.com/hinshun/vt10x also doesn't support Windows. So then that would mean that survey doesn't have any capability of running tests under Windows either right?

[hinshun]

go-expect tests are skipped on windows: https://github.com/AlecAivazis/survey/blob/master/survey_windows_test.go

Prior to the introduction of go-expect, survey was manually tested from files here: https://github.com/AlecAivazis/survey/tree/master/tests

[vinchauhan]

Strange it works on the integrated git bash terminal in vscode but not in the actual ming terminal

[jobnte]

Is there any solution for this?

[gbraad]

The issue seems to be with MinTTY running the bash command, as starting "c:\Program Files\Git\bin\bash.exe" from the Command Prompt does not have the same issue.

Note: C:\Program Files\Git\git-bash.exe shows very different behaviour. It invokes C:\Program Files\Git\usr\bin\mintty.exe as terminal.

[gbraad]

The line that fails is: https://github.com/AlecAivazis/survey/blob/4de88574e78145bdcfa6627ed766564231588b31/terminal/runereader_windows.go#L94

[gbraad]

Filed: https://github.com/mintty/mintty/issues/906

[jlu5]

Another workaround might be to run the affected app under winpty - I tried this with saml2aws (above linked issue) and it appears to work around the issue. AFAICT winpty is bundled with Git for Windows.

[mdrohmann]

@rfay If testing survey on Windows is still a priority for you: we have managed to enhance Netflix/go-expect, such that it can use conpty on Windows. The result is ActiveState/termtest . It works very well for testing survey driven menus for us.

[rfay]

Thanks so much for letting me know @mdrohmann - Didn't end up using any of these approaches.

[cpitstick-argo]

When trying to debug interactive applications in Visual Studio Code or IntelliJ (such as saml2aws), the prompts are skipped in the Debug console.

[vpishuk]

Authorization flow affected as well.

[UgmaDevelopment]

@AlecAivazis, thanks for your hard work on this. I'm sure it's not a good time to have so many people breathing down your neck.

Is there anything we can do to help?

[sschuberth]

Probably @dscho is able to give some advice about what exactly needs to be fixed.

[dscho]

I lack the context and the time... :sad:

[rfay]

Seeing the nice mention in Golang Weekly (congratulations! 🚀 ) reminded me of survey, which I loved except for this problem. Is this issue any better at this point? I see that the Windows capability is highly promoted in the README now, not sure if it was back then.

The project I work on is cross-platform, so anything has to work so many places: macOS (arm64/amd64), linux (everywhere), Windows (traditional and WSL2). And most people using it in traditional windows will be using git-bash.

[AlecAivazis]

I hadn't seen the mention in golang weekly - that's awesome! thanks for sharing 😄

Unfortunately, im not too familiar with the Mingw64 terminal and very much lacking in time. If someone wants to take this on, i'm happy to provide any guidance I can

[dscho]

I see that winpty has been suggested as a working work-around. This makes me believe that you could imitate how Git for Windows itself (which also does not have direct access to MinTTY's pseudo terminal) handles this. In a nutshell, it spawns cat >/dev/tty && read -r -s line </dev/tty && echo \"$line\" && echo >/dev/tty and reads its output, which works because the bash.exe shipped with Git for Windows does have access to /dev/tty. Good luck... 😃

[rfay]

It's hard to claim support for Windows when the basic git-bash terminal can't work; so many people in the dev world use that to interact with Windows.

[AlecAivazis]

@rfay i understand where you're coming from. The claim to support windows comes from supporting the native windows terminal and cmder. There are so many different terminals in the windows ecosystem its hard to track them all. I understand that git-bash is a very common one which is why I think this is an important thing to solve - it would clearly help a large number of users. Like I said, if you want to give it a shot I would gladly offer however much support I can

[rfay]

Yeah, totally understood. And of course I have the same problem and same limited resources and same spread-out-all-over-the-place problem with the projects I maintain. Thanks for all your effort on this! It's a beautiful tool.

[dscho]

Why don't you simply add the suggestion to use winpty ... in Git Bash? That way, you still support Windows, and you do not have to change even as much as a line of code.

[pmi]

@AlecAivazis Any news regarding this issue ?

[codingcn]

bubbletea looks like a good and well maintained alternative.