SetConsoleMode(console, mode & ~ENABLE_ECHO_INPUT) does not work

[floriansimon1]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options
git version 2.21.0.windows.1
cpu: x86_64
built from commit: 2481c4cbe949856f270a3ee80c802f5dd89381aa
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 10, x64

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.16299.1387]

• What options did you set as part of the installation? Or did you choose the
  defaults?
  Defaults

### Details

 - Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
CMD

 - What commands did you run to trigger this issue? If you can provide a
   [Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve)
   this will help us understand the issue.

* Create a password-protected zip file
* Try to extract its content using the 7z.exe CLI program (`7z.exe x <thezip>`)
* Type a password

 - What did you expect to occur after running these commands?
No echoed password

 - What actually happened instead?
Notice that the password is echoed

- Additional info
7z seems to read passwords using this bit of code: https://github.com/kornelski/7z/search?q=SetConsoleMode&unscoped_q=SetConsoleMode

[PhilipOakley]

hi @floriansimon1, Is this a Git problem, or just a problem that happens because you have started using 7zip because it came with Git?

At the moment I can't see it being a Git problem, rather that you should report the problem to 7zip.

[floriansimon1]

This occurs in Git Bash inside CMD, but not when using CMD directly. I think it was working before an update (hence why I report this here). I'll try older versions and I'll let you know ;)

[PhilipOakley]

Git Bash inside CMD

That, to me, sounds like part of the issue, but it's not an area I've studied. I know there have been may difficulties in getting the semantics of *nix/bash/posix to play well with the Win10/Cmd/Msys2 semantics as lots of folks use other command windows and things like Ctrl+C are a real pain for character trapping and exchange.

I guess that in the 'Bash in CMD' scenario you are getting echoing of characters between the interface layers where you had expected them to be swallowed by the application, which is at a different level.

But as I said it's not my area of expertise, and this is only my hearsay of prior issues on the list. I'm sure that others will be interested in any other digging you can do.

[dscho]

From https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md#known-issues:

• Some console programs, most notably non-MSYS2 Python, PHP, Node and OpenSSL, interact correctly with MinTTY only when called through winpty (e.g. the Python console needs to be started as winpty python instead of just python).

Could that be it?

[floriansimon1]

Using winpty fixes the issue. Are you able to provide details about what the differences are?

Thanks for your assistance.

[dscho]

Are you able to provide details about what the differences are?

Yes.

MinTTY is an MSYS2 program, i.e. it uses the POSIX emulation layer known as "the MSYS2 runtime" (which is a friendly fork of "the Cygwin runtime"). As such, it has an idea of what a pseudo terminal looks like, as that is what is used on Linux/Unix/macOS.

On Windows, however, there is a Win32 Console. Therefore, even while any console program has a Win32 Console instance (sometimes implicitly so), MinTTY does not use it.

Only in very recent Windows versions is there support to access the Win32 Console as if it were a Unix pseudo terminal. And Cygwin is only in the process of learning about this, there is not even any official version of Cygwin which supports that yet.

The current workaround is to run any Win32 program that expects a Win32 Console with winpty. This program will instantiate a Win32 Console, and attach to the pseudo terminal provided via the MSYS2 runtime, and try to synchronize between the two. It is just a workaround, but it does work in most cases.