bash acts differently whether it is a shell or a normal programming language (like
By design, the settings in
~/.bashrc, etc. are for users to set things when
bash plays the role of a shell (login shell, interractive shell). Think about environment you have in a
xterm (interactive shell) or in
ssh sessions (login shell) or in consoles (login shell).
In other hand,
bash is also a powerful progamming language –think about many scripts for managing services in
systemd– which requires a different style of working. For example, when a developer is writing a system script or a
bash program, he/she will not like to source the user's
~/.bash_profile automatically. It is a normal program, not a shell. A normal program (including
bash programs) would naturally inherit settings from the current working evironement (shell), but not set them.
If we write a program for
bash –it just happens to be written in
bash; in fact, we can write it in
perl or any other progamming language– then we can have an option to sources
~/.bash_profile (read: setting of user's shell, which just happens to be the same language of your programming language):
[ -f /home/user/.bash_profile ] && . /home/user/.bash_profile
However, what if that particular user do not use
bash as his/her shell? He/she may use
fish, etc. So, that practice would not really work when writing program for public use.
So, you can source
~/.bash_profile if you think that will work. But, here, it is not about whether we are able to source a file, it is about how things should works in the system: the design concept. In short: we should view
bash as something having 2 roles: shell and progamming language. Then everything will be much easier to understand.