.bashrc .profile .bash_profile

Scott Haneda talklists at newgeo.com
Fri Oct 2 13:14:48 PDT 2009


Thank you! comments below...

On Oct 1, 2009, at 5:21 PM, Brandon Allbery wrote:

> On Oct 1, 2009, at 17:41 , Scott Haneda wrote:
>> I need to understand this once and for all, there is varying info  
>> on this, the bash man page is verbose and not entirely clear.
>>
>>     When  bash is invoked as an interactive login shell, or as a  
>> non-inter-
>>     active shell with the --login option, it first reads and  
>> executes  com-
>>     mands  from  the file /etc/profile, if that file exists.  After  
>> reading
>>     that file, it looks for ~/.bash_profile, ~/.bash_login, and  
>> ~/.profile,
>>     in  that order, and reads and executes commands from the first  
>> one that
>>     exists and is readable.  The --noprofile option may be  used   
>> when  the
>>     shell is started to inhibit this behavior.
>>
>> This implies, that only one of those files is read.  That it stops  
>> once it finds one.  I have:
>> .bash_profile, .bashrc, and .profile
>
> bash will read .bash_profile and .bashrc.
>
> I would put bash-specific session-level information  
> in .bash_profile, portable (to e.g. zsh) session-level information  
> in .profile, and have .bash_profile source .profile.  Per-shell  
> information should go in .bashrc.  But I've been doing this stuff  
> for a while, and I can imagine people hndling single files better.   
> (I also use the same shell config files on every system I use, which  
> is a rather wide array of operating systems and versions.)

I do the same, move the files from one machine to that of about 10.   
Can you give an example of what you consider session-level info?

> Normally it is a good idea not to put environment settings, stty  
> settings, etc. in .bashrc.

What specifically is an environment setting?  This means PATH would be  
a bad thing to have in .bashrc?  What I do is work in my user account,  
I have aliases, and other helper things as well as the PATH  
adjustments to MacPorts.

Most of this stuff for me is server stuff, and it gets old typing sudo  
all the time, so I hit up `sudo -s` which drops me into root, even  
though I do not believe I even have root login on.  If I do not have  
my aliases and such in .bashrc, my `sudo -s` env is pretty stark, and  
hard to work in. I do not need all my settings to come over when in  
this `sudo -s` mode, but I certainly would like the macports paths and  
other things to make it.

>> Sounds to me, like the correct course of action is to put my custom  
>> shell aliases and settings
>
> Shell aliases should be in .bashrc.

Ok, that helps then.  so alias l='ls -la' would go in .bashrc just  
fine?  What happens if I were to alias rm to something like rm -i,  
would apps, installers, uninstallers and the like break?  I know they  
should /bin/rm in their scripts to avoid this, but I also want to make  
sure I am not going to break things for others.

>> This brings up a question, if the .bash* files do not cascade, and  
>> stop after finding your local one, how is it that MacPorts suggests  
>> to use .profile, as that will never get read?
>
> MacPoerts assumes you don't use the shell-specific .bash_profile  
> or .bash_login, or if you do you also "source .profile".  I would  
> consider the latter a best practice.

Ok, source it in .bashrc, or .bash_profile?

>> On a side note, I am doing this:
>> export LSCOLORS=dxfxcxdxbxegedabagacad
>> Which has never worked for me on a non darwin OS.
>
> On many systems it's LS_COLORS, not LSCOLORS, and it has a different  
> format.

I have never fully understood this one.  On Mac OS X, what is the  
correct way to color your shell listings?

>> Is that the wrong way to do it, are there more appropriate ways to  
>> do coloring?  I think having this in .bashrc actually hurt me ones,  
>> as MacPorts saw either:
>> 	export CLICOLOR=1 or export CLICOLOR_FORCE=1
>
> CLICOLOR_FORCE will probably cause scripts that use ls to break  
> pretty badly.  MacPorts is itself implemented using scripts.

Ok, I had a feeling I needed to get rid of that, but I believe if I  
do, I lose my colors, so I need to figure out the correct way to set  
my colors in OS X.  Most google searches just have people telling you  
to turn it on. The man page on ls is beyond my understanding on this  
issue.

It seems to me like I need to use the CLICOLOR_FORCE, but with that,  
there are dangers.

Brandon, thank you for taking the time on this one, it is appreciated.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *



More information about the macports-users mailing list