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:
OS system-wide files (not to be modified, rebuilt in OS upgrades)
Local install system-wide files (modified by local sysadmins for all users)
Personal config files (in home dir, apply to one user, edited by one user)
Personal config files
You can customise your environment by putting commands into personal config files.
Default shell at DCU is
bash
There are global config files
and bash-specific config files.
These are run in login shell (e.g. ssh) or login to GUI:
file
type
notes
$HOME/.profile
global
Change PATH in here.
$HOME/.bash_profile
bash specific
See below.
This is run in non-login shell (e.g. new terminal in GUI):
file
type
notes
$HOME/.bashrc
bash specific
Set aliases in here.
Change prompt in here
.bashrc may or may not also be run by login shell.
It depends on setup.
.bash_profile
On some Linux setups:
ssh will only run .bash_profile not .bashrc
GUI terminal will only run .bashrc not .bash_profile
So where do you put your commands?
Solution for those setups:
Get .bash_profile to run the commands in .bashrc (and maybe run the commands in .profile too).
Put the following in .bash_profile:
source $HOME/.profile
source $HOME/.bashrc
DCU Linux setup can change from year to year, so experiment with:
alias h="history"
alias cds="cd /users/tutors/mhumphrysdculab/share"
This text substitution at the command-line
is more efficient than starting up a program to do the job.
In fact, in the case of the change directory alias, a program won't work
since a program
can't change the directory of the parent process that called it.
What is customisation (like changing prompt) for?
Just cosmetic?
No. Imagine you have multiple ssh windows open.
In Jan 2017, an admin at
GitLab
typed the "remove database" command into
the production/live ssh window by accident,
rather than the development/backup ssh window.
The video explains the disaster.
Apart from the technical issues that would have stopped it, there are simple things
to help stop such disasters in a work environment:
Make the prompt on the production server something dramatic like:
[WARNING: PRODUCTION SERVER] >
Make the production ssh session background colour red, as a warning of where you are.
Never rm directories. Just rename them. You can delete them later, when everything is working.
You can delete them a month later. What's the hurry?
To continue that idea,
obviously your normal backups should work, but if you just rename directory, your backup is sorted already!
Never type rm dir or other dangerous commands raw. Put them in scripts.
The script will do the error checking of host, database, directory.
Only run the scripts.
e.g. Don't update your website by copying files to production with cp, mv, rm.
One day you will type the sequence wrong, or on the wrong server, or in the wrong dir.
Put it all in a script.