Set GODOT environment variable in both ".bashrc" and ".bash_profile" shell configuration files on Unix

[LungDrago]

GodotEnv currently only sets the GODOT environment variable (along with changes to PATH) inside the ".bashrc" file. However, we found out through Discord discussion that on an Arch-based OS, VSCode will not read environment variables correctly unless they are set in user's ".bash_profile" file. Setting the variable in both places would allow Arch-based distros to work out of the box like the rest.

[edassis]

Hi, ~/.bash_profile ~/.profile are called by login shells, the one that starts when you log in to your system and only at that moment (generally). ~/.bashrc is called by interactive, non-login shell, when you open a Terminal application (GNOME Terminal, Konsole).

However, we found out through Discord discussion that on an Arch-based OS, VSCode will not read environment variables correctly unless they are set in user's ".bash_profile" file.

Can you describe better your situation, maybe with some example? From my tests (Ubuntu), VSCode seems to source a login shell at startup, and when you open an integrated shell it's an interactive non-login shell:

• 

• Put a echo at the end of my ~/.bashrc to show that it's been called:
  

• I think it's worth a look into the vscode's setting "terminal.integrated.profiles.linux" and see if it specifies some args for the shell that can be affecting it's initialization.
  https://code.visualstudio.com/docs/terminal/profiles

Here, a table and diagram about bash/zsh's startup files calling:
https://shreevatsa.wordpress.com/2008/03/30/zshbash-startup-files-loading-order-bashrc-zshrc-etc/

But this can vary, as some distros sources ~/.bashrc from ~/.profile per example (it's my case). So, this means that a bash login shell can source ... -> ~/.profile -> ~/.bashrc.

As we can see, the shell process initialization is tricky and can vary per shell/distro. One interesting approach to guarantee that the PATH modification is happening, independent of how the shell is being called, it's to define some separated script that checks if the PATH was already patched, if not patch it. This script would be sourced at multiple shell's startup files. It's the approach that rust's cargo tool took:

$HOME/.cargo/env approach

$HOME/.cargo/env defined in:

~/.zshenv:. "$HOME/.cargo/env"
~/.bashrc:. "$HOME/.cargo/env"
~/.config/fish/conf.d/rustup.fish:. "$HOME/.cargo/env.fish"
~/.profile:. "$HOME/.cargo/env"

$HOME/.cargo/env contents:

#!/bin/sh
# rustup shell setup
# affix colons on either side of $PATH to simplify matching
case ":${PATH}:" in
    *:"$HOME/.cargo/bin":*)
        ;;
    *)
        # Prepending path in case a system-installed rustc needs to be overridden
        export PATH="$HOME/.cargo/bin:$PATH"
        ;;
esac

Maybe we could do something similar here.

[jolexxa]

@edassis If it's good enough Rust, it's probably a good solution. I'm totally in favor of doing that.