This page has instructions for various tasks you might wish to do to customize your environment or perform a few other common tasks under the Linux operating system running on the Shared Computing Cluster (SCC).


Setting default project

Each account on the system has an assigned default Project. Any computing resources you use will be applied to it. You can see the list of projects that you belong to by typing “groups” on the command line. The first one listed is your default project. Note that Projects are implemented as Linux groups.

Four ways to control your default project:

  1. When you submit a job you can override the default by using the -P projectname flag.
  2. For frequent use, you can include it in your .sge_request file in your home directory.
  3. You can change the project for the current session by typing newgrp projectname on the command line.
  4. You can permanently change your default project on your individual Research Computing User Information page. Your default project will be changed the next time the system configuration files are updated, generally overnight.

Changing your shell

New accounts on the SCC are currently set to use the bash shell . You can switch to  the tcsh or zsh shell on your individual Change Shell Form. You can run the command printenv SHELL to see which shell you are using.

Setting up basic dotfiles

Dotfiles are files, generally in your home directory, with names starting with the dot/period (.) character. These files control such things as your Path, which is where the system looks to find programs to run when you type a command.

These files (such as .bashrc, .cshrc, or .login) are set to reasonable defaults for new accounts and you should be very careful in modifying them as it can lead you to be unable to log in to the system or cause other major difficulties using your account. If by any chance you delete or corrupt one of your dotfiles, you can run the command /usr/local/bin/dotfiles to back up your existing dotfiles and install new dotfiles which should provide you with a good, basic working environment.

Here are some of the  dotfiles that are likely in your home directory.

  • bash users -> .bashrc – This file is usually the one which is modified, for bash shell users, to change your path or set environment variables.
  • tcsh users -> .cshrc – This file is used just like its bash equivalent .bashrc for tcsh users. This file could also be named .tcshrc.
  • zsh users -> .zshrc – This file is used just like its bash equivalent .bashrc for zsh users.
  • all users -> .forward – This file is used to forward your email and is explained in Setting up a .forward file section.
  • all users -> .login – This file is executed upon login and is an alternative place to your .bashrc or .cshrc file for actions/changes you want taken every time you log in.

Setting up a .forward file

We regularly send email to so it is important that you read this mail either directly on the SCC or have it forwarded to where you do read email.

If you have a file in your home directory named .forward, all email sent to that machine will automatically be forwarded to the email address in that file, such as as is set up by default for new internal BU accounts. External users will likely wish to set up an appropriate .forward file by for example doing:

scc1% echo "" > .forward

Sourcing files

Sourcing a file basically means to run it as a script. It is done most often with dotfiles and files which set up basic environment variables and other things needed to run a given application.

In order to source a file, such as your .bashrc, you simply need to run the command:

scc1% source .bashrc

If you find yourself sourcing a given file almost every time you log in, you may want to add the appropriate source command to one of your dotfiles, such as your .bashrc or .cshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to either directly source the original file or source the .bashrc or .cshrc file you just changed.

Adding items to your path

Your path defines in which directories, when you type a command, the machine will look to find the command you typed. If the system returns a message saying “command: Command not found“, that indicates that either the command doesn’t exist at all on the system or it is simply not in your path. For example, to run exampleapp, you might need to directly specify the exampleapp path (/usr/sbin/exampleapp perhaps) or you need to have the directory /usr/sbin in your path. If you didn’t have that directory in your path, you could add it to the end of your existing path by issuing the appropriate one of these commands based on your shell:

bash and zsh users ->  scc1% export PATH=$PATH:/usr/sbin
tcsh users ->  scc1% set path=($path /usr/sbin)

Also, note that the order in which items appear in your path is important as, if two items have the same name, the one which is in the directory appearing earliest in your path will be executed. For example, maybe you have written a program and compiled it and named it test. Well, it turns out that a program named test already exists on most systems in /usr/bin/test. As such, if the directory /usr/bin appears before your current directory (represented in your path by a . symbol) in your path and you just type test, you will run the version in /usr/bin/test and not the program you wrote of the same name. To avoid this, you can either put the . at the start of your path (not recommended) or you can specify the full pathname for your version of test by running /usr1/scv/aarondf/test or you can simply not reuse any command names already on the system (recommended). You can find out the full path to a given command you are running by using the command which. In the example given above, which test would likely return either /usr/bin/test or /usr1/scv/aarondf/test, depending on how your path was set up. You can add items to the front of your path by modifying the commands above so that the $PATH (for bash and zsh users) or $path (for tcsh users) appears after the directory you are adding or you can totally replace your path by leaving out the $PATH or /$path entirely (not recommended).

