`remote.SSH.serverInstallPath` does not respect environment variables now

[Lablace]

• VSCode Version: 1.86.0 (system setup)
• Local OS Version: Windows_NT x64 10.0.19045
• Remote OS Version: Ubuntu 22.04.1 LTS (Linux kernel 5.15.0-88-generic, glibc 2.35)
• Remote Extension/Connection Type: Containers/WSL/Server Server

• Logs: not needed

Steps to Reproduce:

1. Change the value in one of the key-value pairs in remote.SSH.serverInstallPath setting to one that contains well-known representives for home directory (like ${HOME} and ~ (tilde)).
2. Connect to the modified remote server, it now creates the directory with the above name and tries to install the vscode-server there rather than expanding it to home directory where a vscode-server has been already installed.
3. Change the modified value back to an absolute path, like /home/alice, and retry connecting to the server, the installed vscode-server in home directory can be found now.

Prior to VSCode 1.86.0, I've been using ${HOME} in my remote.SSH.serverInstallPath without any problem, so I am sure it had the ability to expand these before.

Does this issue occur when you try this locally?: Yes/No No, Remote-SSH is needed. Does this issue occur when you try this locally and all extensions are disabled?: Yes/No No, Remote-SSH is needed.

[arghness]

Confirmed here as well. I have a home directory shared between multiple docker containers and I was using ~ and ${HOSTNAME} to configure each server install path and they stopped expanding.

As an aside, it would be nice if it handled wildcards for the remote host, like remote.SSH.remotePlatform so that I wouldn't have to configure each one individually.

[roblourens]

Does setting "remote.SSH.useExecServer": false make a difference?

[Lablace]

Does setting "remote.SSH.useExecServer": false make a difference?

No, I've tried "remote.SSH.useExecServer" with both true and false, and it didn't make a difference. I've been using configs below (uppercase values are omitted):

{
    "remote.downloadExtensionsLocally": true,
    "remote.SSH.configFile": "CONFIG_FILE",
    "remote.SSH.localServerDownload": "always",
    "remote.SSH.remotePlatform": {
        "REMOTE": "linux"
    },
    "remote.SSH.serverInstallPath": {
        "REMOTE": "$HOME/SOME_DIRECOTORY"
    },
    "remote.SSH.suppressWindowsSshWarning": true,
    "remote.SSH.useExecServer": false,
    "remote.SSH.useLocalServer": true,
}

[djobin]

Same here. We are 20ish users here with the same issue.

Before, we were using:

"remote.SSH.serverInstallPath": {
    "server1": "~/.vscode-server/server1",
    "server2": "~/.vscode-server/server2"
}

Since 1.86.0, this config wrecks our home folder (and vscode-server installations) by creating a folder named '~' /home/username/~/.vscode-server/serverX

Notice the litteral tilde '~' folder in the path.

We tried replacing with $HOME, {$HOME}, {$env:HOME} .. nothing works anymore. We now have to rely on hardcoding the full path.

here is an excerpt from the remote-ssh log :

[11:35:43.279] > code 1.87.2 (commit 863d2581ecda6849923a2118d93a088b0745d9d6)
[11:35:43.307] > Starting VS Code CLI... "$HOME/.vscode-server/server1/.vscode-server/code-863d2581ecda6849923a2118d93a088b0745d9d6" command-shell --cli-data-dir "$HOME/.vscode-server/server1/.vscode-server/cli" --on-port --parent-process-id 3259736 &> "$HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log" < /dev/null  
[11:35:43.310] > Removing old logfile at $HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log
[11:35:43.316] stderr> cat: '$HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log': No such file or directory

[11:35:43.390] > Exec server process not found
[11:35:43.398] > main: line 321: $HOME/.vscode-server/server1/.vscode-server/code-863d2581ecda6849923a2118d93a088b0745d9d6: No such file or directory

[arghness]

Same here. We are 20ish users here with the same issue.

Before, we were using:

"remote.SSH.serverInstallPath": {
    "server1": "~/.vscode-server/server1",
    "server2": "~/.vscode-server/server2"
}

