Scoop-extras: vscode remote doesn't work for wsl

[ksawerykarwacki]

We should be able to run code . within wsl and open remote session instead message shows and code starts without starting remote session.

Message:

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

Steps to reproduce:

1. Install vscode from extras
2. Install Remote Development extension
3. Run ubuntu.exe
4. Within terminal run cd /
5. Run code .

If vscode is installed using exe installer instead of using scoop everything works correctly.

[ebugusey]

I think it's an upstream issue.
vscode manifest setup to create shim like this:

"bin": [
    [
        "bin\\code.cmd",
        "code"
    ]
],

scoop creates 3 shims for this instruction:

1. code.cmd
2. code.ps1
3. code - this is a shell script, which is run when you type code . in wsl or git-for-windows.

The problem is, this script actually runs cmd.exe:

MSYS2_ARG_CONV_EXCL=/C cmd.exe /C "C:\Users\User\scoop\apps\vscode\current\bin\code.cmd"  "$@"

But when you install vscode with installer it adds bin directoroy in it's root to PATH. This directory contains to files to run vscode:

1. code.cmd
2. code - which should be run in wsl and git-for-windows instead for code.cmd.

Why it's an upstream issue and you just can't add another shim for correct file? Because you can't.

[AlJohri]

@ebugusey thanks for the detailed explanation! Unfortunately, I'm still a little confused.

When I install it via the regular installer, I can see that this has been added to my PATH: /mnt/c/Users/aljoh/AppData/Local/Programs/Microsoft VS Code/bin. And the code script still calls cmd.exe:

$ cat "$(which code)" | grep -n cmd
33:                     cmd.exe /C ".\\bin\\$APP_NAME.cmd --locate-extension $WSL_EXT_ID >%TEMP%\\remote-wsl-loc.txt"
34:                     WSL_EXT_WLOC=$(cmd.exe /C type %TEMP%\\remote-wsl-loc.txt)

So when it is installed via scoop, what's the issue with calling cmd.exe? Are you saying that .\\bin\\$APP_NAME.cmd doesn't exist?

Also, can you suggest a manual fix? Is it as simple as just adding this path to the PATH variable?

[AlJohri]

Seems like this is a pretty major issue, especially with WSL 2 now out. Here's another stack overflow user talking about it, for reference: https://stackoverflow.com/questions/61268923/cant-launch-vs-code-from-windows-terminal-inside-wsl-2

[ebugusey]

@AlJohri

And the code script still calls cmd.exe

Complete code:

        if [ $WSL_BUILD -ge 41955 -a $WSL_BUILD -lt 41959 ]; then
            # WSL2 workaround for https://github.com/microsoft/WSL/issues/4337
            CWD="$(pwd)"
            cd "$VSCODE_PATH"
            cmd.exe /C ".\\bin\\$APP_NAME.cmd --locate-extension $WSL_EXT_ID >%TEMP%\\remote-wsl-loc.txt"
            WSL_EXT_WLOC=$(cmd.exe /C type %TEMP%\\remote-wsl-loc.txt)
            cd "$CWD"
        else

This is some kind of workaround for certain builds of WSL.

So when it is installed via scoop, what's the issue with calling cmd.exe?

Problem is not in cmd, at least I don't think so. Problems is that scoop runs incorrect start script for code. Shell script handles code start better in shell environment. As you can see there are some workarounds and stuff there.

Also, can you suggest a manual fix?

There actually two ways.

Fix manifest

Imitate vscode installer and add bin directory to PATH. It's against what scoop is, but scoop is capable of that. You will need to fix vscode _manifest_ and merge it through PR to this repository.

Fix shim

Every time you update vscode you will need to fix code _shim_.

You will need to replace something like this

MSYS2_ARG_CONV_EXCL=/C cmd.exe /C "C:\Users\User\scoop\apps\vscode-portable\current\bin\code.cmd"  "$@"

with something like this

/c/Users/User/scoop/apps/vscode-portable/current/bin/code "$@"

[david-bakin]

Shim fix by @ebugusey is correct.

[david-bakin]

I'm wondering if the shim fix by @ebugusey should be considered a general scoop feature request: If the target apps installer has a no-extension shell script in its bin directory, the generated shim should trampoline to it rather than to the windows batch file via cmd.exe?

And if so, should that be a separate issue that specifically says so?

Might become useful in general for other applications which (will) operate in a windows-client linux-server mode as Windows+WSL becomes a more popular development environment.

[chadrien]

More precisely, @ebugusey solution works because the problem is that scoop is creating a shim that looks incomplete if you compare it to what the shell bin provided by vscode looks like ($SCOOP_PATH/apps/vscode/bin/code).

I guess this is a super edge case: vscode might be the only program out there that is providing a wsl/shell compatible bin, but it would be nice still if scoop would provide a way in app manifest to say "don't autogenerate the shell shim, use that file instead"

[taro-ball]

I have the same issue, can you fix it please?
```PS C:\Users\pa> scoop -v
Current Scoop version:
643cfb0d (HEAD -> master, tag: 2020-10-22, origin/master, origin/HEAD) Merge branch 'develop' into master

'extras' bucket:
45d9f5be6 (HEAD -> master, origin/master, origin/HEAD) kate: Update to version 20.08.2-1057

'main' bucket:
b0214b15 (HEAD -> master, origin/master, origin/HEAD) consul: Update to version 1.8.5```