Search code examples
bashubuntuwindows-subsystem-for-linuxchocolatey

Using Chocolatey VS Code from within WSL Ubuntu


I cannot get VS Code code.exe to run properly within WSL. (I found a connected question here, but it does not solve this issue - Launch VS Code from WSL Bash).

Within WSL (any distro) we can access any executables on Windows. e.g.

alias chrome="\"/mnt/c/Program Files/Google/Chrome/Application/chrome.exe\""  # Open Chrome from WSL
alias notepad++="\"/mnt/c/Program Files/Notepad++/notepad++.exe\""            # Open Notepad++

Typing chrome in bash will open Chrome and notepad++ ~/.bashrc would open .bashrc in Notepad++ This all works great.

However, I have hit a problem with code.exe provided by the choco inst VisualStudioCode installation. When I try:

alias vscode="\"/mnt/c/ProgramData/chocolatey/bin/code.exe\""

This fails really badly.

[main 2021-01-24T18:44:17.966Z] update#setState idle
(node:20404) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\vscode-sqlite3\build\Release\sqlite.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:20404) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:18692) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.

So, I can ignore that and just use code.exe within Ubuntu (as WSL will scan the path for executables). This sort of works but with the following error:

'\\wsl$\Ubuntu-20.04\home\boss'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

VS Code does open, but if put a filename as an argument that file fails to open (while noting that for the notepad++ example, all files open perfectly run with the above alias).

It seems to be saying that code.exe can't support UNC paths, but it does support UNC paths as I can see from PowerShell. code.exe \\HPEnvy\Drive-D\test.txt opens perfectly.

It would really round out my WSL setup to be able to open code that I'm working on seamlessly with VS Code. Does anyone have an idea why this might be happening / how to fix?


Solution

  • My installation has a shell script for launching VSCode in ../Microsoft VS Code/bin/code. I'm fairly certain that it is installed with VSCode, but there's a chance it comes from the "Remote - WSL" extension.

    Is that present in your installation? If so, add that bin directory to your path (the full installer does this automatically). Then just use code rather than code.exe to launch from within WSL.

    If not, first make sure the "Remote - WSL" extension is installed in VSCode (or better yet, the "Remote Development" extension pack, which includes the WSL support). If it's still not there after that, here are the contents of the script that should live in VSCode/bin/code:

    #!/usr/bin/env sh
    #
    # Copyright (c) Microsoft Corporation. All rights reserved.
    # Licensed under the MIT License. See License.txt in the project root for license information.
    if [ "$VSCODE_WSL_DEBUG_INFO" = true ]; then
        set -x
    fi
    
    COMMIT="ea3859d4ba2f3e577a159bc91e3074c5d85c0523"
    APP_NAME="code"
    QUALITY="stable"
    NAME="Code"
    DATAFOLDER=".vscode"
    VSCODE_PATH="$(dirname "$(dirname "$(realpath "$0")")")"
    ELECTRON="$VSCODE_PATH/$NAME.exe"
    
    IN_WSL=false
    if [ -n "$WSL_DISTRO_NAME" ]; then
        # $WSL_DISTRO_NAME is available since WSL builds 18362, also for WSL2
        IN_WSL=true
    else
        WSL_BUILD=$(uname -r | sed -E 's/^[0-9.]+-([0-9]+)-Microsoft.*|.*/\1/')
        if [ -n "$WSL_BUILD" ]; then
            if [ "$WSL_BUILD" -ge 17063 ]; then
                # WSLPATH is available since WSL build 17046
                # WSLENV is available since WSL build 17063
                IN_WSL=true
            else
                # If running under older 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
        fi
    fi
    if [ $IN_WSL = true ]; then
    
        export WSLENV="ELECTRON_RUN_AS_NODE/w:$WSLENV"
        CLI=$(wslpath -m "$VSCODE_PATH/resources/app/out/cli.js")
    
        # use the Remote WSL extension if installed
        WSL_EXT_ID="ms-vscode-remote.remote-wsl"
    
        ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --locate-extension $WSL_EXT_ID >/tmp/remote-wsl-loc.txt 2>/dev/null </dev/null
        WSL_EXT_WLOC=$(cat /tmp/remote-wsl-loc.txt)
    
        if [ -n "$WSL_EXT_WLOC" ]; then
            # replace \r\n with \n in WSL_EXT_WLOC
            WSL_CODE=$(wslpath -u "${WSL_EXT_WLOC%%[[:cntrl:]]}")/scripts/wslCode.sh
            "$WSL_CODE" "$COMMIT" "$QUALITY" "$ELECTRON" "$APP_NAME" "$DATAFOLDER" "$@"
            exit $?
        fi
    
    elif [ -x "$(command -v cygpath)" ]; 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 $?
    

    Permissions on the file are 0777. And, as mentioned above, it should be in your path.