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 :wink:

[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 https://github.com/Microsoft/BashOnWindows/issues/1363 & https://github.com/Microsoft/BashOnWindows/issues/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 https://github.com/Microsoft/BashOnWindows/issues/1363 and https://github.com/Microsoft/BashOnWindows/issues/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 https://github.com/Microsoft/vscode/issues/18536 as it's going into the release.

[figuerres]

Hey Microsoft what gives ? if you are going to offer developers a linux system on windows and a portable editor called code that works on all the other linux and mac os systems then you need to get the two teams in the same room and make this stuff work!

the way things are going i might as well just get a mac and run vs code on a mac where all of the filesystem and all of the commands "just work"

are you going to get more developers on windows if they see that Microsoft can't make the developer environment work in a smooth way ? or are you going to have a lot of developers switch to "the real thing" called Linux / UNIX and dump the whole WIndows stack?

think about it. really think about it.

[Tyriar]

@figuerres you will notice progress was made 20 days ago towards resolving this issue, fixing arguable the biggest use case of relative paths which will come in v1.9.0.

[ryansully]

FYI, did a bit of digging and found that this feature should be supported in Windows 10 Insider Preview builds from 14951: https://blogs.windows.com/windowsexperience/2016/10/19/announcing-windows-10-insider-preview-build-14951-for-mobile-and-pc/ It is part of their documentation now as well: https://msdn.microsoft.com/en-us/commandline/wsl/interop

With relevance to VS Code, this should provide project devs with platforms on which to test.

If you want to follow WSL release notes for status updates, look here: https://msdn.microsoft.com/en-us/commandline/wsl/release_notes

I look forward to being able to launch VS Code with code . just like subl ..

[Tyriar]

@ryansully might be worth giving it another try on today's release, I can't remember if I was using code . or code.sh . but one of them should work now.

[rbirkby]

I was running VSCode from WSL and did a VSCode update. One file was locked - I didn't pay much attention, choosing to ignore.

Following this, I could no longer start VSCode from bash with code ..

So I downloaded the latest installer from Windows and ran it again. This time, the missing file was written and code . from bash works again. Any idea why it was locked?

Before re-install and after directory listings:

root@TM-INFINITY:/mnt/c/Program Files (x86)/Microsoft VS Code/bin# ls
cat.exe  code.cmd  code.js
root@TM-INFINITY:/mnt/c/Program Files (x86)/Microsoft VS Code/bin# ls
cat.exe  code  code.cmd  code.js

I'm on insider preview 15019

[figuerres]

i did a test on my laptop and i was able to run vs code ! now to see if we can run the insider builds of windows on our work machines ....

[Tyriar]

@rbirkby not sure what happened there, I believe code is just a file that is installed by the installer.

@figuerres good to hear :smiley:

[abdullah2993]

+1

[damekr]

+1

[rjgonza]

+1

[int19h]

Here's what I get on Insider Preview 15048 with the most recent code-insiders:

This appears to be the same as https://github.com/Microsoft/BashOnWindows/issues/648.

[slikts]

This is what happens on 1703:

> code-insiders --verbose
[12686:0413/153621.223501:ERROR:browser_main_loop.cc(272)] Gtk: cannot open display: :0

[Mohamed3on]

+1 Notepad works, Code does not.

[oshalygin]

Anyone having any luck? Installed the package but command line doesnt work.

code-insiders --verbose
error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

EDIT: Installed all of the associated dependencies, but now no errors and it just doesnt work :( poop.

When running code-insiders --verbose, the following output comes out:

FATAL:render_sandbox_host_linux.cc(40)] Check failed: 0 == shutdown(renderrer_socket_, SHUT_RD). shutdown: invalid argument.

Then a bunch of unknowns =>

[csholmq]

Works for me on version 1703 (Creators Update).

sholmq@AR-489:/mnt/c/Users/sholmq$ /mnt/c/Program\ Files\ \(x86\)/Microsoft\ VS\ Code\ Insiders/Code\ -\ Insiders.exe launches 1.12.0-insider successfully.

Trying to launch using code-insiders does not. Complains about realpath not being on path and then fails to launch ./Code - Insiders.exe.

sholmq@AR-489:/mnt/c/Users/sholmq$ code-insiders --verbose
/mnt/c/Program Files (x86)/Microsoft VS Code Insiders/bin/code-insiders: rad 7: realpath: kommandot finns inte
/mnt/c/Program Files (x86)/Microsoft VS Code Insiders/bin/code-insiders: rad 14: ./Code - Insiders.exe: Filen eller katalogen finns inte

[Tyriar]

@oshalygin I think that will only happen if you try to run the Linux VS Code binary. Installing The Windows VS Code and then adding that to your Linux path will add a .sh script which should launch it.

[gordonbondon]

@csholmq i have fixed the realpath error with:

sudo apt-get install realpath

Now code and code-insiders work for me on 1703.

[csholmq]

@gordonbondon Nice, that fixed it!

In general I can now launch VSCode from bash on Win10.

[MathiasMagnus]

As far as I understood from the comments thus far, noone was able to get the native linux client running with the linux environment as its 'parent' (see the very same things, as if I was running it on a linux box).

Just as a test, I popped open an instance of Xming on my Windows box, set the DISPLAY environmental variable to localhost:0.0 and from a powershell console (cause that's where I live) issue bash.exe ~ -l (notice there's no X forwarding going on). Because there is no X forwarding, DISPLAY in the linux shell is not set. No worries, set it manually. After that, saying something like gedit pops open a gedit window in Xming (woot).

PS C:\Users\Matty> bash ~ -l
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

mnagy@MATTY-Z50-75:~$ export DISPLAY=localhost:0.0
mnagy@MATTY-Z50-75:~$ gedit

After that go for the big game: VS Code. What does saing code-insiders say?

mnagy@MATTY-Z50-75:~$ code-insiders --verbose .
[35:0426/153127.501252:ERROR:bus.cc(427)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Nincs ilyen fájl
 vagy könyvtár
[35:0426/153127.650293:WARNING:audio_manager.cc(317)] Multiple instances of AudioManager detected
[35:0426/153127.650488:WARNING:audio_manager.cc(278)] Multiple instances of AudioManager detected
[35:0426/153127.688064:FATAL:udev_linux.cc(20)] Check failed: monitor_.
#0 0x000001cca77e <unknown>
#1 0x000001cafa1b <unknown>
#2 0x000002ffc4b6 <unknown>
#3 0x0000022c513b <unknown>
#4 0x000001cb2e7e <unknown>
#5 0x000001d054cc <unknown>
#6 0x000001d05778 <unknown>
#7 0x000001d05adb <unknown>
#8 0x000001cb51d9 <unknown>
#9 0x000001d05267 <unknown>
#10 0x000001ce7bb0 <unknown>
#11 0x000002de25a6 <unknown>
#12 0x000002de2759 <unknown>
#13 0x000001d1d2a5 <unknown>
#14 0x000001cf7d03 <unknown>
#15 0x7fc385e676ba start_thread
#16 0x7fc37f2a682d clone

Still no worries, the internet says this socket cannot connect to system bus. Service is surely missing/stopped.

mnagy@MATTY-Z50-75:~$ sudo service dbus start
[sudo] mnagy jelszava:
 * Starting system message bus dbus                                                                                                           [ OK ]
mnagy@MATTY-Z50-75:~$ code-insiders --verbose .
[65:0426/154111.821082:WARNING:audio_manager.cc(317)] Multiple instances of AudioManager detected
[65:0426/154111.821557:WARNING:audio_manager.cc(278)] Multiple instances of AudioManager detected
[65:0426/154111.856709:FATAL:udev_linux.cc(20)] Check failed: monitor_.
...

Error messages gone, but still the same stack trace error appears. Any ideas?

[khuongduybui]

Before I start saying anything, this thread is about launching LINUX NATIVE VSCode inside Ubuntu on Windows with XMing serving as X-server on the Windows host. People have different reasons, but mine is to have an editor that can work directly with the Linux file system, not the mounted /mnt/c/ Windows file system.

Now to the point: I have installed latest stable VSCode (1.11.2 at the time), I have installed realpath, and start dbus service. The next error I'm facing is

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

[MathiasMagnus]

I did not mention, but gedit was warning me about some audio stuff and googling around led me to installing sudo apt install dbus-x11, and the warnings went away.

[kennethreitz]

i'm having no trouble at all, after installing the latest creator's update.

[khuongduybui]

@kennethreitz are you sure you are launching the native Linux binary (from /usr/bin/code) and not the Windows binary, which simply runs code.exe on Windows?

[khuongduybui]

@MathiasMagnus I'm still stuck at the mutex error. Did you not have that error at all? If memory serves, that error is shared between all Electron-based applications, if not all Chromium-based (including Google Chrome itself).

[masonk]

Hi from a Mac -> Windows switcher. My new laptop never would have been Windows without this extremely cool WSL product that you've brought us. So please tell your bosses that you're gaining 'developers, developers, developers!' with this thing.

As far as this issue, launching Windows apps from Bash would be sweet. Having just finished reading the first few blog posts about WSL, and beginning the setup of my dev environment here, launching VSC from bash was one of the first things I wanted to do but couldn't. I understand that you're focusing most of your development efforts into making the virtual Linux kernel as complete as possible. But, if you think about what WSL is for, namely, developing cross-platform applications from a Windows host, this is a big improvement to the development workflow for (what I'm hoping would amount to) a relatively small expenditure.

If you do implement this functionality, it should not be limited to VSCode. What would be most useful is a linux user-land binary that takes a path to a DriveFs Win32 executable, and makes a 'syscall' to lxcore.sys that maps that DriveFs path back to the host NTFS share and launches the Win32 application in the host. Yeah, you'd have to provide a virtual kext and implement your own user space binary to do this, but they'd be small ones, and you'd be closing the loop back to the host OS and enabling all sorts of cool tricks. Once we have the fundamental bridge binary, we can take care of building all the aliases we need for ourselves.

[CherryDT]

@masonk In fact, you can launch Windows apps from WSL just fine by now, this feature already exists for a while. Make sure you have the latest Windows build installed (15063)!

Also, this thread is about the fact that Linux VSCode (not Windows) does not work properly under WSL!

[masonk]

@CherryDT Oops. My mistake. Carry on then!

[figuerres]

kind of funny how this thread has been confusing as some folks have been trying to run the windows binary other folks trying to run the linux binary and sometimes folks do not see which one the other person is referring to.... kind of the blessing and the curse of running linux on windows and having one cross platform app

[crcrewso]

I'm finding this thread hard to navigate. Has anyone managed to successfully launch the Ubuntu version of VS code (from the new repository) in WSL? If so could you post how?

Right now here's my error,

~$ code --verbose
[771:0509/151826.968357:ERROR:bus.cc(427)] Failed to connect to the bus: Failed to connect to socket /host/run/dbus/system_bus_socket: No such file or directory
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.

This is after the dbus fix and running

export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket

[ghost]

I'm finding this thread hard to navigate. Has anyone managed to successfully launch the Ubuntu version of VS code (from the new repository) in WSL?

No.

Launching the Linux version of Code from WSL does not work yet due to low-level issues with WSL itself. In fact, electron apps like Code do not in general work with WSL at this point so there's not much that can be done here until that gets resolved.

Here are some relevant issues with further details:

https://github.com/Microsoft/BashOnWindows/issues/648#issuecomment-299699951 https://github.com/Microsoft/BashOnWindows/issues/758#issuecomment-262158231 https://github.com/Microsoft/BashOnWindows/issues/1121

For folks who really need this now, and who have Windows 10 Pro, one solution that is a bit more complicated but still quite usable is to setup a Linux VM in Hyper-V and enable X11 forwarding via VcXsrv or MobaXterm; don't bother with Xming because it is slow and doesn't support newer X11 features needed to launch Code this way.

Since Hyper-V is a type-1 native hypervisor like KVM, it's very efficient, probably about as fast or faster than running programs through WSL. There's more memory overhead but even that isn't too bad since you can setup the hypervisor to use dynamic memory allocation so you don't need to dedicate a fixed large chunk of memory just to run the VM.