Dr. Mark Humphrys

School of Computing. Dublin City University.

Home      Blog      Teaching      Research      Contact

Search:

CA216      CA249      CA318

CA400      CA651      CA668


Configuration files




Hierarchy

Configuration files differ across different types of Unix/Linux. It can be quite complex.

Often instructions can be put in multiple places and you may not notice the difference, depending on how you work.

Hierarchy is:

  1. OS system-wide files (not to be modified, rebuilt in OS upgrades)
  2. Local install system-wide files (modified by local sysadmins for all users)
  3. Personal config files (in home dir, apply to one user, edited by one user)



Config files for DCU setup

The following shows some of the main config files for our default setup at DCU (bash on openSUSE).



Run at login to GUI and/or login shell (e.g. ssh):

file Hierarchy notes
/etc/profile OS  
/etc/profile.d/* OS directory of scripts to run
see code in /etc/profile
/etc/profile.local Local Local install to extend /etc/profile
~/.profile Personal  
~/.bash_profile Personal bash specific


Run for interactive shell that is not login shell (e.g. new terminal in GUI):

file Hierarchy notes
/etc/bash.bashrc OS bash specific
/etc/bash.bashrc.local Local Local install to extend /etc/bash.bashrc
bash specific
~/.bashrc Personal bash specific


Run for non-interactive shell (e.g. shell script):

file Hierarchy notes
$BASH_ENV Can point to any file.
Not set up in DCU install by default.
Beware of infinite loops!
Q. How could there be an infinite loop?



DCU setup:
  1. new terminal in GUI:
    runs .bashrc

  2. ssh login:
    runs .bashrc and then .bash_profile (or .profile if previous is not found).
    On some setups, only .bash_profile might run, so to get it to run .bashrc you add this line:
    source $HOME/.bashrc

Explore yourself: Add instructions to these files and see where they are executed.



Config files for alternative C shell

Some config files used by C shell (read the manual page for details of when called):



How to change the PATH

You plan to put your own programs in some directory.
We will put them in a $HOME/bin ("binary") directory.
To call them by typing their names, you need to change the PATH to include that directory.

openSUSE already includes $HOME/bin in PATH

If you are using openSUSE (e.g. at DCU) then $HOME/bin is already in the PATH, if it exists.

See: /etc/profile
This defines the system-wide PATH.
Note that this contains code:


    if test "$HOME" != "/" ; then
        for dir in $HOME/bin/$CPU $HOME/bin ; do
            test -d $dir && PATH=$dir:$PATH
        done
    fi

i.e. If $HOME/bin exists, it is automatically put in path.
If $HOME/bin does not exist, it will not be in path.

So (at DCU) you only need to create the directory, log off, log on again.


DCU install may add it twice

Some DCU accounts have a line in the local (DCU install) default copy of .bashrc that adds $HOME/bin to the PATH. So you may get it twice.
If so, you can delete that line.

How to change the PATH manually

On other OS versions or setups, or if you want to use dirs other than $HOME/bin, you will need to manually change the PATH.
  1. Edit .profile or .bashrc (depending on setup)
  2. Add this line:
    export PATH=$PATH:$HOME/bin
    
  3. Could also put current dir (.) in $PATH
    export PATH=$PATH:$HOME/bin:.
    
  4. Log out and in, or close terminal and open new one (depending on setup)
  5. echo $PATH


Do not over-ride system program names

Type "which ls" to see the location of the system ls program.
If you write your own "ls" script, and insert it in a directory in the path which comes before that system directory, then you have over-ridden the system ls.
All calls to "ls" at the command-line will be calls to your program, not system ls.

This may be ok for you, but other programs that call ls will now be calling your version instead.
They may fail in unexpected ways.

Recommended:

  1. Put . and your own dirs at end of PATH, not start. (Note openSUSE does not follow this!)
  2. Do not use system command names. Do "which scriptname" before choosing a script name to make sure it does not already exist.

"." in the PATH can be a security risk

Why?

Also, if you are in someone else's directory, and read is off and "." is in the PATH, you will find strange effects.





How to set up aliases

Text substitutions at the command line.

In .bashrc:

alias name="string"

alias h='history'

alias cdshare="cd $HOME/share"

In .cshrc:
alias name string


For instance (on C shell):

If you regularly need to login to some other server, put the following in .cshrc:
  alias t 'ssh -l userid remoteserver'
and then, to connect to it, just type:
  t
Or if you regularly need to jump to your web directory, put the following in .cshrc:
  alias cdp 'cd $HOME/public_html'
and then, any time you want to jump to that directory, just type:
  cdp


This straight text substitution at the command-line is more efficient than starting up a Shell script that needs parameters set up for it (environment variables, command-line arguments) and then needs to be interpreted.
It is like the difference between a macro text substitution (e.g. a #define in C/C++) and a run-time procedure call.

In fact, in the case of "cdp" above, a Shell program won't work since a Shell program can't change the directory of the parent process that called it.




How to change the prompt

Edit .bashrc


# PS1='[\H] [\u] [\w] > '

PS1='\W> '  

See:


Feeds      w2mind.org

On Internet since 1987.