Vscode-remote-release: FISH Support

[jatsrt]

Issue Type: Bug

Will not install/initialize if the shell being used is fish

Extension version: 0.34.0
VS Code version: Code - Insiders 1.34.0-insider (473af338e1bd9ad4d9853933da1cd9d5d9e07dc9, 2019-05-01T00:21:48.884Z)
OS version: Darwin x64 18.5.0
Remote OS version: Linux x64 4.15.0-1037-aws

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz (8 x 3100)|
|GPU Status|2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: enabled
rasterization: enabled
surface_synchronization: enabled_on
video_decode: enabled
webgl: enabled
webgl2: enabled|
|Load (avg)|1, 1, 1|
|Memory (System)|16.00GB (3.95GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: Jake-VSCode|
|OS|Linux x64 4.15.0-1037-aws|
|CPUs|AMD EPYC 7571 (4 x 2199)|
|Memory (System)|15.53GB (12.56GB free)|
|VM|0%|

[Reanmachine]

I'm also experiencing this, here's the output from the remote terminal:

Source:

Version: 1.34.0-insider (user setup)
Commit: 473af338e1bd9ad4d9853933da1cd9d5d9e07dc9
Date: 2019-05-01T00:22:05.899Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Target:

Linux toudai 5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 19.04
Release: 19.04
Codename: disco
fish, version 3.0.2

[jatsrt]

The requirements state bash, which is fine, the install process should start by launching it's scripts in bash and not assuming the login shell is correct.

[weisi]

Update: It might not work (as people pointed out below), though it works for me with openSUSE Linux local.

Workaround for "Remote - SSH" on your SSH remote host that defaults to a non-bash shell like fish shell:

Create a new entry in your .ssh/config file that specifies RemoteCommand /bin/bash. Like this:

Host remotehost-bash
Hostname ...
RemoteCommand /bin/bash

And then in the "Remote SSH: Connect Current Window to Host..." input, put in remotehost-bash or user@remotehost-bash instead of remotehost or user@remotehost. Now you can have "Remote - SSH" use bash for the setup, but still use fish or your favorite shell as the default shell for your remote user.

[Reanmachine]

@weisi I had success getting connected but the tunnel connection reports this and the sub-window just hangs waiting for the tunnel:

bash: cannot set terminal process group (28484): Inappropriate ioctl for device
bash: no job control in this shell

And this below:

Waiting for ssh tunnel to be ready
Cannot execute command-line and remote command.

[GordonMcGregor]

I can confirm I see the same problem when using a 'RemoteCommand' setting. It is when the ssh tunnel is then being set up, as it uses a command-line on the ssh command to run a sleep infinity when creating the tunnel.

[Reanmachine]

@jatsrt 's Suggestion above is probably the best way for this to be fixed. The solution can still require bash installed, but not assume it's the default and run their commands by launching them in bash on the remote server.

[matthewess]

Just to confirm I'm also having issues with this. It's not trivial to change the login shell on my remote server at work, so having some more ability to control how these install scripts get launched is a must, I would say.

[adonese]

i had the same problem (i use fish) and i had to temporarily switch to bash for WSL initialization to succeed. A hack but works.

[gcemaj]

@weisi I had success getting connected but the tunnel connection reports this and the sub-window just hangs waiting for the tunnel:

bash: cannot set terminal process group (28484): Inappropriate ioctl for device
bash: no job control in this shell

And this below:

Waiting for ssh tunnel to be ready
Cannot execute command-line and remote command.

Did you get this to work? I am also crashing after the "install command ran"

[Reanmachine]

Did you get this to work? I am also crashing after the "install command ran"

No, it successfully allows the install script for the code server to run, but once it goes to launch the ssh tunnel it interferes and halts the process from working.

I've reverted my shell to bash for the time being, hoping this gets fixed soon.

[jatsrt]

Should have mentioned this when I originally posted, but a quick note for anyone dealing with this. Even if you have to run bash as your main login shell. VSCode can launch any shell you want in the integrated terminal. Just makes things a little easier for now. If you cannot change your login shell, this will not help.

"terminal.integrated.shell.linux": "/usr/bin/fish"

[adam-erickson]

@jatsrt @Reanmachine Another solution is to use the $SHELL environmental variable, which points to the default shell set for the user, together with a simple conditional statement to select the correct install script. I don't know about Windows, but this works across Linux and MacOS.

[Reanmachine]

@adam-erickson Unless I am misunderstanding what you mean, the $SHELL environment variable is set by login(1) which is determined by the shell configured for your account.

This is precisely the problem. When our default shell is set to fish, the install script cannot run it's bootstrap command (I assume) it's relying on a strict POSIX terminal feature (of which fish isn't 100% compliant). We don't have a problem calling fish from a terminal once vscode is running and connected, the problem is that our account preferences on the target machine have to be altered to support this workflow.

If we use the RemoteCommand trick to drop us into bash before the install script runs, this effectively works, but the same settings are used when the tunnel is created, and the command used by that to keep the tunnel session open conflicts with the RemoteCommand directive in the configuration.

So we're stuck changing our default shell on the target machine back to bash affecting our other workloads.

[roblourens]

This is fixed in the new "nightly" build of the ssh extension, would appreciate people trying it to let me know if there's still an issue: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh-nightly (uninstall the stable version too)

[Reanmachine]

@roblourens Confirmed working with /usr/bin/fish as default shell on:

VSCode

Version: 1.35.0-insider (user setup)
Commit: 16de3c28db1d2c6fbe2227d1ffe91c5e7e683bc9
Date: 2019-05-27T05:19:20.616Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

Extension

Name: Remote - SSH (Nightly)
Id: ms-vscode-remote.remote-ssh-nightly
Description: Open any folder on a remote machine using SSH and take advantage of VS Code's full feature set.
Version: 2019.5.39180
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh-nightly

Remote Machine

Linux toudai 5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 19.04
Release: 19.04
Codename: disco

Thank you for the hard work!