centos which file to edit to get .bash_profile running?

Question

I want to know which file to edit in order to launch my .bash_profile when I graphically start the terminal.

---

I am using an AWS Workspace with the following OS and the default MATE terminal.

$ cat /etc/os-release

NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

There are so many files in ~/etc:

bashrc
profile
/profile.d
    #lots of .sh

But in my /home/<usr> directory I have:

.bashrc
.bash_profile 

^ I created this bash_profile file and it works when I launch the terminal graphically and do $ source ~/.bash_profile

---

REQUESTED EDIT: This is what I am putting in my .bash_profile it colors my command prompt on every line and adds a timestamp and mentions the virtualenv I have active. I expect it to

# in order to be able to change the color of venv prompt
#
function virtualenv_info(){
    # Get Virtual Env
    if [[ -n "$VIRTUAL_ENV" ]]; then
        # Strip out the path and just leave the env name
        venv="${VIRTUAL_ENV##*/}"
    else
        # In case you don't have one activated
        venv=''
    fi
    [[ -n "$venv" ]] && echo "(pvenv:$venv) "
}

# disable the default virtualenv prompt change
export VIRTUAL_ENV_DISABLE_PROMPT=1

VENV="\$(virtualenv_info)";
#

git_branch() {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/<b:\1>/'
}

# set the prompt color
# color starts with `\e[36m` and is closed with `\e[0m`
export PS1="\e[36m[\t] \e[38;5;203m${VENV}\e[38;5;78m\$(git_branch) \e[38;5;179m\w \e[0m☯  "

---

WORKAROUND by checking this box in the default MATE terminal application.

Answer 1

Don't use profile for this. Instead, add your changes to ~/.bashrc. That's the file most commonly used for this sort of thing which you want evaluated for each shell you open.

So, just remove your modifications from ~/.profile and add them to ~/.bashrc instead. For more details on which files are read under what circumstances, see this answer on our sister site, Ask Ubuntu:

https://askubuntu.com/a/438170

Answer 2

This depends on your graphical environment (LXDM, XFCE, KDE, etc). Some of them don't source ~/.bash_profile.

If you have your reason to use it (e.g. compatibility reasons), you can source it in your ~/.bashrc (expecting you are using bash as your default shell).

echo "source ~/.bash_profile" >> ~/.bashrc

This method comes with some disadvantages.

• It will only be sourced by interactive login shells.
• Other graphical programs won't have the same environment.

I would recommend to use something which works natively with your setup.

1. Use /etc/profile
   • It's global.
   • Affects all user.
   • Disadvantage: It can be overriden more easily because it is sourced very early (but never experienced this in reality. But some desktop environments or something similar set their own unique environment and override the old).

2. Checkout the behaviour of your desktop environment. LXDM for example will source the following (and not ~/.bash_profile):

   /etc/profile
   ~/.profile
   /etc/xprofile
   ~/.xprofile
   

References:

• What's the difference between .bashrc, .bash_profile, and .environment?
• Great context information linked by @terdon: Scripts in /etc/profile.d Being Ignored?

EDIT:

In response to your edit: As expected, mate doesn't source ~/bash_profile by default.

Some stuff about design decisions (because you asked it in you latest comment). Typically you only set environment variables in your ~/.bash_profile, /etc/profile etc why I would consider to move your script else where and not in the ~/.bashrc.

What you are doing is very shell specific. It's reasonable to put it in your ~/.bashrc.

If you are using more shells than one, you could split it into different files. For example define your VIRTUAL_ENV_DISABLE_PROMPT inside a environment file like /etc/profile, create a new bash script with the function virtualenv_info() and only source the script in the shell environment where you need it. This would be a clean solution but it will work if you only put the whole script into your ~/.bashrc.