.bashrc .profile .bash_profile

[Brandon Allbery]

On Oct 2, 2009, at 16:14 , Scott Haneda wrote:
> 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.

Anything you set with "export".  (Take a look at the output of the  
"env" command.  That's your environment.)  They are inherited by  
subprocesses; the distinction between setting in .profile vs. .bashrc  
is evident if you add a directory containing non-general-purpose  
programs (say Apache, or some commercial packages such as Matlab or  
Cadence) to your path temporarily, as a subshell will lose (or  
override) the change if you set PATH in .bashrc. Since it's not  
unusual to have a script which adds the custom package to $PATH and  
then runs an interactive shell, you'd be undoing the script's work.

stty settings are even more pervasive, as they affect the terminal and  
therefore every program running in it.  Rerunning it every time a new  
shell is created is at best a waste of cycles and at worst can cause  
subtle breakage because stty outputs an error message when it finds  
it's not running in a terminal.  (scp is where people usually notice  
this, although there are some vi and emacs commands which can also  
trigger it.)

> 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.

"sudo" isn't root login.  If you enable root login, you could use  
"su", or you could log into OSX as root (not recommended; I'm not even  
sure it's sane to log in with the GUI, as opposed to suppressing the  
GUI startup and getting a Darwin login prompt).  sudo is generally  
preferred to enabling/using root directly.

> 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.

Aliases aren't inherited; they belong in .bashrc.  (Shell functions  
can be inherited, but now we're getting into distinctions you probably  
don't want to know, much less care, about.)

> 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.

.bashrc is (except in special cases like vi) only read by  
*interactive* shells, precisely for this reason; scripts won't get  
your aliases.  There is a mechanism you can use ($ENV) to force  
aliases and such on noninteractive shells, but it's generally a bad  
idea.

>>> 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?

.bash_profile

>>> 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.

CLICOLOR is the correct one to use, as it affects only interactive  
"ls".  CLICOLOR_FORCE will also affect scripts, with similar results  
to the above discussion --- except that, because you "export" it, it  
affects more programs.  Note that because it's exported, it is still  
dangerous even if you set it in .bashrc in an attempt to only affect  
interactive shells.

(I wonder if I can find a good description of what's going on here  
somewhere.  It *is* kinda confusing for beginners.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20091003/2af57ee4/attachment.bin>