Open vectorcrumb opened 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?
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.
@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.
@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)?
@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.
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
@Tyriar FYI
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"
},
}
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.
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.
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",
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"] }
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
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?
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.
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
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.
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.
That's a much better workaround, indeed.
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?
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?
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:python3 -m pip install -U fprime-tools
. An executable is installed in$HOME/.local/bin
. This can be verified by runningfprime-util
in a terminal window.fprime-util
results in acommand not found
error. Upon verifying the path withecho $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