As with sourcing files above, you can add path changing commands to your dotfiles, such as your .bashrc or .cshrc, so that you do not have to change your path manually every time you log in. In fact, this is generally a very good idea to do. A good practice is to put the most important directories towards the front of your path (examples: /bin, /usr/bin, /usr/local/bin) and your current directory ( . ) and application-specific directories towards the end of your path.

Setting environment variables

Unix uses environment variables to keep track of defaults for all sorts of purposes. For example, the variable HOSTNAME is usually set to indicate the name of the system you are on, such as scc1. All environment variables have names in ALL CAPS and you can get a list of all the environment variables you currently have set by issuing the command printenv. You can set an environment variable by doing the following, based on your shell. This example command is changing the default editor.

bash and zsh users ->  scc1% export EDITOR='/usr/local/bin/emacs'
tcsh users ->  scc1% setenv EDITOR /usr/local/bin/emacs

As with sourcing files above, if you find yourself setting a given environment variable almost every time you log in, you may want to add the appropriate setenv command to one of your dotfiles, such as your .bashrc or .cshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to source the .bashrc or .cshrc file you just changed.

Loading modules

Modules are a relatively easy way to load a specialized software packager or particular version of a package that is available on the system but not set up for you by default. You can set a Module up to load automatically on login by adding it to your .bashrc or .cshrc file (as appropriate for your shell) as explained here. Be warned, however, that if you do this you might end up somewhat confused later if you forget what you did and load a different module for the same package, which can cause issues.

Creating and using a .rhosts file

An .rhosts file on a given machine is used to allow trusted access to given host/user combinations without the need for a password. This has security advantages and disadvantages. The disadvantages are obvious: if a user gets access to your account on one machine, he may automatically have access to accounts on various other machines. On the other hand, using .rhosts files reduces the number of times you need to type your password and this is a security advantage.

For security reasons, we do not allow the use of .rhosts files into our systems from non-SCC systems. However, you can use an .rhosts file to switch among the machines in the SCC without needing a password.

Creating a .rhosts file and using it to log in between SCC nodes

A .rhosts file is a simple text file which you can create in any editor with a series of lines of the form “remote_hostname username” specifying that a given username on a given remote system is trusted to automatically access the machine. This file must be named .rhosts and must reside in your home directory. For example, assume the following was my (username: aarondf) .rhosts file on aarondf

Given this, I could run ssh scc2 from to log in to scc2 without needing to enter my password. Since one’s home directory is shared between all of the SCC nodes, I could in fact log into any SCC node from without needing my password.

Copying files between SCC nodes using a .rhosts file

Use the command scp (secure copy) to copy files/directories from one system to another without needing a password. For example, given the .rhosts file example above I could do the following:
Copy a file from my home directory on scc1 to my home directory on scc2.

scc1% scp /scratch/testfile scc2:/scratch/.

See the man page on scp for more information and help. On the SCC, this is usually only needed for files in /scratch since most other directories are shared among all of the SCC nodes.

Listing and killing stray processes

Users often accidentally can leave background processes running and consuming resources. These stray processes should be eliminated. To get a list of all the processes you have running on a given machine, use the ps command:

scc1% ps -ef | grep your_login_name | more

and this will return a list of the form:

aarondf   7064  7062  0 11:49 ?        00:00:00 sshd: aarondf@pts/20
aarondf   7065  7064  0 11:49 pts/20   00:00:00 -tcsh
aarondf   7110  7065  0 11:49 pts/20   00:00:00 ps -ef
aarondf   7111  7065  0 11:49 pts/20   00:00:00 grep aarondf
aarondf   7112  7065  0 11:49 pts/20   00:00:00 more

You can kill a given process by doing the command kill -9 PID:

scc1% kill -9 84190

The “-9” is not always necessary but makes sure that you kill the process. You can, of course, only kill your own processes. If there are a large number of runaway processes of other people on the system, you can send mail to and ask us to kill them.

Additional help/documentation

If you have problems or questions on any of this, please send email to

We also have a tutorial on Linux which we generally offer live three times a year but for which the slides are always available.