Since 1.86.0, this config wrecks our home folder (and vscode-server installations) by creating a folder named '~' /home/username/~/.vscode-server/serverX

Notice the litteral tilde '~' folder in the path.

We tried replacing with $HOME, {$HOME}, {$env:HOME} .. nothing works anymore. We now have to rely on hardcoding the full path.

here is an excerpt from the remote-ssh log :

[11:35:43.279] > code 1.87.2 (commit 863d2581ecda6849923a2118d93a088b0745d9d6)
[11:35:43.307] > Starting VS Code CLI... "$HOME/.vscode-server/server1/.vscode-server/code-863d2581ecda6849923a2118d93a088b0745d9d6" command-shell --cli-data-dir "$HOME/.vscode-server/server1/.vscode-server/cli" --on-port --parent-process-id 3259736 &> "$HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log" < /dev/null  
[11:35:43.310] > Removing old logfile at $HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log
[11:35:43.316] stderr> cat: '$HOME/.vscode-server/server1/.vscode-server/.cli.863d2581ecda6849923a2118d93a088b0745d9d6.log': No such file or directory

[11:35:43.390] > Exec server process not found
[11:35:43.398] > main: line 321: $HOME/.vscode-server/server1/.vscode-server/code-863d2581ecda6849923a2118d93a088b0745d9d6: No such file or directory

In your case, would it just work to have ".vscode-server/serverX", as it seems to be prepending your home dir anyway?

[djobin]

🤦‍♂️

In your case, would it just work to have ".vscode-server/serverX", as it seems to be prepending your home dir anyway?

You are totally right.....my savior! Thank you!

[gmertes]

Same problem here. The env var is not expanded, and the path is treated like a literal.

    "remote.SSH.serverInstallPath": {
        "REMOTE": "$HOME"
    }

Results in the folder ~/'$HOME' being created.

[vs-code-engineering[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[essex-edwards]

I'm running into a similar problem. I have:

    "remote.SSH.serverInstallPath": {
        "server1": "/local/path"
    }

When I try to connect, it creates a path, /home/my_user_name/'/local/path'/.vscode-server. Yes, there if a folder named ' and another named path'. It's like something is being quoted or expanded incorrectly.

Everything worked fine until today. I don't know what changed. Help->About says:

Version: 1.93.0 (user setup)
Commit: 4849ca9bdf9666755eb463db297b69e5385090e3
Date: 2024-09-04T13:02:38.431Z (1 day ago)
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

[mawansui]

Hello, I fully back @essex-edwards . Everything worked for me yesterday. Today VSCode showed me that it updated to the Aug2024 version (I assume I was using an older one previously), and I have the same problem as @essex-edwards . In my config, I have:

"remote.SSH.serverInstallPath": {
        "myserver": "/projects",
}

And when I connect, it creates a path /projects/'/projects' . Something is definitely wrong with quotations here.

I am on MacOS, M2 chip. My Help -> About section:

Version: 1.93.0 (Universal)
Commit: 4849ca9bdf9666755eb463db297b69e5385090e3
Date: 2024-09-04T13:02:38.431Z (1 day ago)
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin arm64 22.6.0

Thank you for your kind attention to this issue. Let me know if further info is needed to look into it.

[mawansui]

In a strange turn of events, if I write like so:

"remote.SSH.serverInstallPath": {
        "reactions": /projects,
}

that is, skipping the quotations, everything works fine. Although I'm afraid that's not a standard JSON format. But I confirm that this way, it installs at the correct dir 👍

[Lablace]

In a strange turn of events, if I write like so:

"remote.SSH.serverInstallPath": {
        "reactions": /projects,
}

that is, skipping the quotations, everything works fine. Although I'm afraid that's not a standard JSON format. But I confirm that this way, it installs at the correct dir 👍

Your reported problem seems to be a new one introduced in 0.114, see these two: 1, 2.

And frankly speaking it astonished me how this got released, this really common use case should be covered in test.