Dr. Mark Humphrys

School of Computing. Dublin City University.

Home      Blog      Teaching      Research      Contact

Online coding site: Ancient Brain

coders   JavaScript worlds


CA170      CA668      CA686

Online AI coding exercises

Project ideas

Configuration files


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 the default setup at DCU last time I looked (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 (PATH automatically set up)

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

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.

Other installs (manual change PATH)

On other Linux/Unix installs, $HOME/bin may not be in the PATH.
You need to manually change the PATH.
You also need to do this if you want to use dirs other than $HOME/bin.
  1. Edit .bashrc (or some similar config file, depending on setup)
  2. Add something like 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. (There is another way to implement changes, but log out and in will work.)
  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.


  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


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

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


ancientbrain.com      w2mind.org      humphrysfamilytree.com

On the Internet since 1987.

Wikipedia: Sometimes I link to Wikipedia. I have written something In defence of Wikipedia. It is often a useful starting point but you cannot trust it. Linking to it is like linking to a Google search. A starting point, not a destination. I automatically highlight in red all links to Wikipedia and Google search and other possibly-unreliable user-generated content.