# windows: Fix ssh reporting wrong password even it's actually correct \(\#38263\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/14fc726cae5ae558d72504289867152894c5b6e5)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 14fc726cae5ae558d72504289867152894c5b6e5

Requested commit: 14fc726cae5ae558d72504289867152894c5b6e5

Commit: 14fc726cae5ae558d72504289867152894c5b6e5

Tree: ba9c2ebb4fc88da8ab6de6a07ec42e6b812f54f2

Author: 张小白

Committer: GitHub

## Message

```
windows: Fix ssh reporting wrong password even it's actually correct (#38263)

Closes #34393

Currently, we’re using `zed.exe --askpass` kind of like an `nc`
substitute, it prints out the SSH password to stdout with something like
`println!("user-pwd")`. `ssh.exe` then reads the password from stdout so
it can establish the connection.

The problem is that in release builds we set `subsystem=windows` to
avoid Windows spawning a black console window by default. The side
effect is that `zed.exe` no longer has a stdout, so `ssh.exe` can’t read
the password.

Through testing, I confirmed that neither allocating a new console for
`zed.exe` nor attaching it to the parent process’s stdout resolves the
issue. As a result, this PR updates the implementation to use `cli.exe
--askpass` instead.

TODO:

- [ ] Check that the `cli` path is correct on macOS
- [ ] Check that the `cli` path is correct on Linux

Release Notes:

- N/A

---------

Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
```

## Parents

- [4f95186b537aaeda56d79083c1453af9f09a27b7](https://git.cafe/gitcafe/zed/commit/4f95186b537aaeda56d79083c1453af9f09a27b7?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/14fc726cae5ae558d72504289867152894c5b6e5?format=markdown)
