VS Code not starting from within Github Desktop

[ArtHoff]

The problem

Hi there,

I have my editor set to Visual Studio Code in Options->Integrations->External Editor, however it will not start.
I'm using Visual Studio Code version: 1.66.2

Thanks for any advice you may be able to provide.
Kind regards,
Arthur.

Release version

Github Desktop: 2.9.15-linux1 (x64)

Operating system

Linux: 5.4.72-microsoft-standard-WSL2 #1 x86_64 GNU/Linux - Ubuntu 20.04.4 LTS

Steps to reproduce the behavior

• Go to the menu (Repository -> Open in Visual Studio Code) - Nothing happens
• click on 'Open in Visual Studio Code' in the right-click popup menu on any file - Nothing happens
• From the main click on the 'Open the repository in your external editor' button - Nothing happens
• Highlight a file and press Ctrl-Shif-A - Nothing happens
• I've also tried reinstalling Visual Studio Code - Nothing changed

Log files

2022-04-21.desktop.production.log

Screenshots

No response

Additional context

I tried the other editor option (Gnome) and that works as expected.
I noticed that Visual Studio Code will open when right clicking on a file and clicking 'Open with Default Program'.

[shiftkey]

A quick question to help on my end - where is the path to VSCode on disk? Can you launch it from the terminal (I'm assuming this is WSL based on the OS text)?

cc @aminya who contributed this support for any other troubleshooting ideas...

[ArtHoff]

Hello Brendan and @aminya

Thank you for getting back to me.

Yes, that's in WSL.

Code is located in /usr/bin.

I can start it from the menu. I can also start it from the console by calling 'code' or '/usr/bin/code'. However in the console I'm then first presented with the below message and need to enter 'y' first.

To use Visual Studio Code with the Windows Subsystem for Linux, please install Visual Studio Code in Windows and uninstall the Linux version in WSL. You can then use the code command in a WSL terminal just as you would in a normal command prompt.
Do you want to continue anyway? [y/N]

I noticed that it works as expected on a standalone Ubuntu machine (not WSL).

[shiftkey]

Thanks for that extra info. I think we're hitting some limit with mixing Win32 and Linux programs within WSL. What I think is happening is our work to resolve the path to code is matching on /usr/bin/code first (the Linux version), instead of the one at /mnt (the Windows version):

desktop/app/src/lib/editors/linux.ts

Lines 28 to 34 in 1f2c838

	name: 'Visual Studio Code',
	paths: [
	'/usr/share/code/bin/code',
	'/snap/bin/code',
	'/usr/bin/code',
	'/mnt/c/Program Files/Microsoft VS Code/bin/code',
	],

What happens if you uninstall the Linux version? Would that revert to detecting the Windows version, and avoid the /usr/bin/code path which reports this issue?

[ArtHoff]

I have uninstalled the Linux version now, for testing, and now VS Code opens on Windows. However it also opens a new, empty file called cli.js.
Actually I prefer to use the Linux version and the strange thing is that it will open the Linux version when I use the 'Open with default program' option.

[shiftkey]

However it also opens a new, empty file called cli.js.

I'm curious which path you're now locating (I guess the /mnt one) and what it's contents are. If it's a .cmd file and looks like this (but without the placeholders) I wonder if something is mucked up with the arguments and it's considering cli.js to be a file instead of the script it should launch (with our arguments being filled in at the end with the %*):

https://github.com/microsoft/vscode/blob/e08e4d3fe1079f6ccb1b781f6089d9e573b81ca6/resources/win32/bin/code.cmd

@echo off
setlocal
set VSCODE_DEV=
set ELECTRON_RUN_AS_NODE=1
"%~dp0..\@@NAME@@.exe" "%~dp0..\resources\app\out\cli.js" --ms-enable-electron-run-as-node %*
endlocal

But

Actually I prefer to use the Linux version and the strange thing is that it will open the Linux version when I use the 'Open with default program' option.

This is handled by Electron's shell.openExternal API:

desktop/app/src/ui/lib/open-file.ts

Line 8 in 1f2c838

const result = await shell.openExternal(`file://${fullPath}`)

This would be then launching the Linux version through xdg-open:

https://github.com/electron/electron/blob/31c2b5703a75a5ff2bf0e68f472d9002fe866bfb/shell/common/platform_util_linux.cc#L330-L343

We don't use this approach because we want to open a directory instead of a path. And if WSL is going to complain about /usr/bin/code pointing to the Linux version of VSCode I'm not sure what our options are here. WSL isn't something I have handy to test, so I'm mostly guessing here based on the last time I used it.

[ArtHoff]

Hello Brendan,
Now that I have uninstalled VS Code from Linux, GitHub Desktop opens the Windows version and still creates the cli.js file, however it won't open from a Linux shell.
I then added /mnt/c/Program Files/Microsoft VS Code/bin to the PATH and now it opens from Linux too, however for the first file I open it also opens a blank cli.js
Subsequent files I open from Linux are opened in new Code tab (expected) however the cli.js tag is set to be the active tab.

[shiftkey]

One thought that I have is to stay with the VSCode for Linux but opt out of the message, which blocks the script and which is likely the underlying issue - here's the relevant source:

if grep -qi Microsoft /proc/version && [ -z "$DONT_PROMPT_WSL_INSTALL" ]; then
	echo "To use @@PRODNAME@@ with the Windows Subsystem for Linux, please install @@PRODNAME@@ in Windows and uninstall the Linux version in WSL. You can then use the \`@@NAME@@\` command in a WSL terminal just as you would in a normal command prompt." 1>&2
	printf "Do you want to continue anyway? [y/N] " 1>&2
	read -r YN
	YN=$(printf '%s' "$YN" | tr '[:upper:]' '[:lower:]')
	case "$YN" in
		y | yes )
		;;
		* )
			exit 1
		;;
	esac
	echo "To no longer see this prompt, start @@PRODNAME@@ with the environment variable DONT_PROMPT_WSL_INSTALL defined." 1>&2
fi

If you set the DONT_PROMPT_WSL_INSTALL environment variable I wonder if that's a better experience for your setup

[aminya]

I didn't test my change in #703. I just used which to find the code executable when it is called from WSL and used its path here. Inside WSL, running code from that path opens it and connects it to WSL.

If this is not working, please revert the change.

[ArtHoff]

I have reinstalled VS Code in Linux again and added the DONT_PROMPT_WSL_INSTALL in /etc/profile. I also removed the path to the Windows version again and now the Linux version of VS Code starts from the shell and also when opening files from within GitHub Desktop on Linux. Everything works as expected now.
Thank you so much for coming up with a solution.

[shiftkey]

Excellent. If we hit other cases like this I'll see if we can get a better warning in place to avoid this prompt but for now I'm gonna close this out as resolved. Thanks for working through this with me!