Why modify your .bashrc?
There may come a time when you want to customize your default login environment. If you always load the same module when logging in, or want to add other definitions for your login shell to process, that means editing the .bashrc file in your home directory. This runtime configuration file is processed (or 'sourced') by bash, the default shell on Odyssey, when you log into a node and by your jobs when they run. Any time a new shell is created by your user, this file is sourced.
As you might imagine, you need to be very careful not to break your .bashrc or you may not be able to log in. If that should happen, contact us and we can copy in a default .bashrc for you so you're able to log in again.
The default FASRC .bashrc file contains the following:
# .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # User specific aliases and functions
# User specific aliases and functions section is where you should put any customizations of your .bashrc as that will cause them to run after the global definitions have been sourced.The
# Source global definitions section is where the default Odyssey-wide definitions are sourced. The /etc/bashrc file includes definitions necessary to make your jobs and other interactions run properly across the cluster. Please do not remove this section as you will run into problems as a result.
For instance, your .bashrc may contain the Odyssey2 module definitions call there. If you see
source new-modules.sh, that's what that is. On Odyssey3 you can leave or remove is as it's benign after the CentOS 7 upgrade.
Editing your .bashrc
In order to edit your .bashrc, you'll need to be comfortable with a command-line editor such as
nano (probably the easiest to get started with) or
vi). You may also be able to edit the file using your SFTP client of choice, but experiences may vary. We'll assume here that you're using
From a login or other node on the cluster, type nano ~/.bashrc to open the file in the nano editor. My .bashrc has already been added to, so you'll see additional definitions below the
# User specific aliases and functions section.
Let's look at what those additions do and how they fit into the larger bash login environment. And we'll add one more.
> THE GLOBAL DEFINITIONS
> THE USER'S DEFINITIONS
>> MY CODE TO CHECK WHETHER I'M LOGGING INTO A SPECIFIC SERVER
>> IF YES, THEN SOURCE A SHORT SET OF ADDITIONAL DEFINITIONS
>> IF NO, THEN SOURCE MY FULL SET OF DEFINITIONS (MODULES, etc.)
>> DONE. FI IS THE BASH COMMAND THAT TERMINATES AN IF STATEMENT
>> I HAVE A SET OF ALIASES THAT I ALWAYS WANT SOURCED NO MATTER WHERE I LOG IN
>> LET'S SAY I WANT TO ALWAYS LOAD THE GIT MODULE REGARDLESS OF WHERE I LOG IN
>> YOU CAN ADD A MODULE LOAD STATEMENT AT THE END (NOT RECOMMENDED)
>> BUT IT'S BETTER TO PUT ALL YOUR MODULE LOADS INTO A FUNCTION
>> THEN ANY TIME YOU NEED TO LOAD THEM ALL, YOU SIMPLY CALL THE FUNCTION
# Load my module favorites by invoking 'mymodules'
You're free to experiment with your .bashrc, but please do remember that you can break your access while doing so. A good practice to mitigate this is to open two shells before editing your .bashrc so that, if you break your login environment, you're still logged into that other shell (.bashrc is only sourced on login, so that shell will be 'normal') and can likely fix or revert the damage from there. It's a good idea to make a copy of your working .bashrc first before editing it.
If SFTP is failing because your .bashrc causes output to STDOUT (echo, etc.)
You can try wrapping your interactive needs inside a statement that tests for an interactive shell. This may not work 100% of the time:
if [ -z "$PS1" ]; then
# non-interactive stuff, if any, here
# interactive stuff here
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at Attribution.