17.14. Dot Files and .bashrc

There are a number of dot files and dot directories in the Unix filesystem. Dot files are files whose name starts with a . character. These files are typically hidden because the ls command does not list them by default. To view these hidden files, use the -a command line argument to ls. For example:

$ ls

$ ls -a
  .   ..    .bashrc   .vimrc    .xsession  /unix_notes

Two dot directories are always present in every directory: . is an alias for the directory itself, and .. is an alias to its parent directory. As we saw in Section 17.1, . and .. are often used in relative path names. For example, a common use of .. to move up one directory (to change the current working directory to be the parent of the current directory):

$ cd ..

The . entry also commonly appears in commands that run an executable file from the current directory by prefixing the command with ./ For example, to run a.out in the current working directory, a user would type the following:

$ ./a.out

Many dot files are configuration files (or directories of configuration files) for different applications. These dot files contain application-specific options that can change how the application behaves. Application dot file contents are evaluated by a program when it first starts up to configure its behavior. Many of these dot files can be edited by a user to customize the behavior of the programs they run. Here are a few examples of these types of dot files:

  • .bashrc: a configuration file for the bash shell program set environment variables, define command aliases, …​

  • .vimrc: a configuration for the vim editor define color and highlighting scheme, encoding, …​

  • .xsession: # a configuration file for the X Windows managers that are started after login on a terminal. set background color, define some default behavior start some applications, start a specific window manager (which has its own config dot files)

17.14.1. The .bashrc File

Unix shell configuration files (e.g., .bashrc for the Bash shell) contain entries that change the behavior of the shell. Typically a system administrator sets up a default .bashrc file for the system. However, individual users often want to customize their shell further, and they can do so by editing the .bashrc in their home directory.

The shell reads the .bashrc file when it first starts up. Thus, changes to the .bashrc file do not take effect unless the user runs source .bashrc or restarts bash.

Two common changes that users make are changing the definition of shell environment variables and adding command aliases (a user’s shorthand for commands that they commonly run). Shell environment variables are used by the shell to determine how certain shell features work. To list all the environment variables, use the env command, or list the value of a particular environment variable using echo $env_var_name. For example:

$ echo $GROUP    # list your default unix file group

$env             # list value of all env vars (a lot)

The PATH environment variable is particularly interesting—​it lists the set of directories in which the shell searches (in order) for programs when the user enters a command at the shell prompt. For example, given the definition of PATH shown above, if a user enter the ls command, the shell will first look in the /usr/bin directory for it (the shell looks for an executable file named ls) and runs it if found. If ls is not found in /usr/bin, then the shell next looks in /usr/local/bin, and if it is not found, it next look in /bin, and if it is still not found, the shell prints out error message saying that the ls command is not found. The PATH environment variable is the reason why users do not need to list the full path name to common commands, like ls, when they run them!

Because there may be multiple versions of the same program in different locations, the order of the directory names in $PATH determines which one is run. A user can see which version of a program they are running using the which command. For example:

$ which ls

Users can also redefine PATH in their .bashrc files to change the order of the paths searched by Bash or to add additional search paths. For example, if Sarita creates her own utility programs that she often runs, she may want to put them in a directory named mybin in her home directory and then update her PATH environment variable to include this directory so that she can run them without listing their full path name each time. She could do this by modifying the existing definition of PATH in her bashrc file or by adding an additional definition of PATH like the following:


This definition appends her mybin directory to the end of her existing PATH environment variable (set PATH to the current value of PATH with another path called /home/sarita/mybin).

When Sarita starts a new Bash shell, or if she types source ~/.bashrc in a currently running Bash shell, her path will be updated to include /home/sarita/mybin/.

Another common modification to a .bashrc file is to add shorthand aliases for either commonly typed commands or commands that ensure they are always run with specific command line options. A common example is to alias the command rm -i to be rm. This ensures that anytime the rm command is entered on the command line, the shell actually executes rm -i, which prompts the user to confirm that they really want to delete the file before removing it. Here is how to add this alias for rm in a .bashrc file:

alias rm="rm -i"      # add alias for rm to double check

Similarly, if Sam is frequently running the command cd ~/classes/CS31/, he may want to add a shorthand Bash alias for this command to his .bashrc like this:

alias gt31="cd ~/classes/CS31"  # goto (cd) into my CS31 directory

Then Sam could start using these new aliases. For example:

$ source ~/.bashrc    # source: make bash re-evaluate .bashrc file

$ rm notes            # rm is now an alias for rm -i
rm: remove regular file 'notes'? n
$ ls
classes/  letters/  notes  projects/

$ rm notes
rm: remove regular file 'notes'? y
$ ls
classes/  letters/  projects/

$ gt31
$ pwd

17.14.2. References

For more information see: