Visual studio code does not launch anymore

[Macfly]

Describe the bug When I try to launch VS code I have the follwoing error: coval@LAPTOP-PVGUIGKO  ~  code& [1] 139 To use VS Code with the Windows Subsystem for Linux, please install VS Code in Windows and uninstall the Linux version in WSL. You can then use the 'Visual Studio Code' command in a WSL terminal just as you would in a normal command prompt. [1] + 139 suspended (tty output) code

To Reproduce Steps to reproduce the behavior:

1. code&

Expected behavior Visual Studio is supposed to launch with the X server

Screenshots If applicable, add screenshots to help explain your problem.

Pengwin Version

Insert here: 1.2.4.0

Windows Build

Run 'systeminfo | findstr /C:"OS"' in Command Prompt and insert here: OS Name: Microsoft Windows 10 Pro OS Version: 10.0.17763 N/A Build 17763 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Workstation OS Build Type: Multiprocessor Free BIOS Version: American Megatrends Inc. 5.11, 2/23/2018

[crramirez]

Hello,

Why do you append an & to code? Just run code and answer yes when it ask you if you still want to launch it.

Regards

[DistractionRectangle]

This is an upstream issue related to vscode v1.3.4 With code-insiders, it's now possible to do remote development inside of ssh, docker, and wsl from a windows native installation of vscode (insiders build, it's not available in the current standard release).

They've now added a user prompt to inform you about this option, requiring y/n input. Making code run as a background task (which isn't necessary as @crramirez stated) effectively hangs it since you've not given it a response.

A work around would be:

echo 'y' | code <some arguments here> &

You could alias code to restore old behavior. code () { echo 'y' | \code "$@" ; }

[WSLUser]

I will note that there does seem to be some noticeable differences in running VSCode in WSL vs Linux vs Windows. I think they've introduced some WSL specific code to force migration to using the new remote extension. It does work well but limiting people's choice of how to run it isn't the right thing to do either. Most notable difference is how easy it is to crash it whereas before, it usually worked without issues. Probably worth filing an issue over but I think it was intentional.

[enjibby]

I am now using VSCode from within WSL because it handles developing in containers that are running in docker inside WSL. VSCode for Windows with Remote Development does not currently handle developing in a docker container hosted by WSL.

I have created a shortcut in my start menu using the following as a target: C:\Windows\System32\wsl.exe echo 'y' | DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0.0 code (Grepping for the nameserver of the network connection means I can send the GUI to the X-Server running on the Windows 10 host)

I assume this will change before all these insider things get released, but for the moment this is a really handy way of running things for me :)

[WSLUser]

A bit unrelated to the OP but useful workaround. Did you file an issue with them to fix the container issue?

Also keep in mind they do have a remote container extension. So it's likely you'll need to use that. If I were to hazard a guess, running the wsl version of vs code with the remote-container extension would probably address your needs though you'd still need your workaround to get GUI working. What would optimally happen is you can install the container extension inside of wsl using the remote-wsl extension (similar to installing other extensions). You could technically do this now as the container source code is slightly more open than the other remote extensions but it would be a manual process.

[grahammcculloch]

FYI I just came across this same issue and, examining the code-base led me to a slightly simpler solution...

In your .bashrc file (for example):

export DONT_PROMPT_WSL_INSTALL=1

VS Code on your WSL distribution will no longer attempt to prompt you to use VS Code in Windows 😃