We don't support this at the moment.

Tyriar on 3 Oct 2016

👎1

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

sujaysarma on 4 Oct 2016

👍4

@sujaysarma code --verbose should give you some info

Tyriar on 4 Oct 2016

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".
capture

sujaysarma on 5 Oct 2016

👎11 👍7 😄1

@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.

Tyriar on 5 Oct 2016

👍18 👎12

+1

MathiasMagnus on 23 Oct 2016

+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.

jonomacd on 6 Jan 2017

👍68 😄12 🎉7

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

csholmq on 10 Jan 2017

👍16 😕6 ❤2 👎2

@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).

Tyriar on 10 Jan 2017

@Tyriar How did it work?

MathiasMagnus on 10 Jan 2017

@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.

Tyriar on 10 Jan 2017

@Tyriar Oh, my mistake.

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

csholmq on 10 Jan 2017

@csholmq yeah I think it was. Woo progress :wink:

Tyriar on 10 Jan 2017

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!

CherryDT on 12 Jan 2017

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 on 13 Jan 2017

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

Tyriar on 13 Jan 2017

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 on 13 Jan 2017

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 on 13 Jan 2017

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 on 14 Jan 2017

Forked the relative path issue to https://github.com/Microsoft/vscode/issues/18536 as it's going into the release.

Tyriar on 14 Jan 2017

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.

figuerres on 2 Feb 2017

👎58 👍13

@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.

Tyriar on 2 Feb 2017

👍5

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 ..

ryansully on 3 Feb 2017

@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.

Tyriar on 3 Feb 2017

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

rbirkby on 3 Feb 2017

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 ....

figuerres on 3 Feb 2017

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

@figuerres good to hear :smiley:

Tyriar on 3 Feb 2017

+1

abdullah2993 on 9 Feb 2017

+1

damekr on 20 Feb 2017

+1

rjgonza on 10 Mar 2017

😄1

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.

int19h on 17 Mar 2017

👍3

This is what happens on 1703:

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

slikts on 13 Apr 2017

+1
Notepad works, Code does not.

Mohamed3on on 16 Apr 2017

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 =>

oshalygin on 17 Apr 2017

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

csholmq on 17 Apr 2017

👍1

@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.

Tyriar on 18 Apr 2017

👍1

@csholmq i have fixed the realpath error with:

sudo apt-get install realpath

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

gordonbondon on 26 Apr 2017

👍18 ❤3 🎉2

@gordonbondon Nice, that fixed it!

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

csholmq on 26 Apr 2017

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?

MathiasMagnus on 26 Apr 2017

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.

khuongduybui on 27 Apr 2017

👍9 🎉1

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.

MathiasMagnus on 27 Apr 2017

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

kennethreitz42 on 30 Apr 2017

@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 on 30 Apr 2017

@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).

khuongduybui on 30 Apr 2017

👍1

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.

masonk on 5 May 2017

@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!

CherryDT on 5 May 2017

@CherryDT Oops. My mistake. Carry on then!

masonk on 5 May 2017

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

figuerres on 5 May 2017

👎1 👍1

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

crcrewso on 9 May 2017

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.

ghost on 12 May 2017

👍4 👎1

Wow, thanks @freebroccolo and @therealkenc for the thorough investigation. It is good to see that people actually involved with VS Code (and related tech) actually do deep investigation.

I teach HPC programming to physicist students and because I don't want to restrict my students to using a specific OS, we teach cross-plat tools and VS Code is the IDE of choice. It would be really nice if I could demo both the Windows and the Linux experience on the spot each for installing dependencies, building and debugging.

MathiasMagnus on 12 May 2017

👍1

@freebroccolo Thank you for your explanation, its quite helpful.

I have found Hyper-V quite lacking in a number of areas, least of which is writing single install configuration guides for multiple systems. WSL is a lot easier to teach people to install in a short amount of time who have Linux knowledge but not necessarily VM knowledge.

We are quite close with WSL, the last thing missing is editors. VS Code is my personal recommendation but if we can't get it to work then I'll figure something else out.

@MathiasMagnus Completely Agree!!!

crcrewso on 12 May 2017

@crcrewso For what it's worth, Sublime Text 3 works perfectly fine.

khuongduybui on 12 May 2017

@khuongduybui Great news. Last time I looked at sublime it didn't.

crcrewso on 12 May 2017

Just a +1 that installing realpath worked for me too. Maybe it could just be documented and then this could be considered fixed?

cfjedimaster on 13 Jun 2017

Considered fixed? Could you give a step-by-step tutorial on how you got it working? Are you talking about launching the native linux client under WSL and have the window show up through Xming?

MathiasMagnus on 13 Jun 2017

Sorry - I thought the main issue was -launching the Windows code.exe from WSL. And as installing realpath worked for folks, it may be a good solution. If I misread, ignore me (but add me to the list of folks who had success with that tip!)

cfjedimaster on 13 Jun 2017

The main issue I have with running the Windows code.exe is it CANNOT work with the Linux file system.
The main issue I have with working with the Windows file system is it messes up executable bits.

khuongduybui on 13 Jun 2017

@khuongduybui just keep your files under C. Don't forget you can get there from WSL. So for ex, I was in /mnt/c/projects/foo. I typed "code .", and WSL launched Code and it had the proper path (c:\projects\foo).

cfjedimaster on 13 Jun 2017

@cfjedimaster @kheiakiyama you might find some success moving your development somewhere under /mnt/c, but be aware that there are caviats; notably, all files are root.root and no such thing as symbolic links (so you'll have problems with npm and bower, along their like).

davidmaxwaterman on 13 Jun 2017

@davidmaxwaterman Can you give an example of a problematic NPM package? I have been using node, nom and yarn for short time now, and there were no issues so far.
Sometimes it is necessary to cd to /c/... because path translation breaks (symlink /mnt/c to /c).

sladiri on 13 Jun 2017

@sladiri it's not packages, per se, that are the problem, but using npm itself - eg the whole npm link mechanism, and, similarly for bower link. If I do this inside WSL, and then try to use vscode outside, then it completely fails on the linked code, causing errors and lost functionality because it thinks the code isn't there.

davidmaxwaterman on 13 Jun 2017

👍2

I think you are talking about WSL symlinks working differently than Windows symlinks and/or junction points.

For reference, the relevant issues are:
https://github.com/Microsoft/BashOnWindows/issues/353
https://github.com/Microsoft/BashOnWindows/issues/559
https://github.com/Microsoft/BashOnWindows/issues/1475

CherryDT on 13 Jun 2017

Well, I don't know about 'differently' - I'd say 'not at all' :) - but, yeah.

davidmaxwaterman on 13 Jun 2017

WSL symlinks work in WSL but not in Windows, Windows symlinks work in Windows but not in WSL, due to different semantics, that's what I meant.

