New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support launching VS Code from Bash on Ubuntu on Windows #13138

Open
sujaysarma opened this Issue Oct 2, 2016 · 177 comments

Comments

Projects
None yet
@sujaysarma

sujaysarma commented Oct 2, 2016

  • 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 Tyriar changed the title from In WSL, does not launch, no error message to VS Code does not launch or give error when running via Bash on Ubuntu on Windows Oct 3, 2016

@Tyriar

This comment has been minimized.

Member

Tyriar commented Oct 3, 2016

We don't support this at the moment.

@sujaysarma

This comment has been minimized.

sujaysarma commented Oct 4, 2016

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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Oct 4, 2016

@sujaysarma code --verbose should give you some info

@sujaysarma

This comment has been minimized.

sujaysarma commented Oct 5, 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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Oct 5, 2016

@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 Tyriar changed the title from VS Code does not launch or give error when running via Bash on Ubuntu on Windows to Support launching VS Code from Bash on Ubuntu on Windows Oct 5, 2016

@MathiasMagnus

This comment has been minimized.

MathiasMagnus commented Oct 23, 2016

+1

@jonomacd

This comment has been minimized.

jonomacd commented Jan 6, 2017

+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

This comment has been minimized.

csholmq commented Jan 10, 2017

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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 10, 2017

@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

This comment has been minimized.

MathiasMagnus commented Jan 10, 2017

@Tyriar How did it work?

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 10, 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.

@csholmq

This comment has been minimized.

csholmq commented Jan 10, 2017

@Tyriar Oh, my mistake.

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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 10, 2017

@csholmq yeah I think it was. Woo progress 😉

@CherryDT

This comment has been minimized.

CherryDT commented Jan 12, 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!

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 13, 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

This comment has been minimized.

Member

Tyriar commented Jan 13, 2017

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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 13, 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

This comment has been minimized.

Member

Tyriar commented Jan 13, 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 Microsoft/WSL#1363 & Microsoft/WSL#1494

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 14, 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 Microsoft/WSL#1363 and Microsoft/WSL#1494 it just won't work. I also tried to call into code.cmd however the --help didn't seem to work properly.

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

@Tyriar

This comment has been minimized.

Member

Tyriar commented Jan 14, 2017

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

@alanaasmaa

This comment has been minimized.

alanaasmaa commented Jul 13, 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.

@spences10

This comment has been minimized.

spences10 commented Jul 13, 2018

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.

@markdeloura

This comment has been minimized.

markdeloura commented Jul 13, 2018

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.

@therealkenc

This comment has been minimized.

therealkenc commented Jul 13, 2018

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

17692 suffers from Microsoft/WSL#3191

@markdeloura

This comment has been minimized.

markdeloura commented Jul 13, 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.

@davidcoleman007

This comment has been minimized.

davidcoleman007 commented Jul 17, 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?

@jcklpe

This comment has been minimized.

jcklpe commented Jul 17, 2018

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!

@markdeloura

This comment has been minimized.

markdeloura commented Jul 17, 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.]

@jcklpe

This comment has been minimized.

jcklpe commented Jul 17, 2018

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

@nayato

This comment has been minimized.

nayato commented Jul 18, 2018

@markdeloura what version of xming are you using?

@markdeloura

This comment has been minimized.

markdeloura commented Jul 18, 2018

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

@olingern

This comment has been minimized.

Contributor

olingern commented Aug 19, 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

@therealkenc

This comment has been minimized.

therealkenc commented Aug 19, 2018

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.

@MathiasMagnus

This comment has been minimized.

MathiasMagnus commented Aug 19, 2018

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

@FranklinYu

This comment has been minimized.

FranklinYu commented Aug 21, 2018

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

@myuseringithub

This comment has been minimized.

myuseringithub commented Oct 1, 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

This comment has been minimized.

myuseringithub commented Oct 1, 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.

@int19h

This comment has been minimized.

int19h commented Oct 1, 2018

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

https://whitewaterfoundry.com/WLinux/

@DarthSpock

This comment has been minimized.

DarthSpock commented Oct 24, 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.

@spences10

This comment has been minimized.

spences10 commented Oct 24, 2018

It's still an issue for me

Is this going to be fixed in coming Windows builds?

@therealkenc

This comment has been minimized.

therealkenc commented Oct 24, 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.

@spences10

This comment has been minimized.

spences10 commented Oct 24, 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 🙏

@markdeloura

This comment has been minimized.

markdeloura commented Oct 24, 2018

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

@therealkenc

This comment has been minimized.

therealkenc commented Oct 24, 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.]

@jaakkouu

This comment has been minimized.

jaakkouu commented Nov 3, 2018

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

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

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

After that I tried again Code .

Bob's your uncle.

@therealkenc

This comment has been minimized.

therealkenc commented Nov 3, 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.

@Jaff1

This comment has been minimized.

Jaff1 commented Dec 10, 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?

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

@MathiasMagnus

This comment has been minimized.

MathiasMagnus commented Dec 11, 2018

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

@therealkenc

This comment has been minimized.

therealkenc commented Dec 11, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment