remote-ssh: .profile not sourced for bash shells, only .bashrc?

[Codelica]

• VSCode Version: 1.34.0-insider
• Local OS Version: Mac OS 10.14.4
• Remote OS Version: Ubuntu 16.0.4
• Remote Extension/Connection Type: SSH

Not sure if this is "as intended" or not, but remote bash terminals (when connected via SSH) only seem to source .bashrc and not .profile (like a typical login shell would). Obviously not the end of the world, but still curious. :) Local dev w/ bash terminal seems to source .profile.

Steps to Reproduce:

1. Connect via Remote SSH
2. Bring up a terminal

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

[WSLUser]

It's better practice to use .profile. Fish, dash, and other shells would have an easier time being used as the login shell and potentially resolve some issues in using other shells other than bash.

[michaelaye]

it looks like .bash_profile is being sourced though.

[Tiedye]

This caused my pipenv installation to not be recognized by vs code. Renaming .profile to .bash_profile fixed the issue

[jenzopr]

I can confirm that .bash_rc is sourced, but not /etc/profile.
This behaviour breaks existing conda installations which rely on scripts in /etc/profile.d/ normally sourced in /etc/profile. My OS is Debian.

[hostmaster]

@Codelica This behavior is expected and documented. http://man7.org/linux/man-pages/man1/bash.1.html

       When bash is invoked as an interactive login shell, or as a non-
       interactive shell with the --login option, it first reads and
       executes commands from the file /etc/profile, if that file exists.
       After reading that file, it looks for ~/.bash_profile, ~/.bash_login,
       and ~/.profile, in that order, and reads and executes commands from
       the first one that exists and is readable. 

So for a new ssh session (no control master process) bash reads '/etc/profile' and ~/.bash_profile and ignores ~/.profile and ~/.bash_login

ubuntu@:~$ set | grep PROFILE
PROFILE_BASH_LOCAL='~/.bash_profile'
PROFILE_GLOBAL=/etc/profile

ubuntu@:~$ cat /etc/profile .profile .bash_profile .bash_login
export PROFILE_GLOBAL="/etc/profile"
export PROFILE_LOCAL="~/.profile"
export PROFILE_BASH_LOCAL="~/.bash_profile"
export PROFILE_BASH_LOGIN="~/.bash_login"

ubuntu@:~$ echo $BASH_VERSION
4.4.19(1)-release

ubuntu@:~$ lsb
lsblk        lsb_release
ubuntu@:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.2 LTS
Release:	18.04
Codename:	bionic

[Codelica]

@hostmaster what I'm seeing doesn't seem to line up what you've written, or maybe I'm mis-reading.

When I bring up a terminal in VS Code locally (on Mac), I see ~/.bash_profile being read, as it would for "an interactive login shell, or as a non-interactive shell with the --login option" -- which is what I would expect.

However, when I bring up a VS Code terminal with a Remote SSH connected host, I do not see ~/.bash_profile being read. Rather, I see ~/.bashrc being read as a non-login BASH shell would:

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists.

Is that different from what you are observing?

I guess I would expect them to behave the same, assuming the goal for these remote plugins is to be editing on the remote resource just as if it were a local VS Code session.

[hostmaster]

@Codelica

remote bash terminals (when connected via SSH) only seem to source .bashrc and not .profile

This is exactly how bash supposed to work. It looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order.

It is irrelevant to remote-ssh.

[Codelica]

@hostmaster

This is exactly how bash supposed to work. It looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order.

Again none of those files are loaded for me when bringing up a terminal in a remote-ssh connected VS Code session. Those files are checked in that order when bringing up a local VS Code terminal, just as a login shell would.

Is that not what you are seeing?

If the point of the remote plugins like remote-ssh, are to develop on a remote resource as if it were local, I don't see why this behavior should be different, or irrelevant.

[hostmaster]

@Codelica please ask your Linux vendor (or in a mailing list or whatever) if you think bash does not work as expected.

[jenzopr]

I have the feeling to step in here. Sorry @hostmaster, but your reply

It is irrelevant to remote-ssh.

is simply not true. This issue is directly relevant to remote-ssh as the terminal behaves differently when invoked locally and remotely. The bash works correctly in both cases given how it is (or seems to be) invoked. However, this issue is about how bash is currently invoked and how bash should be invoked from remote-ssh. The issue is not about whether bash behaviour is correct or not.

[Codelica]

@hostmaster I'm not sure how you got the impression that I feel bash is at fault here. As you'll notice this is a VS Code issue thread I created -- not bash.

Twice I've tried to explain that it's inconsistent behavior on the part of VS Code's integrated terminal to provide a different bash experience based on whether you are working locally or with a "remote-ssh" connected host. The whole idea of the remote-ssh plugin (IMO) is to transparently work as though you were working locally on that remote host, so bash should be invoked as such.

If you feel this is correct behavior for VS Code, and aren't interested in responding to direct questions, then I can't see how this thread is worth your time.

[roblourens]

Many things have changed in the last few months, if anyone is still having issues, please file a new issue.

[jenzopr]

I tested this again and created the files .bash_profile, .bash_login and .profile, as well as .bashrc with repsective echo statements. It now seems that the Remote SSH only sources .bashrc, which replicates behaviour of an interactive shell, that is not a login shell. In this case, we could open a new issue requesting the option to invoke a login shell, by e.g. passing the --login option. This should then source the first of .bash_profile, .bash_login and .profile (in that order).
@Codelica can you confirm the behavior? Version was 1.38.1

[Codelica]

What I see for a remote SSH connected host:

When VS Code makes it's initial ssh connection to the host, .bash_profile is sourced (as per a login shell), however any/all interactive terminals brought up in VS Code source .bashrc

What I see for a local host:

Any/all interactive terminals brought up source .bash_profile (as per a login shell)

That difference in terminal behavior between local and remote connections is what I consider a bug in VS Code's remote ssh implementation.

[megakoresh]

What I see for a remote SSH connected host:

When VS Code makes it's initial ssh connection to the host, .bash_profile is sourced (as per a login shell), however any/all interactive terminals brought up in VS Code source .bashrc

What I see for a local host:

Any/all interactive terminals brought up source .bash_profile (as per a login shell)

That difference in terminal behavior between local and remote connections is what I consider a bug in VS Code's remote ssh implementation.

I can confirm - exactly the same behaviour observed here.

[barata0]

+1 same here.
Host Windows 10 Home
Remote Guest Ubuntu 18.04

[megakoresh]

+1 same here.
Host Windows 10 Home
Remote Guest Ubuntu 18.04

Yes mine is Windows 10 Pro 1903
Remote is Centos 8.0.1905
VSCode is 1.40.1

@roblourens Please reopen this, it's clearly an issue. I can reproduce this with every windows machine, including my colleague's Windows 10 Enterprise and latest version of VSCode and Remote SSH extension.

[roblourens]

This is covered by #1671 (comment), and I see that there is a difference but don't totally understand why it's an issue.

[barata0]

Hi Rob,

According to your comment on #1671 :
"...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. ..."

I just added a PATH="/nopath:$PATH" at the end of the .profile ,restarted the server and opened VS code

Output from the shell running on Remote Ubuntu (/nopath is there)

> ubuntu@node-server:~$ echo $PATH
> /nopath:/home/ubuntu/.yarn/bin:/home/ubuntu/.nvm/versions/node/v13.2.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> 

Output from the vs code terminal running on Local Windows (/nopath is missing)

ubuntu@node-server:~/dev$ echo  $PATH
/home/ubuntu/.yarn/bin:/home/ubuntu/.nvm/versions/node/v13.2.0/bin:/home/ubuntu/.vscode-server/bin/8795a9889db74563ddd43eb0a897a2384129a619/bin:/nopath:/home/ubuntu/.yarn/bin:/home/ubuntu/.vscode-server/bin/8795a9889db74563ddd43eb0a897a2384129a619/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Is it the expected behaviour?

[roblourens]

I don't know, is it? Both outputs have /nopath

The second one:

/home/ubuntu/.yarn/bin:/home/ubuntu/.nvm/versions/node/v13.2.0/bin:/home/ubuntu/.vscode-server/bin/8795a9889db74563ddd43eb0a897a2384129a619/bin:>>>/nopath<<<:/home/ubuntu/.yarn/bin:/home/ubuntu/.vscode-server/bin/8795a9889db74563ddd43eb0a897a2384129a619/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

[barata0]

You're right.
Both have nopath

I might have missing any step before.

Not a BUG.
thanks