CherryDT on 13 Jun 2017

WSL symlinks work in WSL but not in Windows, Windows symlinks work in Windows but not in WSL

Which are, for anyone counting, different than (default) symlinks in Cygwin / MSYS2 / Git Shell, and different than symlinks in Windows NFS client mounts. And different than directory junction points. Due to, reasons.

therealkenc on 13 Jun 2017

I'm led to believe that a solution to links not working in Windows is being worked on, right?

davidmaxwaterman on 13 Jun 2017

@cfjedimaster that's what I'm doing right now, but I cannot keep track of executable bits when working in /mnt/, everything is 777 there.

khuongduybui on 13 Jun 2017

It seems to me that what is being proposed here by the OP is that from within WSL a user should be able to launch a native Linux GUI app within Windows. Isn't that beyond scope for WSL?

If you want to do this then running an actual Linux guest in a VM (with Hyper-V, VMWare, etc) would be the better solution. As a MacOS user I too am looking at Windows + WSL these days and looking to duplicate my longtime setup. The thing is: on MacOS, when you launch VSCode from the CLI, you end up launching the native app and everything just works. It would be desirable (!) that the native VSCode on Windows could duplicate this behavior; furthermore, because the real solution would be native it would be more efficient.

Perhaps what's really needed is some way to configure and pass a working context up to Windows for use by the called binary (e.g. VSCode). The idea is that the native app would continue to resolve all of its personal dependencies (e.g. shared libraries) within Windows but resolve all other paths within the working context. I suppose VSCode could implement this support itself but since this is a problem that affects other apps being launched the same way perhaps it should just be a standard interface in WSL.

markeissler on 5 Jul 2017

👍2

@markeissler unfortunately due to the way files are handled on windows it does not play well at all with files that are also being interacted with by tools in WSL. Being able to launch the linux version of code would mean that we don't need an entire VM running just to run one application. VM's have their own issues such as a greater drain on battery for a laptop and a bigger overhead in terms of memory and processor usage and a poorer GUI performance experience compared to native. The ideal solution would be a native xserver interface to support WSL but failing that being able to use XLaunch/VcXsrv to display GUI apps is great. This already works for a great many applications with no extra work needed. I am already able to install run the entire LXDE desktop environment and a great many development tools so this is obviously already well on the way to being possible. Being able to use VS Code would mean I finally no longer need to dual boot into Ubuntu for my daily work and can stay in Windows the whole time. As I use a Surface Book this would be especially awesome as I would have the touch screen capabilities which I lose by using native Ubuntu.

mredbishop on 7 Jul 2017

@mredbishop Just to be clear, I 100% understand the pain point you are trying to express here and the shortcut solution you are proposing. For me this is an experiment on a spare laptop as I'm hopeful the other shoe will drop soon and something will change to make a transition from macOS to Windows 10 + DSL seamless. At the moment, we are so far far away from that. I'd describe the current state of WSL as "doable" but "awkward" and therefore "not efficient".

Case in point: I've spent the greater part of a day trying to figure out how to setup an ideal node development environment with native VSCode and everything else in WSL. As you know, it's simply not doable without a dual installation (node on Windows and node on WSL). The same would be true for Go and anything else where you have VSCode plugin dependencies that need to call node utilities to handle code assistance, repl, etc.

The practical problems with an XServer is that:

applications on the Linux side need to support operating as a client
you end up with a reverse problem where Windows is invisible to the client
and then all of the esthetics of the whole thing

For that last point you mentioned this about VMs:

a poorer GUI performance experience compared to native

Well, the same is certainly true for an XServer-based solution.

And about this:

VM's have their own issues such as a greater drain on battery for a laptop and a bigger overhead in terms of memory and processor usage

I'll give you the battery drain issue but "overhead?" Sure it's true but I take it you are using recent and capable hardware? Even my daily driver (a 2012 MBP) has 16GB RAM and a quad core i7--it's more than capable of handling multiple VMs despite its age.

I think if MS really wanted to support a native XServer solution, then it would have made more sense to have just created a solution using hyper-v to genuinely run Linux. Combine that with the upcoming VM store (or whatever it's called) and everyone would have been super happy. But it still wouldn't be a 1:1 comparison with the efficiency of using macOS with native *nix underpinnings where you don't have to worry about silly things like corrupting files because there are actually two incompatible file systems involved.

So I still think this needs a native working context solution wherein the primary context would be Windows for a native app, and one or more additional working context objects could be made available to the app like a bash working context. The context would define things like the target operating directory, with its associated PATHs, file access restrictions, etc. So that an app which supports additional contexts could leverage this information for use in a safe manner.

For example. VSCode with context support could have a node plugin which could use a bash context to potentially use IPC (or some other mechanism) to connect to a bash instance to run all of its commands while VSCode could continue to access the native file system for its own dependencies, including other plugins, etc. This could all be implemented experimentally with a less efficient client/server process (e.g. a daemon running in bash.exe).

Simply opening a file in bash with a Windows app would create such a context.

I think this would solve your needs, would it not?

markeissler on 27 Jul 2017

👍8

KindDragon on 18 Aug 2017

Meet this issue, too. And also request this feature in the future.

huzq85 on 3 Sep 2017

code command works for me in Bash on Ubuntu on Windows (Windows 10 15063.608 1703).

For example: code --diff index_1.js index_2.js to show difference between files in VSCode.

Also in VSCode bin directory I have bash script:

$ cd "/mnt/c/Program Files (x86)/Microsoft VS Code/bin"
$ ls -aF
./  ../  code*  code.cmd*
$ cat code
#!/usr/bin/env bash
#
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See License.txt in the project root for license information.

NAME="Code"
VSCODE_PATH="$(dirname "$(dirname "$(realpath "$0")")")"
ELECTRON="$VSCODE_PATH/$NAME.exe"
if grep -q Microsoft /proc/version; then
        # If running under WSL don't pass cli.js to Electron as environment vars
        # cannot be transferred from WSL to Windows
        # See: https://github.com/Microsoft/BashOnWindows/issues/1363
        #      https://github.com/Microsoft/BashOnWindows/issues/1494
        "$ELECTRON" "$@"
        exit $?
fi
if [ "$(expr substr $(uname -s) 1 9)" == "CYGWIN_NT" ]; then
        CLI=$(cygpath -m "$VSCODE_PATH/resources/app/out/cli.js")
else
        CLI="$VSCODE_PATH/resources/app/out/cli.js"
fi
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"
exit $?
$ cat code.cmd
@echo off
setlocal
set VSCODE_DEV=
set ELECTRON_RUN_AS_NODE=1
call "%~dp0..\Code.exe" "%~dp0..\resources\app\out\cli.js" %*
endlocal%
$

My VSCode config:

// Place your settings in this file to overwrite the default settings
{
    "editor.fontSize": 17,
    "editor.fontFamily": "Fira Code Regular",
    "editor.fontWeight": "normal",
    "editor.tabSize": 4,
    "editor.cursorStyle": "line-thin",
    "git.enabled": true,
    "explorer.openEditors.visible": 0,
    "explorer.enableDragAndDrop": true,
    "files.encoding": "utf8",
    "files.eol": "\r\n",
    "files.insertFinalNewline": true,
    "files.autoSave": "off",
    "window.openFilesInNewWindow": "default",
    "editor.renderWhitespace": "none",
    "window.zoomLevel": 0,
    "workbench.startupEditor": "welcomePage",
    "editor.lineHeight": 24,
    "editor.fontLigatures": true,
    "terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe",
    "workbench.colorTheme": "Material Theme",
    "workbench.iconTheme": "eq-material-theme-icons",
    "editor.minimap.enabled": true,
    "editor.dragAndDrop": true,
    "editor.minimap.renderCharacters": false,
    "editor.cursorBlinking": "blink",
    "workbench.activityBar.visible": true,
    "workbench.statusBar.visible": true,
    "editor.mouseWheelZoom": false,
    "editor.renderIndentGuides": true,
    "editor.renderLineHighlight": "all",
    "editor.multiCursorModifier": "ctrlCmd",
    "editor.matchBrackets": false,
    "diffEditor.renderSideBySide": true,
    "extensions.autoUpdate": false,
    "editor.quickSuggestions": {
        "other": true,
        "comments": false,
        "strings": false
    },
    "subtleBrackets.disableNative": true,
    "subtleBrackets.parse": true,
    "subtleBrackets.styles": {
        "global": {
            "borderWidth": "1px",
            "borderStyle": "none none solid none",
            "borderColor": "#FFCC00"
        }
    },
    "editor.find.seedSearchStringFromSelection": true,
    "editor.find.autoFindInSelection": true,
    "editor.selectionHighlight": true,
    "editor.occurrencesHighlight": true,
    // https://github.com/Microsoft/TypeScript/issues/6209
    "typescript.disableAutomaticTypeAcquisition": false,
    "editor.colorDecorators": false,
    "window.restoreWindows": "all",
    "extensions.ignoreRecommendations": true,
    "editor.smoothScrolling": true,
    "selectline.alignment": "right",
    "editor.parameterHints": true,
    "emmet.includeLanguages": {
        "ejs": "html"
    }
}

Zx-EvM on 26 Sep 2017

Is that they Linux install of node or just the windows install being
executed from bash?

On Tue, 26 Sep 2017, 10:11 pm Mikhail, notifications@github.com wrote:

code command works for me in Bash on Ubuntu on Windows (Windows 10
15063.608 1703).

For example: code --diff index_1.js index_2.js to show difference between
files in VSCode.

Also in VSCode bin directory I have bash script:

$ cd "/mnt/c/Program Files (x86)/Microsoft VS Code/bin"
$ ls -aF
./ ../ code* code.cmd*
$ cat code

!/usr/bin/env bash

#

Copyright (c) Microsoft Corporation. All rights reserved.

Licensed under the MIT License. See License.txt in the project root for license information.

NAME="Code"
VSCODE_PATH="$(dirname "$(dirname "$(realpath "$0")")")"
ELECTRON="$VSCODE_PATH/$NAME.exe"
if grep -q Microsoft /proc/version; then
# If running under WSL don't pass cli.js to Electron as environment vars
# cannot be transferred from WSL to Windows
# See: https://github.com/Microsoft/BashOnWindows/issues/1363
# https://github.com/Microsoft/BashOnWindows/issues/1494
"$ELECTRON" "$@"
exit $?
fi
if [ "$(expr substr $(uname -s) 1 9)" == "CYGWIN_NT" ]; then
CLI=$(cygpath -m "$VSCODE_PATH/resources/app/out/cli.js")
else
CLI="$VSCODE_PATH/resources/app/out/cli.js"
fi
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"
exit $?
$ cat code.cmd
@echo off
setlocal
set VSCODE_DEV=
set ELECTRON_RUN_AS_NODE=1
call "%~dp0..Code.exe" "%~dp0..\resources\app\outcli.js" %*
endlocal%
$

My VSCode config:

// Place your settings in this file to overwrite the default settings
{
"editor.fontSize": 17,
"editor.fontFamily": "Fira Code Regular",
"editor.fontWeight": "normal",
"editor.tabSize": 4,
"editor.cursorStyle": "line-thin",
"git.enabled": true,
"explorer.openEditors.visible": 0,
"explorer.enableDragAndDrop": true,
"files.encoding": "utf8",
"files.eol": "\r\n",
"files.insertFinalNewline": true,
"files.autoSave": "off",
"window.openFilesInNewWindow": "default",
"editor.renderWhitespace": "none",
"window.zoomLevel": 0,
"workbench.startupEditor": "welcomePage",
"editor.lineHeight": 24,
"editor.fontLigatures": true,
"terminal.integrated.shell.windows": "C:\Windows\sysnative\bash.exe",
"workbench.colorTheme": "Material Theme",
"workbench.iconTheme": "eq-material-theme-icons",
"editor.minimap.enabled": true,
"editor.dragAndDrop": true,
"editor.minimap.renderCharacters": false,
"editor.cursorBlinking": "blink",
"workbench.activityBar.visible": true,
"workbench.statusBar.visible": true,
"editor.mouseWheelZoom": false,
"editor.renderIndentGuides": true,
"editor.renderLineHighlight": "all",
"editor.multiCursorModifier": "ctrlCmd",
"editor.matchBrackets": false,
"diffEditor.renderSideBySide": true,
"extensions.autoUpdate": false,
"editor.quickSuggestions": {
"other": true,
"comments": false,
"strings": false
},
"subtleBrackets.disableNative": true,
"subtleBrackets.parse": true,
"subtleBrackets.styles": {
"global": {
"borderWidth": "1px",
"borderStyle": "none none solid none",
"borderColor": "#FFCC00"
}
},
"editor.find.seedSearchStringFromSelection": true,
"editor.find.autoFindInSelection": true,
"editor.selectionHighlight": true,
"editor.occurrencesHighlight": true,
// https://github.com/Microsoft/TypeScript/issues/6209
"typescript.disableAutomaticTypeAcquisition": false,
"editor.colorDecorators": false,
"window.restoreWindows": "all",
"extensions.ignoreRecommendations": true,
"editor.smoothScrolling": true,
"selectline.alignment": "right",
"editor.parameterHints": true,
"emmet.includeLanguages": {
"ejs": "html"
}
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/13138#issuecomment-332336985,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABC6ZZKkol43egbU98uiluzMqmA4HmvIks5smWiTgaJpZM4KME2Z
.

mredbishop on 27 Sep 2017

@mredbishop I have installed Node.js in Windows and in WSL. VSCode installed only in Windows. And I running VSCode with code command from bash on windows console.

Zx-EvM on 27 Sep 2017

~~deleted as launching Windows binary is irrelevant to this thread~~

mloskot on 27 Sep 2017

For newcomers who do not read through the thread, here is a reminder as a quote:

...this thread is about launching LINUX NATIVE VSCode inside Ubuntu on Windows with XMing serving as X-server on the Windows host.

It is unfortunate that the scenario was not emphasized by the OP in the title, but the first 30 or so posts all targeted this scenario. Please, do not spam the thread with launching the Windows binary, because (I believe) most of us here want to work on the WSL filesystem with Ubuntu dependencies and all, but the Windows binary cannot create files on the linux filesystem.

MathiasMagnus on 27 Sep 2017

👍9

@MathiasMagnus Thanks for that, I missed lots of details and confused the topic. I've removed my extensive report, will safe it for the relevant occasion :)

mloskot on 27 Sep 2017

@Tyriar

regarding your commit 9c298b09782e3dddc473bf6368521b81a122d6f4, have you considered a workaround like this (should be okay until WSL provides an easier way to pass env variables):

if grep -q Microsoft /proc/version; then
    ELECTRON=$(wslpath -m $ELECTRON)
    CLI=$(wslpath -m "$VSCODE_PATH/resources/app/out/cli.js")
    cmd.exe /c "set ELECTRON_RUN_AS_NODE=1 & $ELECTRON $CLI $@"
    exit $?
fi

This works as expected and I can call with options. You would need to implement wslpath yourself. I don't know what tools you can depend on otherwise I would have made a PR.

A python implementation of wslpath (wouldn't it be great if WSL provided this automatically?) is available here (MIT License).

A bash implementation is available here (UNLICENSE).

nshtg on 24 Oct 2017

@nshtg I think something like that would work fine, I'd prefer not to have too much code inside the launch script, perhaps we could inline just the necessary parts of https://github.com/darealshinji/scripts/blob/master/wslpath ?

Tyriar on 29 Oct 2017

@nshtg How did you get that to work in the end? I tried your modification but I get an error of "The system cannot find the path specified".

My set up is:

Running WSL (Fall 2017)
MobaXterm running on Windows
WSL is running Ubuntu
VSCode is installed within WSL following the Ubuntu instructions

It's worth mentioning that Sublime Text 3 when installed on WSL works flawlessly.

What I did:

Took the bash implementation of wslpath and dropped it in /usr/bin and made it executable.

Modified the bottom of my /usr/bin/code file from WSL to look like this:

ELECTRON="$VSCODE_PATH/code"
#CLI="$VSCODE_PATH/resources/app/out/cli.js"
#ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"
#exit $?

if grep -q Microsoft /proc/version; then
    ELECTRON=$(wslpath -m $ELECTRON)
    CLI=$(wslpath -m "$VSCODE_PATH/resources/app/out/cli.js")
    cmd.exe /c "set ELECTRON_RUN_AS_NODE=1 & $ELECTRON $CLI $@"
    exit $?
fi

When I run code . I get "The system cannot find the path specified.".

I tried a few modifications too, such as removing all of the Windows related stuff from your snippet.

For example, VSCode 1.18 when installed within WSL normally looks like this on the bottom of the file:

ELECTRON="$VSCODE_PATH/code"
CLI="$VSCODE_PATH/resources/app/out/cli.js"
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"

exit $?

I tried using wslpath in the same spots as you but then it threw an error of "/usr/bin/code: line 39: C:/Users/Nick/AppData/Local/lxss/rootfs/usr/share/code/bin/../code: No such file or directory" and at that point I figured it's time to post the issue on GitHub because I'm potentially treading in dangerous waters.

My end goal:

Ideally what I'd like to be able to do is run VSCode and edit files that are mounted into WSL but I would like VSCode to know that things like Ruby, Python, Node.JS and Git are all installed within WSL (so I can take advantage of linters and things of that nature).

Personally I don't mind if VSCode ends up being installed directly on Windows if the above is possible somehow, but one thing is for sure. I do not plan to install any programming language run-times or Git directly on Windows.

nickjj on 17 Nov 2017

This thread is about launching LINUX NATIVE VSCode inside Ubuntu on Windows with XMing serving as X-server on the Windows host.

I'm getting the following error as of now.

`user@user-bay:/usr/bin$ code --verbose .

[1463:1117/151007.048895:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
[1463:1117/151007.048987:WARNING:audio_manager.cc(254)] Multiple instances of AudioManager detected
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast`

tushrimali on 18 Nov 2017

👍3

@nickjj
I don't have it configured at the moment (I'm busy with important exams) but after a first look you should check what $VSCODE_PATH is set to in your script.

From the error messages I suspect it resolves to C:/Users/Nick/AppData/Local/lxss/rootfs/usr/share/code/bin/.. so you should figure out where those two dots at the end come from.

Oh and yes you cant really start the linux version of vscode on windows anyways, what I did is start the windows version from the WSL bash.

nshtg on 18 Nov 2017

But we're talking about starting the Linux version of VSCode within WSL, not Windows directly, and then using X server to bind the display to Windows.

This way VSCode has access to your programming environment within WSL (like Ruby, Python or whatever languages you use).

As of VSCode 1.18 (I dunno about earlier), you don't have to do anything extra to launch code . (the Windows version) from within WSL. It works out of the box, but this isn't a proper development environment because you lose autocomplete, linting and all knowledge of whatever libraries you use since VSCode has no idea about your programming environment.

nickjj on 18 Nov 2017

@nickjj So, at the moment, to use native win lib is the only choice to fully leverage vscode’s power.
And git bash is better in replacing cmd.

mzvast on 18 Nov 2017

@mzvast Replacing WSL isn't really an option for me.

I suppose I'll stick with Sublime Text until Windows VSCode can fully understand WSL (or Linux VSCode runs inside of WSL with X server).

nickjj on 18 Nov 2017

If you want to use full native linux power I suppose using a vm or doolboat is the better option.

I intended to use WSL as a replacement for cygwin as a daily-use console on windows. To ssh to other servers, use git etc.

nshtg on 18 Nov 2017

I spent the last 5 years using vmware's Unity mode for full time development. While it was ok it has too many edge cases to enjoy using it and virtualbox's seamless mode doesn't support key things like dual monitors.

Dual booting isn't an option either because my business relies on recording a Linux development environment and audio / video processing on Linux isn't in the same galaxy as Windows.

This WSL set up with X server and running Sublime Text is the best of both worlds, but yeah, no VSCode it seems for now. Hopefully something will change in the near future.

nickjj on 18 Nov 2017

@nickjj I'm late to the party, but code . was my first show stopper and so I found this issue.

I had to change line 119 of the wslpath helper script to

if [ "$p" == "." ]; then
  p=$(pwd)
fi

# lxss=$(win_env LOCALAPPDATA)/lxss
lxss=$(win_env LOCALAPPDATA)/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState

to have correct Windows paths.
I've installed VSCode with Chocolatey on Windows.
In the WSL bash shell I then fixed the code bash helper script with

vi "$(which code)"

In line 14 I added the wslpath helper script

        "$ELECTRON" "$(wslpath -w $@)"

Now I can code . or code ~/bin to open some folders 😃
But I guess there are a lot more situations I will run into with the conflicting paths...?

StefanScherer on 20 Nov 2017

@StefanScherer Hmm, I'm not sure about all of that.

If you have VSCode installed on Windows then you should be able to launch code . through WSL without having to configure anything special -- this was the case with VSCode Insiders at least.

Were you not able to do that by default?

nickjj on 20 Nov 2017

@nickjj Nope, both code . and atom . just opened C:Windows\system32. That's why I started to look for solutions.

I'm running a Windows 10 1709 VM in Azure, installed WSL and Ubuntu, then installed Atom + VSCode with Chocolatey.

StefanScherer on 20 Nov 2017

I'm also running 1709 but through Windows Pro on my desktop. I installed VSCode using the default installer on VSCode's site, not Chocolatey. Maybe the default installer sets up those shortcuts?

nickjj on 20 Nov 2017

@StefanScherer I'm not terribly familiar with this and I'm trying to setup my windows box to run bash and open code, where is the wslpath script located? I'm trying to access it and edit like you suggest.

Same problem as you, when i type code . it opens the windows filepath, ala C:Windows\system32. I could always type code c:/dev or whatever and that works but the whole benefit of using bash and being able to code . wherever you're located is super lost.

oshalygin on 25 Nov 2017

Please understand that this thread is about "Running VS Code native (/usr/bin/code) in WSL".

We can solve the problem of launching Windows VS Code (/mnt/c/.../code.exe) from WSL elsewhere.

khuongduybui on 25 Nov 2017

This has been emphasized so many times that it is clear people don't read through the issue thread before posting. Perhaps we should close off this issue and open a new one with a title explicit enough so newcomers don't get the wrong ideas. The opening post could summarize attempts found in this thread and list blocking issues.

MathiasMagnus on 25 Nov 2017

👍7

I'm also late to this, but I am talking about the NATIVE LINUX VERSION of code-insiders installed under WSL. The installation appeared to go fine.

nickw@DESKTOP-OREBB4V:~
$whereis code-insiders
code-insiders: /usr/bin/code-insiders /usr/share/code-insiders

I have xming installed and xeyes works fine with it.
However, when I try invoking code-insiders I get
nickw@DESKTOP-OREBB4V:~

$code-insiders 
/usr/share/code-insiders/bin/../code-insiders: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Could I be missing a package or something?

nickweavers on 18 Dec 2017

just spotted #13089, so after doing

$sudo apt-get install libgtk2.0-0 libxss-dev libgconf-2-4 libasound2

now, when running code-insiders I get a pause and then I'm back to the cmdline with no code window displayed and no error messages.
nickw@DESKTOP-OREBB4V:~

$code-insiders
nickw@DESKTOP-OREBB4V:~
$

I'm on build 17025.prerelease.171020-1626 (slow ring)

nickweavers on 18 Dec 2017

I think WSL could be Microsoft's killer app for Window 10, and an absolute game changer for dev's (resulting in an exodus of them from Mac back to Windows) if they commit enough skin into this thing and make it work as we really need it to, but as quickly as it gained interest it will wane unless the dev community see MS really committing to getting it done right. That means money, resource, and hearts and minds. Can't help feeling I'm just one of a huge number who really hope it happens.

nickweavers on 18 Dec 2017

👍2

@nickweavers thank you for not talking about launching "code.exe" from WSL. For once someone is on topic 👍

The problem is not with VSCode. It's with Blink (Chrome's fork of WebKit). Everything Blink-based, including Google Chrome and all Electron apps don't work on WSL as of latest fast ring (prerelease 4).

khuongduybui on 18 Dec 2017

It's with Blink

Actually it's not. Chrome works fine on WSL.

Idle observation: If this thread isn't about code.exe (and it arguably isn't), then its only purpose appears to be (1) +1s opining on how great it would be if native Linux VS Code worked on WSL (or not), (2) alleged off topic posts, and, (3) posts pointing out other posts are off topic. Because... there is no actionable in VS Code at present. The thread you are looking for is WSL#2293.

Yeah I'll regret pointing this out before even hitting enter. Shrug. I haven't got any down votes in a while. Just sayin'.

therealkenc on 18 Dec 2017

@therealkenc yep, 100% agree although that one's been beaten into an obscure off topic ramble too so I've closed it and opened a fresh clean one kicking off with the latest info 😃
https://github.com/Microsoft/WSL/issues/2760

mredbishop on 18 Dec 2017

For those not following the WSL github, VS Code launches on WSL as of Windows 10 Insiders 17063. From the release notes.

Support select/epoll of epoll files (previously a no-op).

+1 subtle.

If code doesn't start for you it is probable the problem is Microsoft/WSL#486 aka Microsoft/WSL#1006 (message). Long story short, you'll see an error like:

$ code --verbose
Activating service name='org.gtk.vfs.Daemon'
Successfully activated service 'org.gtk.vfs.Daemon'
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.

Your options are (1) don't install PulseAudio, (2) sudo apt purge libpulse0, (3) install the WSL PulseAudio PPA.

There are probably gotchas to be discovered, but it breathes life.

wsl-code-launch

therealkenc on 20 Dec 2017

👍14

Wow, I am really tempted to install an Insider build, but I have had so many bad experiences with those and the next stable build is still VERY FAR away. Thank you for the heads up and to anyone who had anything to do with this. Will make my life MUCH easier.

I'm in the middle of porting linux HPC analysis software, and having side-by-side debugging of the Linux version and the Windows port to see where they diverge is awesome!

MathiasMagnus on 20 Dec 2017

@MathiasMagnus may I ask - when did you last use Insiders? I switched from "mainline" to Insiders about half a year ago and I think I remember one instance where something went wrong and I had to switch to the mainline version. Maybe try it again? Heck you can install both, so it's harmless for sure. :)

cfjedimaster on 20 Dec 2017

@cfjedimaster I just want to clarify that we are talking about Windows Insider builds, not VS Code Insider builds.

khuongduybui on 20 Dec 2017

@cfjedimaster I tried it 2-3 months ago and 80% of the tile icons disappeared from my Start Menu, including nearly all of the non-app icons (Visual Studio, VS Code, etc.) and no matter how I unpined-repined them, they did not come back. Connect external monitor (so DPI change forces icon rerender...) but nothing.

Glitches like this cause me to hesitate to mess up my brand new devbox.

MathiasMagnus on 20 Dec 2017

Ah - so sorry!

cfjedimaster on 20 Dec 2017

Yep, that one hit me too... ended up having to do a Reset install which although a ball ache isn't as bad as a full reinstall. It was time consuming as I had wsl set up nicely for dev work and of course all the usual essential tools installed. Naturally it makes you a bit fearful of a repeat as not many of us have the bandwidth for that on top of our day jobs. However, I gave it another chance and (touch wood) it hasn't struck again. It's always a hard call to make though. (I stay on the slow ring now though as the Fast one did "get me" a few times back a while and is just too much of an expose for me).

nickweavers on 20 Dec 2017

Just to let you know, I updated from the stable Win10 to 17063 through the fast ring and indeed Code lights up inside WSL. Downside is, Edge also picked up new features and major instability. EVERY time Edge is not in focus and is obstructed (enters background), it fails to resume from the background and becomes indefinitely unresponsive. It is fairly hard to work this way, that the browser crashes so often.

_I would've installed 17063 in a VM to test it, but damned ASUS still did not release an AMD-v capable BIOS to my GL702ZC. 3 months after launch the BIOS is still half baked. I thought I'd give it a spin over the holidays and do a backroll if things go wrong. I'm still hesitating._

_I just checked and finally there's a new BIOS inbound._

MathiasMagnus on 29 Dec 2017

👍2

While code in wsl does open vscode properly, I'm still unable to open the correct files with code. What code /path/to/file/ does is create a new file at current directory instead of opening the file.

_Maybe wrong issue thread feel free to point me to the right path as I fail to search for the relevant issue_

ketozhang on 3 Jan 2018

👍7

mobaxterm

It is working with MobaXterm.

cybercoder on 7 Jan 2018

Thanks all, for this thread. I've got Ubuntu VS Code working on Win 10 Pro Insider v17074 with Xming x64 under Win 10 as a server. Terminal pops open my preferred Ubuntu shell, Intellisense seems to be using Unix paths... life is looking good!
It took some additional package installs: gtk, xss, asound, if I remember correctly. So don't fret if it throws a few errors along the way as you work to get it installed!

markdeloura on 23 Jan 2018

It does seem to be working. If you want to use it for C++ development however, I could not get debugging to work. If someone does the trick, let me know how it went. As far as the VS Code & WSL (Windows console) teams are concerned, neither is running any X apps supported, and hence neither is VS Code being run inside WSL is.

If you were looking for C++ development inside WSL and make any progress, please post there!

_Edit: debugging also works now. It's a temporary glitch caused by address randomization. Will be solved in coming updates and there is a workaround available until._

MathiasMagnus on 23 Jan 2018

👍3

So the solution for now is to have w10 17063 < ?

Any other workaround?

dogopupper on 25 Jan 2018

@dogopupper, Pease read the linked vscode-cpp-tools issue. It got fixed in 17083, so nothing needed, just upgrade. Debug failure was a temporary glitch in WSL regarding address randomization done by gdb.

MathiasMagnus on 25 Jan 2018

👍3

This is working again for me now after a reinstall of WSL on 17074

On Thu, 25 Jan 2018, 8:18 pm Nagy-Egri Máté Ferenc, <
[email protected]> wrote:

@dogopupper https://github.com/dogopupper, Pease read the linked
vscode-cpp-tools issue. It got fixed in 17083, so nothing needed, just
upgrade. Debug failure was a temporary glitch in WSL regarding address
randomization done by gdb.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/13138#issuecomment-360587596,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABC6ZUX4Y2DNWf57v6K_nugeQgEGQ6Xrks5tOOF5gaJpZM4KME2Z
.

mredbishop on 25 Jan 2018

This was working for me in <17083

I'm now on 17101, on builds <17083 when I use code . it would open VS Code and I could go back into the terminal and kill the session, now (on 17101) when I do that it will kill the VS Code session 🙃

spences10 on 15 Feb 2018

Nm, if I leave it for a few seconds after opening Vs code I can kill the process as before

spences10 on 16 Feb 2018

I am seeing the same as https://github.com/Microsoft/vscode/issues/13138#issuecomment-355127058; that is, code . will open Code, but doesn't open up . in it.

steveklabnik on 6 Mar 2018

Pertaining to #13138(comment). I'm on Windows Build 17074 (not the latest Insiders) and this is solved for me.

@spences10 @steveklabnik Are you sure you're trying to open folder on /mnt/drive/path/to/folder. Folder in WSL are not allowed to be edited in Windows (unless you installed VSCode for WSL)

ketozhang on 6 Mar 2018

Are you sure you're trying to open folder on /mnt//path/to/folder.

I open wsl. git clone something. cd into it. code ..

Folder in WSL are not allowed to be edited in Windows (unless you installed VSCode for WSL

I thought that restriction was lifted, and in fact, when I navigate through the menus of VSCode to open the correct directory, it works just fine. I do remember the days when it wasn't supported; I nuked my WSL install back then. I thought this was supported now. If I'm wrong, then ignore my comments :)

steveklabnik on 6 Mar 2018

👍1

My current issue is that running code . leaves the session open on the CLI. Instead, it should simply open and I should be returned to my shell prompt.

Running on build 17115.

nesl247 on 7 Mar 2018

👍3

When I type code, I get this:
/mnt/c/Program Files/Microsoft VS Code/Code.exe: Permission denied

How can I allow this? I tried:
chmod +x "/mnt/c/Program Files/Microsoft VS Code/Code.exe", but that gives me:

chmod: changing permissions of '/mnt/c/Program Files/Microsoft VS Code/Code.exe': Permission denied

phifa on 12 Mar 2018

@phifa https://github.com/Microsoft/vscode/issues/13138#issuecomment-346915874

eternalphane on 12 Mar 2018

@EternalPhane thanks, what is the recommended way? I don't see why it would make sense to re-install native code (/usr/bin/code), when I already have it installed in my Windows setup. I am eager to learn, can you help me understand?

phifa on 12 Mar 2018

@phifa https://github.com/Microsoft/WSL/issues/403

eternalphane on 12 Mar 2018

+1

rafaelh on 4 Apr 2018

👎3

I decide to use pycharm until stable win10 version can bring vscode to work.

Nekochef on 13 Apr 2018

That will be very soon. The Spring Creators Update (1803) should’ve been released this Tuesday but was delayed due to a bug. Hopefully 1-2 weeks and we’ll have it, which can spawn VS Code windows from WSL.

