.bashrc .profile .bash_profile

[Scott Haneda]

Thanks for all this great info, I think I am getting a handle on it  
much better now.  I always had it hobbled together, but do believe I  
am getting to a point where I understand the repercussions of the  
files and settings I am creating.  More comments inline below...

On Oct 2, 2009, at 9:19 PM, Brandon Allbery wrote:

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

Understood, thanks.

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

I started to read up on this the other day. Your mention of cycles  
seems to be more relevant ages ago, when a new shell could take quite  
some time to start, as it has to load all the actions it was told to.  
I suppose, with so much CPU to spare these days, no one much thinks  
about this.

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

I am not sure where I picked up `sudo -s` but I have been using it  
going back to 10.2 or so.  Reading up on `man sudo` I learned that  
`sudo -s` is just running the shell as specified in the SHELL in ENV.

$ENV | grep SHELL
SHELL=/bin/bash

It appears in my shell's case, `sudo -s` is simply going to run `sudo / 
bin/bash`, which it gets out of ENV.

A few things I am still not grasping, is that you state that "sudo is  
not root".  I export my PS1 as this: export PS1="\u@\h \W $"

With that, I get \u for username. My default prompt on making a new  
terminal window:
me at macbook ~ $

If I `sudo -s` or longhand it with `sudo /bin/bash` my PS1 setting  
will look like this:
root at macbook ~ $

Can you explain why, if I am not root, the shell thinks that \u is in  
fact root?

What I like about this, is it takes with it most of my ENV, but also  
treats me more like a root user that is masquerading as my normal  
user.  For example, as `sudo -s`, a few things to take note of:

$sudo -s
$pwd
/Users/me

$cd ~
root at macbook ~
$pwd
/Users/haneda
( ie: not dropped into roots ~ )

Even though I am listed as user root, my home is not that of root, but  
my home.  Along with that, I get my SSH_AUTH_SOCK, HOME,  
CLICOLOR_FORCE, PATH, and most all of the other settings I am used to  
having.  I just do not have to deal with prefixing sudo on everything.

I try to prefix most of my work with sudo, usually that works fine.  
The reasons I drop into `sudo -s` is entirely tab completion.

Say that I have a path in which the permissions are restrictive enough  
that my admin user can not get to it.  If I try to:
sudo cp /some/place/that/I/have/no/permissions/file.txt /opt/local/ 
some/other/place
I will not be able to use tab completion, the second I hits a  
directory with restrictive permissions, I have to type out the path by  
hand, which I never can spell correct.

If I am in `sudo -s` I ca tab complete any path I desire.  Is this bad  
practice?  I should really just `sudo` all my commands and struggle  
through the really long paths?

In my testing of all this, I added in "echo 'this is .profile';" and  
similar to all the dot files, at line #1, so as I was moving around, I  
could see what was being sourced, and if I had been sourcing files in  
the correct way.  I learned a lot from this.

I usually set up a line like that on all my remote machines, so when I  
ssh in, I am greeted with something that tells me what machine I am  
on.  Most have the same username, and I try not to add too much data  
to the PS1 setting, as long paths can do strange visual things for me  
with line wrap.

This has never caused me any issues.  However, I tried to use  
Interarchy, to ssh/sftp into a remote host, something I do all the  
time, and this time around, I got a login failure.  As soon as I  
removed my echo statements that were printing out which files were  
being sourced, I was allowed login again.

Do you think this is a client issue, with Interarchy, or do I need to  
perhaps echo those statements out in a different way, in some way that  
returns data, rather than prints out a string?

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

I get curious, :) you sent another email with some good links and  
references in them, I will be going thought them.  My experience shows  
they *are* inherited..

alias l='ls -lAG | grep -v DS_Store'
alias traceroute='traceroute -I -q 1 -w 2'

those are two of many I have set in .bashrc at the moment.  In either  
a normal login, locally, or ssh, where I have copied the .bashrc, I  
can use `l` as a way to trigger the alias above.  If I `sudo -s`, I  
also get the alias to work.

me at macbook ~ $alias | grep trace
alias traceroute='traceroute -I -q 1 -w 2'

sudo -s
****

root at macbook ~ $alias | grep trace
alias traceroute='traceroute -I -q 1 -w 2'

I just also noticed, with `sudo -s` I also get full use of  
my .bash_history, so control-r is still useful under that condition as  
well.

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

Cool, very good to know.  This all came from a few years back, there  
were several posts, I believe one on macosxhints, on exactly this.   
This may have been in the tcsh days so a little different.

The core idea, was to alias `rm` to `rm -i`, and how doing so would  
break many other scripts and apps.  I walked away thinking, whatever  
the case may be, that the developer of the app or script should not  
use `rm` but should fish out the real path toe `rm` and use the full  
path.

If they know the deployment OS, they would not even have to fish it  
out, but just know where it is, and use /bin/rm, which before they  
started the work of the script, they could do some small unit tests on  
it, to make sure it works as they expect it to.

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

Here is what I am doing now:

$cat .bash_profile
if [ -f ~/.bashrc ]; then
         source ~/.bashrc
fi

$cat .bashrc
export PS1="\u@\h \W $"
...
alias traceroute='traceroute -I -q 1 -w 2'
... more aliases
export ..... a few things here and there.
# For MacPorts, so I can edit in textmate locally, if remote, I use  
pico/nano
export DISPLAY=:0.0
export EDITOR=/usr/bin/pico
if [[ -z $SSH_CLIENT ]]; then
	export EDITOR=/Users/me/bin/mate
else
	export EDITOR=/usr/bin/pico
fi;

$cat .profile
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH

* Nothing sources .profile, but PATH looks good to me:
$echo $PATH
/opt/local/bin:/opt/local/sbin:/opt/local/apache2/bin:/Users/me/bin:/ 
usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

** Wow, that was a mouthful, hope you were able to follow along, as I  
barely was :)

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

So, can I use it and not export it?  It seems in all examples I can  
find, CLICOLOR_FORCE needs to be exported, but maybe there is a "set"  
way to do it, 'SET CLICOLOR_FORCE' in which case it would not be  
exported, but just available to me for my session?

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

There is no shortage of data, but mix that with unix, linux, bash,  
tcsh, and all the rest, sprinkle in some general misunderstanding of  
how this all works, and it seems better to get answers from people who  
can answer "why", and not those who just say "paste this in the  
terminal"...

Thank you again for all this, I will do my best to grok it all, and  
get it written up somewhere that others may benefit from it.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *