We recommend a WSL terminal simulator and a WSL terminal simulator.

We recommend a WSL terminal simulator and a WSL terminal simulator.

Windows 10 contains a WSL (Windows Subsystem for Linux) Subsystem in which we can run native Linux ELF executable files without modification. Using it, we can do a lot of things, which is true for developers and common users. Of course, it is more attractive to developers, because it means that in some cases, you no longer need to use Linux virtual machines, dual systems, Cygwin/MSYS2.

In WSL, we can directly access the local file system. For example, your computer has three partitions: C:, D:, E:. The paths in WSL are/mnt/c, respectively, /mnt/d,/mnt/e

The common method is to input bash in Win + R directly, but the bash experience in the system is poor. The main problems are as follows:

At present, a better alternative solution is to use wsl-terminal, which is a terminal simulator specially designed for WSL. The main body is mintty. In addition, it integrates some tools and is very convenient to use, it is also the best user experience, and the size is only 1 MB.
For how to use it, see the official homepage: https://github.com/goreliu/wsl-terminal

In terms of implementation, it is improved by starting sshd in WSL and then using ssh client login. Its operating mechanism is very different from that of ssh. Mintty runs wslbridge. wslbridge contains two programs, wslbridge.exe and wslbridge-backend. It can be seen from the file name that the former is a Windows program and the latter is a Linux program. Wslbridge.exe runs bash.exe in a hidden window to enter the WSL environment, where wslbridge-backend under the same directory is run. Three tcp connections are established between wslbridge.exe and wslbridge-backend, that is, stdin, stdout, and stderr are connected through three tcp connections respectively. After the connection is established, no ports are listened. Mintty is a terminal simulator, which has no difference between wslbridge and ssh.

In terms of performance, the speed of using wslbridge and ssh to execute commands is almost the same here. The former is a little faster and not obvious. Resource occupation, the former is dominant.

Wslbridge is dominant in ease of use. You no longer need to start sshd and configure trust relationships. In addition, wslbridge will automatically pass the current path, without the need to convert the path and then splice the cd command, which is much easier. In addition, you can directly pass environment variables through parameters. Several scripts I wrote earlier reduced the number of lines by dozens.