Feladó: Nekochef
Elküldve: 2018. április 13., péntek 19:27
Címzett: Microsoft/vscode
Másolatot kap: Nagy-Egri Máté Ferenc; Mention
Tárgy: Re: [Microsoft/vscode] Support launching VS Code from Bash on Ubuntuon Windows (#13138)

I decide to use pycharm until stable win10 version can bring vscode to work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

MathiasMagnus on 14 Apr 2018

I have the April update (Spring) and I still cannot edit WSL files in VS Code. Does it work for anyone else?

newzealandpaul on 8 May 2018

👍10

@newzealandpaul any updates on your end? have you been able to get it working?
@nesl247 I have this issue as well... did you find a fix?

drewswaycool on 2 Jun 2018

No I have not. I’ve since gone back to Mac for development.

nesl247 on 2 Jun 2018

@nesl247 @drewswaycool I recently installed WSL Ubuntu on a new laptop, not on Insider, plus the WSL VSCode etc, and it seems to be working just fine, but I'm not sure if I'm doing what you're looking for. What's the thing in particular that's broken? Maybe we can sort it out.

markdeloura on 2 Jun 2018

I'm using fish shell from the PPA detailed in the fish shell GitHub page
which I updated this morning to 2.7 I was using 2.2 before

Using code . from the terminal still leaves an open precess but if you
kill it with Ctrl + c then it doesn't kill code

I did this once so I'll probably need to test more

On Sat, 2 Jun 2018, 17:28 Mark DeLoura, notifications@github.com wrote:

@nesl247 https://github.com/nesl247 @drewswaycool
https://github.com/drewswaycool I recently installed WSL Ubuntu on a
new laptop, not on Insider, plus the WSL VSCode etc, and it seems to be
working just fine, but I'm not sure if I'm doing what you're looking for.
What's the thing in particular that's broken? Maybe we can sort it out.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/13138#issuecomment-394099358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOU1DG7OuYQvAUBGa-hBxTf-Ij-936Kks5t4r00gaJpZM4KME2Z
.

>

Regards,
Scott Spence
07960 86 3382

spences10 on 2 Jun 2018

FWIW I was able to find a pretty easy workaround that allows me to edit WSL files using my native (non-Node) version of VS Code. Use at your own risk, of course, as I may just be doing something that's wildly negligent.

After updating to the latest build, I found that running "code /path/to/file" in WSL launches VS Code but doesn't load any files unless "/path/to/file" points to somewhere on the native Windows filesystem (e.g., "/mnt/c/foo/bar.txt"), in which case it loads the files fine. I was quite pleased with the behaviour since it prevents users from messing stuff up by editing WSL files in native Windows.

It is technically possible to change this behaviour and at least allow yourself to read files from the WSL, but I don't trust myself enough to remember to never edit them. So the workaround I threw together was to use rcode and pretend that the WSL was a remote filesystem. After installing rcode on VS Code and the WSL and starting up the server in VS Code, I could then wrap the "code" command in a Bash function like the following:

function code() {
    if [ $# -eq 0 ]
    then
        # Run VS Code with no args
        command code
    else
        for file_arg in $*
        do
            # If path is in WSL, use 'rcode'; otherwise, use 'code'
            if [[ ! "$(realpath "$file_arg")" =~ ^/mnt/c($|/) ]]
            then
                rcode "$file_arg"
            else
                command code "$file_arg"
            fi
        done
    fi
}

Since it's all running locally, I didn't need to mess around with port forwarding and the like. Only downside is that rcode only seems to allow me to open one file at a time, so I've still got some tweaking to do.

ComfyDust on 6 Jun 2018

So with the Spring update (1803) we can now launch the Windows native VS Code from WSL but still cannot launch the linux native one -- best option we have is the hack that @ComfyDust explained, right?

rjgonza on 7 Jun 2018

@rjgonza Native Linux VSCode works perfectly under Windows 1803 stable without any hacks. You just need to run Xserver.

I wrote about setting all of this up at https://nickjanetakis.com/blog/using-wsl-and-mobaxterm-to-create-a-linux-dev-environment-on-windows.

nickjj on 7 Jun 2018

❤1 👍1

@nickjj Have you tried Xming or VcXsrv?

W4RH4WK on 11 Jun 2018

@W4RH4WK nope, but they should work. I chose to use mobaxterm because the free version seemed to provide the best out of the box experience for turning on / off Xserver and getting clipboard sharing to work.

nickjj on 11 Jun 2018

I'm using Ubuntu on Windows 10 with Fish 🐚and am not getting this issue anymore

spences10 on 11 Jun 2018

👍1

@ComfyDust you sir just saved my day, of course all what needed to do is just install rmate since it opens on localhost post, brilliant!

sandric on 16 Jun 2018

Does Xming support VScode?

quoder on 28 Jun 2018

👍1

I haven't been able to get it to work

rjgonza on 28 Jun 2018

👍1

I've been using Xming exclusively and it is working great.

markdeloura on 10 Jul 2018

I recently updated my PC and Ubuntu install and this behaviour is present again but Ctrl+c doesn't kill the session anymore.

spences10 on 10 Jul 2018

I'm realizing all is not puppies and roses with my current VS Code build running under WSL. In particular, if I click on the extensions button, the extensions pane will pop open and the blue cylon will go back and forth, but nothing else happens and eventually it throws two errors in the developer console similar to #50159 : "Error received from starting extension host", and "timeout".
This happens on 1.24, 1.25, 1.25.1, and current code-insiders 1.26.0-1531372980. Under Ubuntu 18.04.
Anyone else experiencing this?
EDIT: Okay, that hurts my head. As soon as I typed this I tried the latest code-insiders on my laptop, which is not on Windows 10 Insider Preview... and it worked. And then 1.25.0, and it worked. Swear this wasn't the case last night. Going to flush the WSL on both of these and start from scratch. Please let me know if you've ever had this weird extensions behavior :)

markdeloura on 13 Jul 2018

@markdeloura the purpose of this thread (as I understand it) is for the launching of VS Code from the terminal a la code . are you saying you are running VS Code from a WSL install? If so, congratulations, I didn't think it worked.

spences10 on 13 Jul 2018

This works for me fine.

I have vscode installed on windows.
I have ubuntu 16.04 installed from store
I use fish shell on WSL
I use Hyper.js Terminal

I just type code . and it opens the current folder.

alanaasmaa on 13 Jul 2018

👍2

I have the same setup as you @alanaasmaa and it does open the current folder as well, but, I have to Ctrl+c to be able to do anything else on the same console.

There was a time when doing a Crtl+c would kill off all open sessions of VS Code, seems to not do that now.

spences10 on 13 Jul 2018

👍1

Hi @spences10! Yeah to be clear, this is what I'm doing:

Fresh copy of Ubuntu 18.04 installed in WSL
Using Xming for X Server
Using Hyper.is for interface, tcsh as shell
Installed VS Code and Code-insiders via .deb files from main website, installed additional packages as necessary (ensuring that libgconf-2-4, libgtk-2.0-0, libxss1, and libasound2 are installed)

Typing code . or code-insiders . launches VS Code and returns control to the shell. VS Code appears to work great, but if I tap the Extensions bug on the left of the window, it never displays anything to do with extensions. After a bit of time the console reports the error "Error received from starting extension host" and then "timeout".

I just re-installed from scratch and still have this same result, so am beginning to think it's a new error from running on this Windows Insider build (x64, Build 17692.rs_prerelease_flt.180625-1624). I'm going to re-install on my non-Insider machine right now and see how that goes.

markdeloura on 13 Jul 2018

(x64, Build 17692.rs_prerelease_flt.180625-1624)

17692 suffers from Microsoft/WSL#3191

therealkenc on 13 Jul 2018

oooooooo thanks @therealkenc - now you make me want to switch to fast ring to see if 17704 fixes the behavior I'm seeing. Hmmmm :-)
EDIT: Thanks! I moved to build 17713 and that seemed to fix it.

markdeloura on 13 Jul 2018

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?

davidcoleman007 on 17 Jul 2018

👍1

Hey I'm not clear on if this has been fixed or not? I'm running 1803 Windows with 18.04 Ubuntu, and using Hyperterm and Zsh. I have all my configs files backed up on a dropbox folder with symlinks routing the WSL home folder etc to the cloud configs.

I can open the config files manually in Windows with VScode and edit them. I can open the config files in WSL using nano and edit them, and see those edits instantly viewable in VScode on Windows. And I can open files using VScode in WSL using the code {{filename}} command BUT the file it opens appears blank.

So... what gives? I came across an article on bash aliases and they mention the ability to open files in WSL using Atom via this alias: https://medium.com/@heinrich10/launching-windows-application-on-windows-subsystem-for-linux-wsl-60cc2c165029

alias atom=’/mnt/c/Windows/System32/cmd.exe /c “atom”’

I tried a quckie edit of changing "atom" to code to see if it would work and.... it throws an error. Might just be because I did a lazy substitution but when I run code . as in the article it opens up the Windows Home directory in explorer.exe not the WSL directory. Which makes me think that there's something else going on? I'm a designer learning how to develop so I'm still pretty new to using the CLI but if anyone can help point me in the right direction for more information or clarification I would be much obliged!

jcklpe on 17 Jul 2018

Hi @thedonquixotic ... are you sure that you're running the WSL version of code? If you type which code does it report /usr/bin/code or something more like /mnt/c/Program\ Files/Microsoft\ VS\ Code/Code.exe?

On my current machine, my version of code lives at /usr/bin/code and opens files with no trouble. But if I call the Windows version instead, it will open my Windows Home directory. That is, when I'm calling VS Code from WSL home directory :) [Using pwd to verify.]

markdeloura on 18 Jul 2018

👍1

@markdeloura Aha yeah, I've only got the windows version running. I'll fix that. Thanks!

jcklpe on 18 Jul 2018

@markdeloura what version of xming are you using?

nayato on 18 Jul 2018

Hi @nayato ... I'm using Xming 7.7.0.33

markdeloura on 18 Jul 2018

edit: As @therealkenc mentions this is only for interop, which isn't what this thread is about. Leaving below for others who might arrive here

I'm not sure this issue is still relevant. Going to list the workarounds I've found / been using here.

`code` / `code-insiders`

Both work for me when passing a directory or just from the command line.

If you see something like this, it means you're probably on the insiders build and should use code-insiders

Inside of `/mnt/c`

Since WSL and Windows share /mnt/c/ you can easily open these from bash and edit them in Windows[1]

Want to edit Windows files and edit them both in Windows and in Linux? Keep your files/code in /mnt/c/ and you can edit them with other OS. Don't use Windows to "reach into the Linux file system."

Anywhere inside of /mnt/c I can run code-insiders . ( _or code . if you're not on the insider build_) and open the current directory inside of vscode.

1 - https://www.hanselman.com/blog/TheYearOfLinuxOnTheWindowsDesktopWSLTipsAndTricks.aspx

olingern on 19 Aug 2018

👎1

Find your Ubuntu folder:
CanonicalGroupLimited.UbuntuonWindows_[xxxxxxx]\LocalState\rootfs\home\$USER

No, don't.. Full stop. If that worked, there wouldn't be an lxfs versus drvfs, now would there. Unsubstantiated rumors they are working towards it. User Voice is here.

Also someone is going to point out this thread is about running Native VS Code on WSL (with say Xming), if you look at the OP. You are using interop.

therealkenc on 19 Aug 2018

👍2

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.

MathiasMagnus on 19 Aug 2018

👍2 👎1

@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…)

FranklinYu on 21 Aug 2018

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 ?

myuseringithub on 1 Oct 2018

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.

myuseringithub on 1 Oct 2018

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

https://whitewaterfoundry.com/WLinux/

int19h on 1 Oct 2018

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.

WSLUser on 24 Oct 2018

It's still an issue for me

Is this going to be fixed in coming Windows builds?

spences10 on 24 Oct 2018

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.

therealkenc on 24 Oct 2018

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 🙏

spences10 on 24 Oct 2018

👍2

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.

markdeloura on 24 Oct 2018

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.]

