Skip to content
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

Closed
sujaysarma opened this issue Oct 2, 2016 · 182 comments
Closed

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

sujaysarma opened this issue Oct 2, 2016 · 182 comments

Comments

@sujaysarma
Copy link

@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 In WSL, does not launch, no error message VS Code does not launch or give error when running via Bash on Ubuntu on Windows Oct 3, 2016
@Tyriar
Copy link
Member

@Tyriar Tyriar commented Oct 3, 2016

We don't support this at the moment.

@sujaysarma
Copy link
Author

@sujaysarma sujaysarma commented Oct 4, 2016

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

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Oct 4, 2016

@sujaysarma code --verbose should give you some info

@sujaysarma
Copy link
Author

@sujaysarma 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
Copy link
Member

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

@MathiasMagnus MathiasMagnus commented Oct 23, 2016

+1

@jonomacd
Copy link

@jonomacd 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
Copy link

@csholmq 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
Copy link
Member

@Tyriar 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
Copy link

@MathiasMagnus MathiasMagnus commented Jan 10, 2017

@Tyriar How did it work?

@Tyriar
Copy link
Member

@Tyriar 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
Copy link

@csholmq 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
Copy link
Member

@Tyriar Tyriar commented Jan 10, 2017

@csholmq yeah I think it was. Woo progress 😉

@CherryDT
Copy link

@CherryDT 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
Copy link
Member

@Tyriar 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
Copy link
Member

@Tyriar Tyriar commented Jan 13, 2017

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

@Tyriar
Copy link
Member

@Tyriar 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
Copy link
Member

@Tyriar 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
Copy link
Member

@Tyriar 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
Copy link
Member

@Tyriar Tyriar commented Jan 14, 2017

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

@therealkenc
Copy link

@therealkenc 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
Copy link

@MathiasMagnus 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
Copy link

@FranklinYu 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
Copy link

@myuseringithub 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
Copy link

@myuseringithub 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
Copy link

@int19h int19h commented Oct 1, 2018

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

https://whitewaterfoundry.com/WLinux/

@WSLUser
Copy link

@WSLUser WSLUser 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
Copy link

@spences10 spences10 commented Oct 24, 2018

It's still an issue for me

Is this going to be fixed in coming Windows builds?

@therealkenc
Copy link

@therealkenc 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
Copy link

@spences10 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
Copy link

@markdeloura 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
Copy link

@therealkenc 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
Copy link

@jaakkouu 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
Copy link

@therealkenc 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
Copy link

@Jaff1 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
Copy link

@MathiasMagnus MathiasMagnus commented Dec 11, 2018

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

@therealkenc
Copy link

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

@jcklpe
Copy link

@jcklpe jcklpe commented Jan 7, 2019

Just a follow up note on my earlier comment.

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

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

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

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

@JoeRoddy
Copy link

@JoeRoddy JoeRoddy commented Jan 11, 2019

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

@sbonds
Copy link

@sbonds sbonds commented Mar 20, 2019

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.

@kieferrm kieferrm mentioned this issue Apr 5, 2019
5 of 9 tasks complete
@RMacfarlane
Copy link
Contributor

@RMacfarlane RMacfarlane commented May 2, 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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet