1.When remote side socket is closed, `SIGPIPE` might be sent. We must ignore and exit correctly (we can't die as we might accept more connections)
2. shutdown and close sockets will inform remote side that socket is closed. Without it, remote side may not notice anything until the next write.
GitOrigin-RevId: 51a6204651e49f63ac8b52d9e3e1e4928007c3ff
Due to https://github.com/microsoft/WSL/issues/10718 `SHELL` var is set to `ttyfix` breaking `gdb`.
We now:
1. Check if first argument (command to execute) is a valid shell and set `SHELL` accordingly
2. If not, check user default shell. Be it a valid shell, we use it
3. Unset `SHELL` otherwise
Review:
https://jetbrains.team/p/ij/reviews/118965/timeline
GitOrigin-RevId: 425b6886b4b48e29f653413c62326afa8033c694
The problem:
https://github.com/microsoft/WSL/issues/10701
When stdout/err are redirected, WSL reports tty size as 1x1 which breaks `ps` tool (famous "expect trouble" message) that some people might have in profile.
`ttyfix` explicitly sets tty size and inserted by `WslDistribution`.
Tiny refactoring moved `getToolPath` to reuse it
Merge-request: KT-MR-12821
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: f33a906b139d22ecdaf0f1b0616ecaaf7bebdd16
fixup! PY-59608: Support ``wslproxy`` when routing is broken by VPN.
When user runs VPN with default gateway pointing to the VPN server and configures interface weight, we can't connect to WSL using its egress IP (traffic to ``172.0.0.0/8`` goes to VPN instead of WSL).
With ``wsl.proxy.connect.localhost`` enabled in registry we bind ``wslproxy`` to ``127.0.0.1`` which could be used in latest WSL2 to connect from Windows to Linux. It is a little bit slow, but still works.
fixup! PY-59608: Support ``wslproxy`` when routing is broken by VPN.
PY-59608: Support ``wslproxy`` when routing is broken by VPN.
When user runs VPN with default gateway pointing to the VPN server and configures interface weight, we can't connect to WSL using its egress IP (traffic to ``172.0.0.0/8`` goes to VPN instead of WSL).
With ``wsl.proxy.connect.localhost`` enabled in registry we bind ``wslproxy`` to ``127.0.0.1`` which could be used in latest WSL2 to connect from Windows to Linux. It is a little bit slow, but still works.
Co-authored-by: Vladimir Lagunov <vladimir.lagunov@jetbrains.com>
Merge-request: IJ-MR-105285
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: 74b5ad4df9c5e95ca4ef53a465f07855a92aa324
By default, we cross-compile for `aarch64`, but that could be adjusted via `HOST` variable.
Also cleaned up the `Makefile` and updated README.
Reviewed-by: IJ-CR-102814
GitOrigin-RevId: b65519b2ab6a3461f0e621d5dcc832b083948fef
Currently, filters support only includes and excludes of files matching the regex patterns. But it should be fairly easy to extend this with other types of filters in the future.
Reviewed-by: IJ-CR-102814
GitOrigin-RevId: 80b7e33aa4d6f89b8a9279d4aa2648783e363bf4
``ifaddrs->ifa_addr`` may be NULL according to ``getifaddr(3)``.
This is a case for the tailscale VPN at least
GitOrigin-RevId: 134cd2bcf03a01b6c52536e23b86a1135450d67b
Symlinks on Windows are junctions (since no UAC required), so only directory symlinks are supported.
GitOrigin-RevId: 9f9134d59597d2987a7c1b95602dc6e477651dfb
``rsync`` is slow because every file system access call from WSL to Windows and vice versa is slow.
We need to decrement number of such calls.
This approach does the following:
* Calculates hashes on Windows side using Intellij process
* Calculates hashes on WSL side using native Linux process
* Compares them searching for differences
* Splits different files into groups, tars each group and copies them on the other side.
From what I checked this is the fastest approach to sync WSL and Windows.
* How to use *
`WslSyncAction` is a temporary internal only action. Run it and try to sync some folder.
`WslSync` is a class with static method you can use to sync to folders.
GitOrigin-RevId: 6c63329d73ff32b7ee5e4436bfde39e72fe35a44
WSLProxy helps processes running on WSL connect to Windows bypassing firewall. See WslProxy.kt and wslproxy.c for more info.
GitOrigin-RevId: bb5d0fc0c67ad18ccc2a2c285b5b71f76e00b26b
Ingress port (127.0.0.1:some-port) or WSL must accept several connections.
All of them are forwarded to application port.
Django debug doesn't work without it because it uses several processes, each connected to port on WSL.
See wslproxy.svg and wslproxy.c doc
GitOrigin-RevId: 4623aef93409c1ea8f282908ae0ba8a810652413