therealkenc on 24 Oct 2018

👍1

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.

jaakkouu on 3 Nov 2018

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.

therealkenc on 3 Nov 2018

👍1

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

Jaff1 on 10 Dec 2018

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

MathiasMagnus on 11 Dec 2018

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.

therealkenc on 12 Dec 2018

👎2

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! :)

jcklpe on 7 Jan 2019

👍1

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

JoeRoddy on 11 Jan 2019

👎1 👍1

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.

sbonds on 20 Mar 2019

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

championbarca on 23 Apr 2019

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

RMacfarlane on 2 May 2019

🚀13 🎉11 👍10

Vscode: Support launching VS Code from Bash on Ubuntu on Windows

Most helpful comment

All 182 comments

!/usr/bin/env bash

Copyright (c) Microsoft Corporation. All rights reserved.

Licensed under the MIT License. See License.txt in the project root for license information.

>

`code` / `code-insiders`

Inside of `/mnt/c`

Support launching VS Code from Bash on Ubuntu on Windows

Related issues

Vscode: Support launching VS Code from Bash on Ubuntu on Windows

Most helpful comment

All 182 comments

!/usr/bin/env bash

Copyright (c) Microsoft Corporation. All rights reserved.

Licensed under the MIT License. See License.txt in the project root for license information.

>

code / code-insiders

Inside of /mnt/c

Support launching VS Code from Bash on Ubuntu on Windows

Related issues

`code` / `code-insiders`

Inside of `/mnt/c`