bash_profile vs bashrc

[dlcarmean]

Forgive me if this has been raised and decided, but the issue searchbox did not reveal such...

I'm wondering why this toolkit focuses on wedging into .bash_profile when .bashrc seems to be generally accepted as the starting point for interactive bash sessions?

I follow what I'd gathered to be a generally accepted practice of a trivial bash_profile which exists primarily to invoke .bashrc, whose only other entries are to configure items I'd use from cron or some remote execution tool.

(in fact I carry this a bit further, having a separate .bashrc.interactive or .bashrc.local for the truly local interactive stuff).

I'm busily hacking on my own local branch to refactor for the above, but want to step back and think about how I can give back.

(background: I spend hours logged in as the daemon user for a particular application for administration. I'm hoping this toolkit can help me standardize those admin environments but my prime directive is "First, do no harm" to the app's auto-customized shell environment. I'm leaning toward an installation that requires manual sourcing for that particular environment, but elsewhere, a cleaner merge into existing startup files.)

[dlcarmean]

I meant to include this snippet from a modern bash manpage:

# GNU Bash-4.1      2009 December 29        BASH(1)
#
#   FILES
#          /bin/bash
#                 The bash executable
#          /etc/profile
#                 The systemwide initialization file, executed for login shells
#          ~/.bash_profile
#                 The personal initialization file, executed for login shells
#          ~/.bashrc
#                 The individual per-interactive-shell startup file
#          ~/.bash_logout
#                 The individual login shell cleanup file, executed when a login shell exits
#          ~/.inputrc
#                 Individual readline initialization file

[barraponto]

.bash_profile is loaded once when you start your session. .bashrc is loaded whenever you start a new shell. maybe the reason is performance.

[bighuggies]

.bash_profile is never run on a graphical login in Ubuntu.

[seefood]

I'm with @bighuggies. logging onto GUI on Ubuntu and derivatives leaves you without bash-it. I tried sourcing it from bashrc but it didn't set the prompt, so I just moved all the relative lines from _profile to rc (for lack of time to debug this).

[tswicegood]

Hmm... the decision for .bash_profile was made before me and I've just left it that way. Maybe we could adjust the installer to prompt and/or detect the OS and put it in .bashrc?

@bighuggies, @seefood: any idea why a bash console in the GUI doesn't work? I've used bash-it on Ubuntu Server installs with no problem.

[seefood]

not without digging the Ubuntu sources or forums to find what was their reasoning.

I think it should just be an option. or at least, we should figure out why the prompt is not set when I source _profile from rc. I think the completions and aliases are set ok though.

[bighuggies]

.bash_profile is sourced whenever you log in to a login shell (like Ubuntu server). A graphical login doesn't count, hence .bash_profile isn't run. Apparently "~/.profile" is sourced on graphical Ubuntu logins[1], though I haven't tested it.

[1]https://help.ubuntu.com/community/EnvironmentVariables#Session-wide_environment_variables

[binarycreations]

I know that this is a bit of an old thread however I ended up just splitting out everything from bash-it into a separate "/.bash_it_profile" file. Then sourced this file wherever I felt necessary. I found that Ubuntu does things differently to other Linux distros, there are a couple of threads on Ubuntu forums and a few blog posts explaining all the differences. I found that it actually sources a "/.xprofile" through graphical login, although looking at the threads different login managers seem to have different behaviour.

[binarycreations]

Btw I did have a quick test to see what was being sourced on graphical login. I couldn't see the "~/.profile" being sourced. I find this odd as it contradicts the documentation, I wondered if anyone else had seen this behaviour?

[RobLoach]

I have symlinked .bashrc to .bash_profile, but knowing that .xprofile is a thing is good to know. Possible solution might be to have a .xprofile just source ~/.bash_profile. What are your thoughts?

[edubxb]

According to bash manual:

https://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files

.bashrc is the correct file for interactive non-login shells (when bash runs inside a terminal application like iTerm or xterm). To use the common settings in login shells (ssh session or a virtual console in Linux), the recommendation is to include .bashrc into .bash_profile:

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

I currently use this scenario.

[edubxb]

I'm planning to modify the installer to detect the OS and choose the file to write the config:

Mac OS X → .bash_profile
Other *nix → .bashrc

Any objections?

[RobLoach]

👍

[nwinkler]

Great idea! 👍

[seefood]

Also Debian+derivs (Ubuntu, Mint) prefer .bash_profile, I think.

[edubxb]

I use Debian, at home and at work, Unstable and Testing, and in both cases, the scenario is the explained in my previous comment #173 (comment).

You can check it viewing the files:

/etc/skel/.bashrc
/etc/skel/.profile

the default config files copied to the home of new created users. If .bash_profile exists .profile is ignored when Bash search for config files.

The original idea comes from @tswicegood in this comment #173 (comment) 😅