microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.64k stars 285 forks source link

WSL2 terminal doesn't source .profile #6096

Open vectorcrumb opened 2 years ago

vectorcrumb commented 2 years ago

Issue Type: Bug

When loading a WSL2 window and opening a terminal, the .profile located in the user directory isn't loaded. The steps I took were:

  1. Install a python module with pip. For example, python3 -m pip install -U fprime-tools. An executable is installed in $HOME/.local/bin. This can be verified by running fprime-util in a terminal window.
  2. Open a WSL window and open a terminal within VS Code.
  3. Trying to run fprime-util results in a command not found error. Upon verifying the path with echo $PATH, the folder $HOME/.local/bin isn't found. However, this folder should be added to the path by .profile.

Also, variables defined by .bashrc can be found inside the shell, therefore the issue should arise from VS Code not sourcing the .profile file.

Extension version: 0.63.13 VS Code version: Code 1.63.2 (899d46d82c4c95423fb7e10e68eba52050e30ba3, 2021-12-15T09:40:02.816Z) OS version: Windows_NT x64 10.0.22000 Restricted Mode: No Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2

bamurtaugh commented 2 years ago

Apologies if I'm misunderstanding, but did you install the Python module in step 1 on the WSL side or the Windows side?

If installed on the WSL side, does fprime-util work in an external WSL terminal, just not within a Remote-WSL integrated terminal in VS Code?

jmullman commented 2 years ago

I can confirm that .profile is not being sourced by the wsl remote terminal. Had my GPG_TTY export in there, along with some docker-related stuff. had to move it all out into .bashrc.

@vectorcrumb Ah, I see the issue now. Bad me for not digging through documentation before using a feature.

vectorcrumb commented 2 years ago

@jmullman I tried adding the following to ~/.vscode-server/server-env-setup after creating the file and making it executable:

#!/bin/bash

source /home/<user>/.profile

where <user> is my linux user. However, this still doesn't source the .profile file on starting up a terminal on VS Code. Also, my WSL Log doesn't mention finding the file:

[2022-02-16 01:49:49.184] Resolving wsl+ubuntu, resolveAttempt: 1
[2022-02-16 01:49:49.262] Starting VS Code Server inside WSL (wsl2)
[2022-02-16 01:49:49.262] Extension version: 0.63.13
[2022-02-16 01:49:49.262] Windows build: 22000. Multi distro support: available. WSL path support: enabled
[2022-02-16 01:49:49.263] No shell environment set or found for current distro.
[2022-02-16 01:49:49.352] Connecting to daemon started by other Remote-WSL window... 5.10.60.1-microsoft-standard-WSL2 Ubuntu
[2022-02-16 01:49:49.352] WSL resolver response: 127.0.0.1:12795
[2022-02-16 01:49:49.352] To debug connection issues, open a local browser on http://127.0.0.1:12795/version
[2022-02-16 01:49:49.352] Using 'wslExeProxy' to connect to the VS Code server as configured by setting 'remote.WSL2.connectionMethod'
[2022-02-16 01:49:49.352] 'wslExeProxy' should fix reconnection issues after sleep and network adapter changes.
[2022-02-16 01:49:49.352] Please report issues related with the new setting to https://github.com/microsoft/vscode-remote-release/issues/5894
[2022-02-16 01:49:49.352] To revert back to the old way of connecting, change setting 'remote.WSL2.connectionMethod' to 'wsl2VMAddress'.

Is this impossible then and should I prefer using .bashrc then? This error also pops up when installing go on WSL2, because the recommendation is to add the go executable to the PATH using the .profile file.

@bamurtaugh The error appears only using the integrated VS Code terminal and not using a windows WSL2 terminal.

bamurtaugh commented 2 years ago

@tanhakabir @aeschli I noticed a similar report in https://github.com/microsoft/vscode-remote-release/issues/5852, where a user mentioned Remote-WSL was also affected by this. Do you think this would be related to the fix from that issue (https://github.com/microsoft/vscode/issues/136791)?

aeschli commented 2 years ago

@vectorcrumb Your log says: Connecting to daemon started by other Remote-WSL window, that's why you don't see the Setting up server environment message. Close all remote windows, wait 5 seconds and try again.

hcs-bernardo-rufino commented 2 years ago

Same problem here.

I've installed WSL2, Python and Pip.

On my .profile i have:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

