bash acts differently whether it is a shell or a normal progamming language (like
By designed, those settings in
~/.bashrc, etc. are for users to set things when
bash plays the roll of a shell (login shell, interractive shell). Think about environment you have in a
xterm (interractive shell) or in
ssh sessions (login shell) or in consoles (login shell).
In other hand,
bash is also a powerfull progamming language --think about many scripts for managing services in
systemd-- which requires a different style of working. Example, when a developer write a system script or a
bash program, he/she will not likely to source user defined
~/.bash_profile automatically. It is a normal program, not a shell. A normal program (including
bash programs) would naturally inherrit setting in a current working evironement (shell), but not set them.
If we write a program for
bash --it is just happenly it is 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 happenly 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's practice does not really work when writing program for public use.
So, you can source
~/.bash_profile if you think it 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 rolls: shell and progamming language. Then everything will be clear, easier to understand.