remote-ssh: Add possibility to invoke a login shell

[jenzopr]

Currently (vscode 1.38.1), a remote bash terminal only sources .bashrc, like an interactive shell that is not a login shell would do.
This breaks existing conda installations on the remote system, which rely on code in /etc/profile.d. I'd like to have the possibility to start an interactive shell with the --login option on the remote system. This way, profiles from /etc/profile and .profile would be sourced as well.

Please see the bash man page for how different files are sourced on bash invocation.

See #83 for reference as well.

[Tyriar]

@roblourens two ways we could solve this:

• Allow users to specify they want a login shell and the ext host can be launched inside a shell using -l.
• Call getUnixShellEnvironment in the ext host just like we do for the main process, normally the ex host inherits this "dev env" from the renderer but in remote-ssh it's inherited from the barebones ssh env which does not run as a login shell.

I'm leaning towards the former as the solution is inside the ssh ext and won't affect anything else. It could probably be called in a similar way to this how we use $SHELL:

https://github.com/microsoft/vscode/blob/f462eab9694a944fdd0c65dbe3fb7b2774ee3092/src/vs/code/node/shellEnv.ts#L33

There is of course then the problem of $SHELL potentially not POSIX-compliant and causing other issues.

[Codelica]

Option 1 sounds find to me. :) IMO from a user's point of view, it seems like a login shell should be the default though -- just to mirror how local VS Code behaves. I realize that would be a change at this point, but it seems like it would solve more random issues than it would create. (e.g. PATH isn't as expected so scripts fail, etc) But either way 👍

[Tyriar]

@Codelica I think we reason we didn't do that is because a regular ssh session does not run a login shell, so currently it's very similar to a regular ssh setup (unless you run bash -l inside the ssh session or something).

[Codelica]

By "regular ssh session", do you mean invoking a typical remote ssh connection from a terminal shell like:

ssh james@some-remote-host.domain.com

As that seems to always provide a login shell from what I've seen.

[Tyriar]

@Codelica yes, based on my testing it didn't. That's also the reason you're seeing this behavior, if it was a login shell I don't think this issue should exist.

[peter-b]

@Tyriar @Codelica I've also run into this problem when trying to get my team set up with the remote-ssh extension. We have a lot of environment that's set up in .profile rather than in .bashrc, and we rely fairly heavily on nested shells in our dev environment, so setting PATH etc. in .bashrc would be tricky to get right. Either of the proposed fixes would be very helpful.

[Tyriar]

@peter-b yeah you're doing it right. We can consider change this to be the default but we would need to do some thinking on what might break as a result of that.

[Codelica]

@Tyriar I believe any new SSH connection/session should give you an interactive login shell to start. But if you begin another shell in an existing session you then get an interactive non-login shell, which is what is at work here. I think. :)

When the Remote SSH plugin initially connects (to form the session, install what's needed, etc) I can see it is given a login shell sourcing .profile, etc. (which it may appreciate :) ). However any interactive VS Code terminal that the user brings up (once connected) just uses that established session, and is not a login shell. At least I think that's the case based on what I've seen.

While that technically may be "correct" behavior for bringing up an additional shell in an established remote session, it's different from how the VS Code terminal behaves when working locally -- which brings up a login shell each time. So I guess if the intent of the Remote SSH plugin is to "work on a remote host as if it's local", that feels like a disconnect.

That got long, but the answer here has more information if you're interested.

https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell

Thanks for considering this!

[roblourens]

I'm a little confused - we do already set up the extension host environment based on a login shell. Essentially we spawn bash -ilc "node command to print environment" and that is the intial environment of the extension host, and terminals will inherit that environment. This is option 1 that @Tyriar describes and this is what I see in my testing.

So if you are setting PATH or other environment variables in your .profile, they should end up in the terminal environment as well. I am not familiar with conda so I wonder if you can give me a concrete example of what you are seeing.

In my case, I have export DOTPROFILE=yes in my .profile and I can run echo $DOTPROFILE in the vscode terminal and see that it is "yes".

Side note, since I had forgotten this: We only discover the environment once then cache it for the rest of the server's session. If you change your dot scripts and want to see that change reflected when you open a new vscode window, you will have to restart the remote server with the command "Kill VS Code Server on Host".

[peter-b]

Side note, since I had forgotten this: We only discover the environment once then cache it for the rest of the server's session. If you change your dot scripts and want to see that change reflected when you open a new vscode window, you will have to restart the remote server with the command "Kill VS Code Server on Host".

Hi @roblourens, this is the part that I was missing. It isn't at all obvious that this is the behaviour; it comes as a big surprise to me that VS Code continues to run on the remote server after the last window connected to it has been closed. Are you sure this behaviour is desirable?

[roblourens]

So restarting the server fixes it for your case?

Are you sure this behaviour is desirable?

No, not at all. However, connecting to the remote is kind of slow already and I'm hesitatant to do anything that could make it slower, like starting a process to check the environment that won't change 99% of the time. Not sure what to do.