If i try something like pip list, i get Command 'pip' not found... just after this if i enter `source .profile', boom! Pip works like a charm!

If i enter which pip i get /home/rufino/.local/bin/pip so the path it's correct.

Why WSL2 does not source automatically when i open a new WSL2 terminal?

My .profile file:

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi
aeschli commented 2 years ago

@Tyriar FYI

Tyriar commented 2 years ago

I believe the VS Code server does not run a login shell when it starts up the server, this is a difference with desktop VS Code which does. On Linux we run a non-login shell by default in the terminal, so it picks up the changes from the profile only on desktop, not the server. I think I suggested changing how the server launched at some point but understandably that was a very risky change to do. Not sure what we should do here but defining your terminal profile to be a login shell should workaround the problem:

  "terminal.integrated.defaultProfile.linux": "bash (login)",
  "terminal.integrated.profiles.linux": {
    "bash (login)": {
      "path": "bash",
      "args": [
        "-l"
      ],
      "icon": "terminal-bash"
    },
  }
nsimeonov commented 1 year ago

This is exactly how terminal.integrated.profiles.linux is configured and I have the same issue, however JUST FIRST time. If I close this terminal and start a new one - the second one is ok. It happened after I updated WSL from Microsoft Store. All other settings seem to be unchanged, it's just the first terminal I open in VSCode.

PeterWang-dev commented 1 year ago

This is exactly how terminal.integrated.profiles.linux is configured and I have the same issue, however JUST FIRST time. If I close this terminal and start a new one - the second one is ok. It happened after I updated WSL from Microsoft Store. All other settings seem to be unchanged, it's just the first terminal I open in VSCode.

You are absolutely right. When wsl is started, the first terminal I opened does not source .profile, but the next does. I used echo $0 to confirm that both terminal are login shell. I wonder why it behaves differently as the same shell mode.

emphyrioio commented 1 year ago

I have basically the same issue: the first terminal opened when I open WSL ignores my terminal profile. Here is the settings.json of my profile : "terminal.integrated.profiles.linux": { "bash": { "path": "bash", "icon": "terminal-bash", "color": "terminal.ansiBlue", "args": [ "--init-file", "~/.vscode_bash_profiles/.init_ASM.sh" ], "overrideName": true } }, "terminal.integrated.defaultProfile.linux": "bash", "terminal.integrated.enablePersistentSessions": true, "terminal.integrated.persistentSessionReviveProcess": "onExitAndWindowClose",

emphyrioio commented 1 year ago

Using the deprecated way solved my problem temporarly: { "terminal.integrated.shell.linux": "/usr/bin/bash", "terminal.integrated.shellArgs.linux": ["--init-file", "~/.vscode_bash_profiles/.init_ASM.sh"] }

Tyriar commented 1 year ago

This is exactly how terminal.integrated.profiles.linux is configured and I have the same issue, however JUST FIRST time.

This is a elusive long standing issue where whenever we fix it, there's some edge case we hadn't covered.

Tracked in https://github.com/microsoft/vscode/issues/175107 Most recent fix https://github.com/microsoft/vscode/pull/175844 Upcoming fix https://github.com/microsoft/vscode/pull/181832

mindplay-dk commented 1 year ago

I'm on a clean Windows 11 install, with a brand-new default WSL installation - literally just wsl --install.

Brand new installation of VS Code as well.

And it doesn't work.

So not really an edge case, I think? Likely everyone with a brand-new Win 11, WSL 2, VS Code install will hit this well.

@Tyriar I copied your settings from here and it does appear to run my .profile now - however, oddly, it appears to run some other startup script twice?

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

LOL
mindplay@Sidewinder-7900:~/workspace/observables$ 

I see that sudo message every time I open a console - my .profile at the moment is just echo "LOL" for testing.

Maybe running something twice is/was a temporary workaround for things not working the first time?

codespearhead commented 1 year ago

That file (~/.profile) seems to be sourced properly when WSL is invoked Visual Studio Code Remote Development, but not from the integrated terminal (BASH) when you do on Windows 10.

Strangely enough, it is when you open Tmux.

codespearhead commented 1 year ago

I've just figured out why: only ~/.bashrc is being sourced because the vscode-remote-release's built-in terminal is not a login shell, which you can corroborate by running:

shopt login_shell

Hence, I suggest doing as this answer says:

[In this scenario] it's usually fine to put all yout stuff in ~/.bashrc

mindplay-dk commented 1 year ago

On my latest WSL2 install, my .profile is now being correctly sourced with the latest versions of VS Code and WSL2 on Win11. Go figure.

louiswdavis commented 12 months ago

I have this issue also on a fresh install of W11, WSL, and VSCode.

I found my .profile file would get sourced when I was opening a terminal from a Windows folder but not from Linux, as others have also found, and that my .bashrc file did get sourced from Linux. Since I didn't want to move content from my files, and I didn't want to mess with the setup when I don't fully understand this stuff, I just decided to source my .profile from my .bashrc.

To my .bashrc I added;

if [ -f ~/.profile ]; then
    source ~/.profile
fi

And commented out code in .profile that would try to call .bashrc or other files to make sure I don't end up in a source loop.

codespearhead commented 12 months ago

That's a much better workaround, indeed.

CS-Account commented 11 months ago

On my latest WSL2 install, my .profile is now being correctly sourced with the latest versions of VS Code and WSL2 on Win11. Go figure.

Any clue what changed?

skupjoe commented 2 months ago

Fixed by adding the code from https://github.com/microsoft/vscode-remote-release/issues/6096#issuecomment-1774153528 added to my ~/.bash_profile. Feels more like a quick fix..

But yeah, something definitely changed. Was the integrated terminal using a login shell before and this changed sometime last year?