Support launching VS Code from Bash on Ubuntu on Windows

[sujaysarma]

• VSCode Version: Unpacked and installed "code_1.5.3-1474533365_amd64.deb"
• OS Version: Windows 10 with WSL, latest patched.

Steps to Reproduce:
(NOTE: I am running Xming on my Windows 10 host, and have "export DISPLAY=:0" set in my .bashrc file)

1. Open Bash on Ubuntu on Windows
2. Type "code" and press ENTER.

Expected result:
Code launches in a GUI window.

Actual result:
Absolutely nothing happens. There is no output. The prompt just returns in a couple of seconds.

[Tyriar]

We don't support this at the moment.

[sujaysarma]

In that case, would be good if some message was output to the console window rather than silence.

[Tyriar]

@sujaysarma code --verbose should give you some info

[sujaysarma]

Have you tried --verbose? This is what I see (see attachment)... Tell me how this is supposed to let someone know that it is "not supported"? What would be meaningful is a message like "Code is not supported to run on your OS/platform/configuration".

[Tyriar]

@sujaysarma vscode has a relatively small team compared to the size of the product, we simply do not have the people to cover every single edge case. I looked briefly at support for Bash on Ubuntu in the past and came to the conclusion that it is not worth the effort right now while it's so new.

The output from --verbose gives you some information about why it is not starting as I said, you can look into it here if you're interested.

[MathiasMagnus]

+1

[jonomacd]

+1E99

Support for this such that vscode uses the bash terminal for everything would be great. I don't want to see, touch or smell the windows terminal. Every shell out directed to bash for windows please.

[csholmq]

@jonomacd You can use the integrated terminal with bash using "terminal.integrated.shell.windows": "C:/Windows/sysnative/bash.exe"

[Tyriar]

@csholmq this one's about launching vscode from a bash in Windows shell, which actually works last time I checked, it just needs some refinement (an empty cli.js file was opening).

[MathiasMagnus]

@Tyriar How did it work?

[Tyriar]

@MathiasMagnus I tried it the other day, I ran code-insiders inside a regular bash on windows shell and it launched VS Code fine. So I believe they must have got around the X window issue in latest Windows.

[csholmq]

@Tyriar Oh, my mistake.

I assume you're on Windows Insiders then. Because it doesn't work for me on.my work machine.

[Tyriar]

@csholmq yeah I think it was. Woo progress 😉

[CherryDT]

