user environment variables are not loaded

[urubatan]

Issue Type: Bug

User environment variables are not loaded, making most processes not work (RVM doesn't work for example)
DOCKER_HOST is not set
DATABASE_HOST is also not set

Extension version: 0.32.0
VS Code version: Code - Insiders 1.34.0-insider (473af338e1bd9ad4d9853933da1cd9d5d9e07dc9, 2019-05-01T00:22:05.899Z)
OS version: Windows_NT x64 10.0.17763
Remote OS version: Linux x64 4.4.0-17763-Microsoft

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7Y75 CPU @ 1.30GHz (4 x 1608)
GPU Status	2d_canvas: enabled checker_imaging: disabled_off flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: enabled surface_synchronization: enabled_on video_decode: enabled webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.89GB (5.29GB free)
Process Argv
Screen Reader	no
VM	0%

Item	Value
Remote	WSL
OS	Linux x64 4.4.0-17763-Microsoft
CPUs	Intel(R) Core(TM) i7-7Y75 CPU @ 1.30GHz (4 x 1601)
Memory (System)	15.89GB (5.29GB free)
VM	0%

[kieferrm]

@urubatan, you're talking about WSL?

[urubatan]

@kieferrm sorry, yes, I'm using the remote WSL

to workaround I changed the server.sh script to use bash instead of sh and forced loading the my user profile, works for most of the plugins but not all (for example, terminal, docker, all build tasks, work perfectly, docker-compose plugin doesn't appear to have the variable set)

but this is after "my small hack"

before that, no user env was available to the editor.

[Codelica]

May be related, if your shell is set to bash, remote-ssh appears to source .bashrc and but not .profile (like a full login shell typically does). Not sure if this is intentional or not. Sub-shells typically don't get .profile, but personally I wish it were included for this.

[Tyriar]

WSL does indeed appear to not run the server in a login shell (unlike the SSH extension).

[Codelica]

Well, I'm not sure the SSH extension uses a login shell either (for the remote terminal at least). I'm definitely seeing .bashrc and not .profile sourced with that extension. But I started a separate issue for that @ #84.

[Tyriar]

@Codelica when you connect to the window on SSH the server is run in a login shell, when you open a terminal it inherits that environment and your shell launches a non-login shell.

[Codelica]

@Tyriar thanks for the info. :) looks like I can key off VSCODE_IPC_HOOK_CLI and add what I need in bashrc. 👍

[sskeirik]

@Codelica @Tyriar Based on your combined input, I got my setup personally to work. Thanks! I did two things:

1. Added a conditional in .bashrc based on value of VSCODE_IPC_HOOK_CLI
2. Added VSCODE_IPC_HOOK_CLI/u to my WSLENV environment variable on the Windows side

The second step lets us resume editing a WSL workspace that we started earlier by just running code-insiders as usual on the Windows side, so that the value of the VSCODE_IPC_HOOK_CLI variable is properly shared from Windows to WSL and the right bash initialization logic kicks in.

[aeschli]

The WSL server is started with bash -i ./script/wslServer.sh.
According to this, bash 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.

When the terminal starts it does the same (@Tyriar Maybe that't not really necessary).

What doesn't work is when when you start code-insiders . from a WSL shell: We start a new shell for the server but do not copy the environment as it is present in the shell.
@urubatan Is that what you were expecting?

[urubatan]

This is what I was expecting, but it was not happening. Variables that were defined in ~/.bash_profile were not available for vscode plugins (for example the DOCHER_HOST that is needed to run docker from WSL pointing to windows docker) It just started working after I changed the startup.sh to force loading the script and using bash. PS.: I'm using code-inseders but not windows insiders, so my WSL version is the latest official version, not a pre release version. Not sure if that affects how it should work.

…

On Mon, May 6, 2019 at 10:09 AM Martin Aeschlimann ***@***.***> wrote: The WSL server is started with bash -i. According to this <https://www.stefaanlippens.net/bashrc_and_others/> 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. When the terminal starts it does the same ***@***.*** <https://github.com/Tyriar> Maybe that't not really necessary). What doesn't work is when when you start code-insiders . from a WSL shell, we but start a new shell for the server but do not copy the environment as it is present in that shell. @urubatan <https://github.com/urubatan> Is that what you were expecting? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAD4NPTRZXQWYEM535D4DPUAUYNANCNFSM4HKPHMJA> .

-- Rodrigo Urubatan Ferreira Jardim Architect, Developer and Technical Writer rodrigo@urubatan.com.br Visite meu blog: http://www.urubatan.com.br Melhor livro de RoR do Brasil: http://livro.urubatan.com.br

[aeschli]

Here's a good read on bash-startup-files:
https://medium.com/@rajsek/zsh-bash-startup-files-loading-order-bashrc-zshrc-etc-e30045652f2e

[aeschli]

@urubatan If you put a ECHO .bash_profile on the first line of ~/.bash_profile you will see that it is invoked. Check the content of the script to see what it further does and why DOCKER_HOST is not initialised.

[aeschli]

@urubatan Sorry, you are right, I got confused. Currently, WSL is an interactive non-login shell. What's called is ~/.bashrc.

[urubatan]

ok, knowing that I can adjust my settings to be loaded from the correct place :D I'll try it here, thanks for the help

…

On Tue, May 7, 2019 at 9:35 AM Martin Aeschlimann ***@***.***> wrote: @urubatan <https://github.com/urubatan> Sorry, you are right, I got confused. Currently, WSL is an interactive non-login shell. What's called is ~/.bashrc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAD4LHFKN7UV2OSQJYVQTPUFZQJANCNFSM4HKPHMJA> .

-- Rodrigo Urubatan Ferreira Jardim Architect, Developer and Technical Writer rodrigo@urubatan.com.br Visite meu blog: http://www.urubatan.com.br Melhor livro de RoR do Brasil: http://livro.urubatan.com.br

[urubatan]

@aeschli just to let you know that moving my environment initialization to ~/.bashrc worked both for env vars and for RVM to load project specific ruby versions (at least with default rvm ruby version, there is some directory change hook not being called but that is outside the scope of this bug and too specific for rvm :D )

Thanks a lot for helping clarify this env load issue 🥇