[Discuss] What the use of .bashrc

[gaf at blu.org (Jerry Feldman)]

The big win with pathmunge() is that it does check. Every time you run a
command in Linux (or Unix), your $PATH is checked until the command is
found. The order of things in the path is also important.
First, NEVER have dot (.) in your path. That is a very big security
risk. Usually you want something like
$HOME/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin
Some people do not like sbin and /usr/sbin in their paths. Sometimes,
products are installed in /opt, so you want those in your path.

One other thing for Glenn is that different Unix systems have different
default shells. For instance, Linux systems generally use BASH as the
default. Some commercial Unix systems use iether the POSIX Shell (Bourne
with POSIX compliance) or KSH. And usually Solaris uses CSH because one
of Sun's founders, Bill Joy, wrote csh. (Actually if I remember
correctly it was a hacked version of Bourne).


On 10/30/2012 11:29 AM, John Abreau wrote:
> Interesting. I had written my own, ages ago, but I made them two
> separate functions. Also, they work not only for PATH, but for
> any similar environment variable such as MANPATH, CLASSPATH, etc.
>
> I never made them check for a pre-existing instance, though; they were
> simple one-liners. Thanks for the tip; I'm updating them to do that.
>
> Usage:
>
>     prepend-path PATH /path/to/bin
>     append-path PATH /path/to/bin
>
> prepend-path() {
>         case "$1" in
>         *:"$1":*)
>                 ;;
>         *)
>                 eval "$1=$2:\$$1" ;;
>         esac
> }
>
> append-path() {
>         case "$1" in
>         *:"$1":*)
>                 ;;
>         *)
>           	eval "$1=\$$1:$2" ;;
>         esac
> }
>
>
> On Tue, Oct 30, 2012 at 10:36 AM, Jerry Feldman <gaf at blu.org> wrote:
>> On 10/30/2012 10:13 AM, Rich Pieri wrote:
>>> On Tue, 30 Oct 2012 07:50:48 -0400
>>> Glenn Hoffman <glennhoffman at mac.com> wrote:
>>>> existence of .bashrc, since I have never used it myself. What's the
>>>> reason for a separate startup file for a non-login interactive shell?
>>> As a matter of principle, an interactive session should have one and
>>> only one login process associated with it. That's the login shell,
>>> whether it's BASH or something else.
>>>
>>> As a matter of practice, logging in on the console is a little
>>> different from starting a screen session. Having separate login and
>>> non-login run command files makes this easy keep sane. This is just one
>>> practical example among many.
>>>
>> Agreed. In the case of a Gnome or KDE session, it is the session that is
>> effectively the login shell. but neither gnome nor kde parse ~/.profile.
>> They generally use xinitrc.
>> The bottom line is it is, IMHO, best to set your path, environment
>> variables and  aliases ~/.bashrc. There is a very nice function in
>> /etc/bashrccalled pathmung() that allows you to add path variables to
>> your path either at the beginning or end but without duplicating anything:
>> pathmunge () {
>>     case ":${PATH}:" in
>>         *:"$1":*)
>>             ;;
>>         *)
>>             if [ "$2" = "after" ] ; then
>>                 PATH=$PATH:$1
>>             else
>>                 PATH=$1:$PATH
>>             fi
>>     esac
>> }
>>
>> If you read the function, it first tests to make sure your element is
>> not already in $PATH. In the default case '*)' it looks if you have
>> specified, 'after', and if so, it appends the element to your path,
>> otherwise it prepends.
>
>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90