VSCode.exe via interop in /mnt subdirectory blocks WSL and new VSCode windows

[bushidocodes]

• A brief description

Launching VSCode with the current directory WSL while in a /mnt Windows directory spawns a process the blocks the WSL terminal. This also prevents me from being able to open new VSCode windows from the Windows environment. I presume this is because the interop functionality has wrapped this process to provide PIDs and such, which blocks the Windows GUI from launching the program.

I can Control+C to stop the "VSCode process" in WSL and the VSCode app persists on the Windows side. However, I'm unable to launch new VSCode windows from my shortcuts or Windows Explorer context menus until I fully close out the VSCode process launched by WSL.

• Expected results

I expect launching VSCode from WSL to function more like a shortcut, whereby I can invoke it on whatever current directory I'm looking at in WSL, and it launches VSCode without blocking my app or tracking PIDs or interfering with my ability to launch new VSCode windows from the Windows environment. I expect to be able to pass *NIX style absolute and relative paths to VSCode.exe as arguments and have them open upon initial load. I expect to be able to seemlessly switch back and forth between WSL and Windows Explorer and launch as many VSCode windows as I want.

• Actual results (with terminal output if applicable)

➜ Documents pwd
/mnt/c/Users/Sean/Documents
➜ Documents Code.exe .
[...interop pid to Code.exe hangs terminal...]

• Your Windows build number

14871.rs_prerelease.161111-1700

[benhillis]

Thanks for trying out interop!

Some notes I have after running through your scenario:

1. The behavior of VSCode not launching additional windows is an implementation detail of VSCode. I tried this locally and even from Windows I'm only able to open one VSCode window - so this is by design.
2. The behavior of GUI applications blocking input from the console is fairly standard in Linux. For example launching firefox from the terminal will block until firefox is closed. You can get around this by launching things in the background by adding a '&' at the end of your command. For example "notepad.exe &"

I expect to be able to pass *NIX style absolute and relative paths to VSCode.exe as arguments and have them open upon initial load

This one is more complicated. In order for the NT version of VSCode to launch using Linux paths one of two things would have to happen:

1. VSCode would have to have built in logic to understand WSL file paths.
2. WSL could do some magic to the command line before creating the NT process. I outlined some of the trouble with that in Launching Win32 applications from within WSL #1243

[therealkenc]

FWIW, VSCode backgrounds on Linux, unlike say firefox. That's just the user-experience they chose. As does Sublime Text and Atom.

There is an interesting Electron bug here that blocked VSCode until they worked around the issue. It raises differences in the way "graphic apps" in Windows vs. Linux treat stdout, stdin and stderr. Electron apps have a lesser known environment variable ELECTRON_RUN_AS_NODE which caused one of your brethren a lot of grief. Node of course is fundamentally CLI.

Interop on environment variables is another fun topic, by the way. Also I think there might be a third way to the path problem, but first I want to see if I can make it work myself ;).

[tara-raj]

Closing this issue as we have made updates to how VS Code is launched from WSL that should resolve this. Please re-open if you are still experiencing this issue on a more recent build of WSL/VS Code.