Can't Connect to WSL Host when WSL login shell is nushell

[EjPlatzer]

• VSCode Version: 1.66.2
• Local OS Version: Windows_NT x64 10.0.19042
• Remote OS Version: Ubuntu 20.04.4 LTS
• Remote Extension/Connection Type: WSL
• Logs:

[2022-04-13 15:41:24.911] Resolving wsl+Ubuntu, resolveAttempt: 1
[2022-04-13 15:41:25.015] Starting VS Code Server inside WSL (wsl2)
[2022-04-13 15:41:25.016] Extension version: 0.66.0
[2022-04-13 15:41:25.016] Windows build: 19042. Multi distro support: available. WSL path support: enabled
[2022-04-13 15:41:25.017] No shell environment set or found for current distro.
[2022-04-13 15:41:25.355] WSL daemon log file: 
[2022-04-13 15:41:25.358] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d Ubuntu -e sh -c "[ -d ~/.vscode-server/bin/dfd34e8260c270da74b5c2d86d61aee4b6d56977 ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2022-04-13 15:41:25.612] Probing result: found
[2022-04-13 15:41:25.613] Server install found in WSL
[2022-04-13 15:41:25.615] Launching C:\WINDOWS\System32\wsl.exe -d Ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" dfd34e8260c270da74b5c2d86d61aee4b6d56977 stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=507716792-2015298620 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all'
[2022-04-13 15:41:25.817] Error: nu::parser::unknown_flag (https://docs.rs/nu-parser/0.61.0/nu_parser/enum.ParseError.html#variant.UnknownFlag)
[2022-04-13 15:41:25.817] 
[2022-04-13 15:41:25.817]   × The `nu` command doesn't have flag `host`.
[2022-04-13 15:41:25.817]    ╭─[source:1:1]
[2022-04-13 15:41:25.817]  1 │ nu -c 'sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" dfd34e8260c270da74b5c2d86d61aee4b6d56977 stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=507716792-2015298620 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all''
[2022-04-13 15:41:25.817]    ·                                                                                                                                          ────────┬───────
[2022-04-13 15:41:25.817]    ·                                                                                                                                                  ╰── unknown flag
[2022-04-13 15:41:25.817]    ╰────
[2022-04-13 15:41:25.817]   help: use nu --help for a list of flags
[2022-04-13 15:41:25.817] 
[2022-04-13 15:41:25.818] VS Code Server for WSL closed unexpectedly.
[2022-04-13 15:41:25.818] For help with startup problems, go to
[2022-04-13 15:41:25.818] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2022-04-13 15:41:25.835] WSL Daemon exited with code 0

Steps to Reproduce:

1. Install WSL with Ubuntu 20.04
2. Change Ubuntu login shell to nushell version >= 0.60
3. Try to open new remote WSL window

I have tried this with current VS Code and Insiders, with all extensions except Remote - WSL uninstalled. The issue seems to be that the shell command sh -c '...arguments' passed to wsl is getting nested in single quotes when passed to nushell (see nushell error about nu -c 'sh -c '...arguments'' where arguments are being interpreted by nu instead of sh because of doubly-nested single quotes).

I believe this a VS Code issue because this behavior of nesting inside double quotes is not reproducible. If I run wsl -d Ubuntu sh -c 'echo hello world' from PowerShell in the Windows host, I get the expected output, rather than an error from nushell: Note that this isn't nushell interpreting the echo hello world command - as we might expect if wsl is actually passing nu -c 'sh -c 'echo hello world' - because nushell treats it's data as structured tables. See this output for comparison:

Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?: No

[BatmanAoD]

It might help to understand exactly how VSCode is invoking wsl.exe; given the discrepancy between the command-line behavior and the error message, it looks like VSCode isn't giving us all the information to understand the issue.

[BatmanAoD]

It looks like the --system flag for wsl.exe ensures that a "system" shell is used rather than the configured login shell. This seems like the appropriate behavior for running scripts like this.

C:\Users\Kyle.Strand〉wsl  echo hello world                                                       04/30/2022 01:44:51 PM
╭───┬───────╮
│ 0 │ hello │
│ 1 │ world │
╰───┴───────╯
C:\Users\Kyle.Strand〉wsl -d Ubuntu --system echo hello world                                     04/30/2022 01:44:55 PM
hello world

[BatmanAoD]

I would submit a patch if I could find the file that's actually making the wsl.exe invocation...

[BatmanAoD]

For now, I've put this in my ~/.profile, and it seems to work as a way to treat nushell "as if" it were the default shell, but only in interactive mode:

# FOR NOW, use nushell as the default WITHOUT `chsh` by just running it here.
# This is *only* for interactive sessions.
# See https://github.com/microsoft/vscode-remote-release/issues/6615
case "$-" in
    *i*)
        if hash nu 2>/dev/null; then
            exec nu;
        fi ;;
    *) ;;
esac

[BatmanAoD]

nushell has been modified so that it now behaves the way VSCode expects. That said, I still think this should be fixed on the VSCode side as well: currently it's executing a script without knowing whether the shell that executes it will be POSIX compliant, when it could simply use the --system flag to ensure that a known shell will be used.

[shenjiangqiu]

any progress on this issue?

[mokeyish]

any progress on this issue?