WSL2 terminal doesn't source .profile

[vectorcrumb]

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]

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]

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]

@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]

@tanhakabir @aeschli I noticed a similar report in #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 (microsoft/vscode#136791)?

[aeschli]

@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]

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]

@Tyriar FYI

[Tyriar]

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]

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]

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]

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]

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]

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 microsoft/vscode#175107
Most recent fix microsoft/vscode#175844
Upcoming fix microsoft/vscode#181832

[mindplay-dk]

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]

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]

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 [1], which you can corroborate by running:

shopt login_shell

Hence, I suggest doing as this answer says [2]:

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

---

[1] https://askubuntu.com/a/121083
[2] https://askubuntu.com/a/121077

[mindplay-dk]

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]

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]

That's a much better workaround, indeed.

[CS-Account]

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]

Fixed by adding the code from #6096 (comment) 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?

[Tyriar]

I don't have any plans to change how terminal profiles work when in a remote as that would lead to other weird inconsistencies.

@aeschli the remote owner(s) need to either address this by sourcing the profile in the shell that launches the server, or accept it as designed (maybe document somewhere if it's not already?). When I've discussed this in the past with @roblourens it was deemed too risky of a change to do after so long. cc @joshspicer as you might be tracking a similar problem in SSH.

[mindplay-dk]

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?

@CS-Account I always just assumed they fixed it already?

I don't recall doing anything about it myself - I'm a very basic Linux user, I don't think I'd know how to.

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

@louiswdavis on my system, .profile runs when opening a terminal from anywhere, whether it's the WSL terminal or VS Code.

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.

@louiswdavis I checked my .bashrc, and it does not reference .profile - again, I'm fairly certain I didn't change anything.

I don't have any plans to change how terminal profiles work when in a remote as that would lead to other weird inconsistencies.

@Tyriar I don't think you need to change anything?

My current WSL2 Linux is the standard/default one. (Ubuntu 22.04.4 LTS, jammy)

As I wrote here on October 8 '23, it just started working on my latest WSL2 Linux install - I checked the /var/log/installer folder, and this Linux OS was installed on August 10 '23, so shortly before I wrote that.

So I'd expect this was an issue with earlier releases of the default WSL2 Linux distro?

Most likely, folks in this thread, who are still having problems, are using an earlier version of the default Linux distro? or perhaps they're using a different Linux distro from the default/standard one?

If someone here would care to create a new (or second) Linux install with the default/standard OS, perhaps we could confirm this?

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[aeschli]

Yes, it's a risky change. Why initially had it like that but then ran into many issues with mis-configured startup scripts preventing us from starting the server or detecting the environment.