Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Codelica opened this issue May 3, 2019 · 21 comments
Closed

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

Codelica opened this issue May 3, 2019 · 21 comments
Labels
ssh

Comments

@Codelica
Copy link

@Codelica Codelica commented May 3, 2019

  • 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

This comment has been minimized.

Copy link

@WSLUser WSLUser commented May 3, 2019

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.

@kieferrm kieferrm added the ssh label May 3, 2019
@Codelica Codelica changed the title .profile not sourced for bash shells, only .bashrc? remote-ssh: .profile not sourced for bash shells, only .bashrc? May 3, 2019
@michaelaye

This comment has been minimized.

Copy link

@michaelaye michaelaye commented May 6, 2019

it looks like .bash_profile is being sourced though.

@Tiedye

This comment has been minimized.

Copy link

@Tiedye Tiedye commented May 14, 2019

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

@jenzopr

This comment has been minimized.

Copy link

@jenzopr jenzopr commented May 21, 2019

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

This comment has been minimized.

Copy link

@hostmaster hostmaster commented Jun 10, 2019

@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

This comment has been minimized.

Copy link
Author

@Codelica Codelica commented Jun 11, 2019

@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

This comment has been minimized.

Copy link

@hostmaster hostmaster commented Jun 11, 2019

@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

This comment has been minimized.

Copy link
Author

@Codelica Codelica commented Jun 11, 2019

@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

This comment has been minimized.

Copy link

@hostmaster hostmaster commented Jun 13, 2019

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

@jenzopr

This comment has been minimized.

Copy link

@jenzopr jenzopr commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Author

@Codelica Codelica commented Jun 15, 2019

@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

This comment has been minimized.

Copy link
Member

@roblourens roblourens commented Oct 15, 2019

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

@roblourens roblourens closed this Oct 15, 2019
@jenzopr

This comment has been minimized.

Copy link

@jenzopr jenzopr commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Author

@Codelica Codelica commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@megakoresh megakoresh commented Nov 15, 2019

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

This comment has been minimized.

Copy link

@barata0 barata0 commented Nov 23, 2019

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

@megakoresh

This comment has been minimized.

Copy link

@megakoresh megakoresh commented Nov 24, 2019

+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 comment has been minimized.

Copy link
Member

@roblourens roblourens commented Nov 24, 2019

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

This comment has been minimized.

Copy link

@barata0 barata0 commented Nov 24, 2019

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

This comment has been minimized.

Copy link
Member

@roblourens roblourens commented Nov 25, 2019

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

This comment has been minimized.

Copy link

@barata0 barata0 commented Nov 25, 2019

You're right.
Both have nopath

I might have missing any step before.

Not a BUG.
thanks

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.