A bash user will eventually end up with .bashrc, .bash_profile, .profile, and maybe some more.

Now, each file gets loaded unders particular situations, and it all leads to confusion and frustration. I don't care about what shell is a login shell and neither should you.

I just want to make sure the same thing is loaded for every shell thing that happens.

So, what's the sane way to set them up?

I'd wager non-bash-specific things go into .profile, and some file sources the others, etc. What exactly would in put in each to achieve an identical environment for every shell?

Note: I'm not asking what you particularly enjoy putting in your rc files, like aliases and functions and so on. Just how you lay them out so as not to have things randomly spliced amongst them.

  • I have this awesome book, From Bash to Z Shell, and I used to know just the perfect way to get out of shell initialization hell, but it's all messy and random, and, well, I can't remember things that don't make sense. – kch Aug 6 '09 at 8:05
  • But some commands, if executed in a non-terminal holding shell, can make logging into that account impossible. – Kent Fredric Aug 6 '09 at 8:10
  • 1
    I'd love an example. Anyway, I'm sure in that case it can be left off in the appropriate file so as not to run when it shouldn't. – kch Aug 6 '09 at 8:11
  • One example would be problems with rsync: samba.org/rsync/FAQ.html#3 – innaM Aug 6 '09 at 9:54

I just want to make sure the same thing is loaded for every shell thing that happens.

If you really want that, put everything in ~/.profile and add a source ~/.profile at the end of your ~/.bashrc. If this is desirable is a different question. To source ~/.profile in ~/.bashrc is a very common setup anyway.

|            | login shells    | interactive shells |
| all        | /etc/profile    |                    |
| bourneish  | ----------------+--------------------|
| shells     | ~/.profile      |                    |
| just       | ~/.bash-profile | /etc/bash.bashrc   |
|            | -------------------------------------|
| bash       | ~/.bash-login   | ~/.bashrc          |

C shell and shells derived use a different set of files (.login, .cshrc, ..).

What exactly would in put in each to achieve an identical environment for every shell?

If you mean environment in the sense of environment variables, just set all of them in ~/.profile and you are OK. If you mean environment in a broader sense, it depends.

The issue here is that it is not desirable to have the very same environment for interactive and login shells. An example is aliases: Maybe you want aliases in your interactive shell, but very likely they will make your scripts do weird things. So you don't want your aliases in non-interactive shells => put them in ~./bashrc.

  • My understanding is that .profile will be loaded by sh too, while .bash_profile just by bash, so you should not put things that only work in bash in .profile. So, I'm actually putting most things in .profile, some in .bashrc, and sourcing both in .bash_profile. Makes sense? – kch Aug 6 '09 at 8:22
  • Although this answer doesn't directly help, it inspired me to think of "How about make a nonsense file that nothing recognises such as ~/.my_shell_conf and then just source it by your different shell scripts where it makes sense to " – Kent Fredric Aug 6 '09 at 8:26
  • @ksh: Makes sense absolutely. – Ludwig Weinzierl Aug 6 '09 at 8:33
  • @Kent Frederic: I agree, but I think you would ultimately end up sourcing your ~/.my_shell where I source ~/.profile. – Ludwig Weinzierl Aug 6 '09 at 8:42
  • 1
    C shells also read ~/.cshrc files. – Jonathan Leffler Aug 6 '09 at 9:46

I fix things so that almost all my setup is done by the login shell and almost nothing on the per-shell basis. That means my .profile file is complex; my .kshrc file (analogue of .bashrc for Bash and .cshrc for C shell) is non-existent. I've never found that to be a problem. It also means that non-login shells are are swift as possible - they don't go poking around for files to parse for commands that they won't use. This might be a hangover from the days of Bourne shell - when the per-shell scripts didn't exist. But I've never found anything that demanded such specialized treatment.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.