I can confirm that it works for me on 14986 too, but I also get an empty file cli.js opened (additionally to any file I'm actually trying to open)

This only happens when running the bin/code-insiders file, though. Running Code - Insiders.exe works!

[Tyriar]

The command runs this which opens cli.js:

ELECTRON_RUN_AS_NODE=1 "/mnt/c/Program Files (x86)/Microsoft VS Code Insiders/Code - Insiders.ex
e" "/mnt/c/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/cli.js"

It doesn't happen in Git Bash.

[Tyriar]

code-insiders --help ignores args and launches in Bash on WIndows but not Git Bash.

[Tyriar]

This is the arg that is received by VS Code: 'C:\\mnt\\c\\Program Files (x86)\\Microsoft VS Code Insiders\\resources\\app\\out\\cli.js, looks like that's the issue (C:\\mnt\\c)

[Tyriar]

The reason this doesn't work is because the environment (ELECTRON_RUN_AS_NODE=1) is not transferred when launching an exe from bash on windows, see microsoft/WSL#1363 & microsoft/WSL#1494

[Tyriar]

I tried to fix the path conversion issue by using the following:

CLI=$(echo "$VSCODE_PATH/resources/app/out/cli.js" | sed -e 's/\/mnt\/\([a-z]\)\//\1:\//g')

Unfortunately due to microsoft/WSL#1363 and microsoft/WSL#1494 it just won't work. I also tried to call into code.cmd however the --help didn't seem to work properly.

In the meantime I can fix the cli.js specifically and get the CLI working for relative files.

[Tyriar]

Forked the relative path issue to #18536 as it's going into the release.

[MathiasMagnus]

On a related note, there are several mentions of Xming, Vcxsrv and MobaXTerm, but I recently installed X410, a MS Store app (had major discount recently) and I am very satisfied with it. Installs easily (like all Store apps), accelerated OpenGL 3.3, so it suits most of my needs.

[FranklinYu]

@MathiasMagnus It works for me, but seems to have fewer features than VcXsrv, like “X server without authentication” and “specify display number”. (They may be available in paid version, but there is some issue with my Microsoft Store account…)

[safizn]

How are the commands code & code-insiders run without the use of .exe extension ? Is alias for the command built into the Linux WSL distro ?
Can I do the same for docker command, so it would feel native ?
Does it use somehow the WSLENV shared variable to achieve this ?

[safizn]

How is code & code-insiders run without the .exe extension ? Is an alias build into the Linux WSL distro ?
Can I do the same for docker command, so it would feel native ?

I guess the VS Code installer just adds a specific entrypoint for WSL into bin files (code file containing #!/usr/bin/env bash) that are added to the PATH variable.

[int19h]

Seconding the X410 recommendation for GUI. Also, take a look at this for easy setup:

https://whitewaterfoundry.com/WLinux/

[WSLUser]

How are the commands code & code-insiders run without the use of .exe extension ?

Add the vs code repo using the MS provided instructions. This issue is about running native VS Code for Linux and you can do that starting with Win 10 build 17134+. Modifying Linux files using Windows VS Code is a separate issue and is resolved utilizing the metadata feature introduced in the same build mentioned above. See the appropriate issue for more discussion on it or the command-line blogs.

Technically this issue can be closed since it can in fact be run despite the fact that the I/O infrastructure in WSL still needs improvement to be suitable in some use-cases regarding performance.

[spences10]

It's still an issue for me

Is this going to be fixed in coming Windows builds?

[therealkenc]

It's still an issue for me

Pronouns.

The OP here was:

[...]
(NOTE: I am running Xming on my Windows 10 host, and have "export DISPLAY=:0" set in my .bashrc file)
[...]
Actual result:
Absolutely nothing happens. There is no output. The prompt just returns in a couple of seconds.

There was never a "VSCode" actionable in this issue from the getgo. Any native Linux application (VSCode or otherwise) that doesn't work on WSL is by definition either a bug, or a missing feature, or by-design (EWONTFIX) in WSL. At one point before eventfd(2) was addressed in WSL (the cause of the OP nothingness) one could have made a case for electron workarounds to make VSCode happy. But those WSL issues (there were about half a dozen) have now been addressed as of Win10 build 1809 (some earlier). Actually, it has been pleasantly surprising how few (new) WSL bugs have popped up due to native nodejs addons or electron/nodejs proper since VSCode lit up in WSL. "New" because there's known unresolved stuff that affects VSCode (and everything else). Whether there have been few reports because not many people are using native VSCode on WSL, or because there isn't anything to report, I can't say.

For anyone using VSCode native on WSL, bear in mind graphics scenarios are still nominally unsupported per the WSL FAQ, so you're on your own. But to a first order native VSCode "works" on WSL, and anything that doesn't work isn't really the VSCode team's problem. Bonne chance.

[spences10]

Ok, I have no idea why I commenting here.

I thought what the title meant:

Support launching VS Code from Bash on Ubuntu on Windows

Was that when using bash on windows (WSL) and you navigate to a project via the terminal:

cd /repos/some-project

then from there you can launch VS Code with:

code .

The expected behaviour is that the terminal launches code and that's it done, what currently happens on my 1809 build machine is that the terminal is locked and you have to Ctrl+c to free up the terminal again.

So, is there an issue raised for that behaviour @therealkenc?

I'll be honest logging an issue isn't the most straightforward affair and I'd rather jump on someone else's issue rather than jump through the hoops needed to report a bug.

Thanks 🙏

[markdeloura]

Mine is still running fine, I use it daily for development work. I start up WSL, cd to my source directory, and use code . to start up the editor - it comes from /usr/bin/code. Xming is my X Windows server. code and code-insiders both update via apt-get. Hm maybe we need a walkthrough on how to get it to work properly.

[therealkenc]

Ok, I have no idea why I commenting here.

That's the general idea (not directed at you specifically, mind).

cd /repos/some-project
code .
The expected behaviour is that the terminal launches code and that's it done

No, the expected behavior with that repro is the shell will return with code not found, if not the chdir to nonexistent repos/some-project.

So, is there an issue raised for that behaviour @therealkenc?

Pronouns.

I'd rather jump on someone else's issue

There are presently no outstanding issues to jump on. Although new ones are always welcome.

Hm maybe we need a walkthrough on how to get it to work properly

Fair enough I guess, although none of the steps are WSL specific, because there is nothing special about WSL versus a headless Real Linux box with a nonfunctioning systemd.

$ # cleanish 18.04 WSL install from the MSFT Store running on Win10 1809
$ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
$ sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
$ sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list'
$ sudo apt update && sudo apt upgrade
$ sudo apt install libgtk2.0-0 libxss1 libasound2 mesa-utils code
$ export DISPLAY=localhost:0
$ export NO_AT_BRIDGE=1
$ sudo service dbus start
$ exec dbus-run-session -- bash
$ touch hello.txt
$ /usr/bin/code -n ./hello.txt

[That's off the cuff. It assumes you have a functioning X Server on localhost. VcXsrv and xrdp are popular choices. YRMV.]

[jaakkouu]

I had trouble getting this all working. Running code -verbose gave me error:

Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborted.

Then I ran sudo apt purge libpulse0 to remove the failing package.

After that I tried again Code .

Bob's your uncle.

[therealkenc]

Running code -verbose gave me error:
Assertion 'pthread_mutex_unlock(&m->mutex) == 0'

Folks may see that on Win10 1803. The error path has been addressed in 1809. Hence the # .... running on Win10 1809. Purging libpulse0 is a reasonable work-around.

[Jaff1]

it works perfectly fine for me on Windows 10 Home (autoupdate enabled and up to date), with the latest ubuntu (from Windows Store):

dave@my_laptop_name  ~
$ uname -a
Linux my_laptop_name  4.4.0-17134-Microsoft #137-Microsoft Thu Jun 14 18:46:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

code . launches a code instance perfectly with current directory open in project pane

for wsl interface, I am using wsltty: https://github.com/mintty/wsltty

Maybe it helps for others to know this?

Starts fine for me - just typing "code" in the bash shell on ubuntu (WSL): Probably supported in a later version than #13138, e.g. mine is
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.17134 N/A Build 17134

[MathiasMagnus]

@jaakkouu You do understand you cannot say goodbye to XServer, right?

[therealkenc]

Can confirm. Holy cow it actually works.

Pronoun. If by it you mean WSL Windows interop, that has been available since build 14951 circa October 2016. Launching code.exe via interop was not the question asked in the OP.

I will not be using it for this purpose

Another one. Depends on your purpose. If your purpose it to edit text files in /mnt/c, à la notepad.exe, yes. If your purpose is software development it depends a lot on the scenario, until the work in #63155 is complete.

[jcklpe]

Just a follow up note on my earlier comment.

While I got vscode installed in WSL and running graphically with vcxsrv it's kind of a hassle to have to launch vcxsrv everytime I want to use vscode to open a file from WSL bash cli. I found a solution which was to create the following alias:

alias vscode="/mnt/c/'Program Files'/'Microsoft VS Code'/Code.exe"

using vscode as an alternative command word keeps it from interfering with the normal code command word in the cli but also makes it easy for me to open the windows version of vscode from my bash prompt. Woo!

This is probably pretty obvious to other devs, but like I said, I'm pretty new to development so I'm glad I figured it out! :)

[JoeRoddy]

sudo apt-get install realpath
then restart terminal got it working for me.

[sbonds]

I have the same issue as #35553 (marked as a duplicate of this one), which is that VS Code won't run under Linux when using a remote X server. This results in a silent failure under normal conditions or the following error under --verbose:

[main 2019-03-20T18:17:33.461Z] windowsManager#open
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
code: xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

A workaround is to use a VNC server running on the remote Linux host instead of an X Server running on Windows.

[championbarca]

Check these steps, it solved my issue:
https://discuss.atom.io/t/atom-over-x11-forwarding-with-xming-errors/25151/7

[RMacfarlane]

We just announced remote development with VS Code, check out the blog post for details https://code.visualstudio.com/blogs/2019/05/02/remote-development