Avoiding problems related to personal .bashrc files

Permanent Link:

Overview

The .bashrc file and its brothers .profile, .bash_login and .bash_profile are convenient ways to influence your work environment (Explanation). They are used to define colors, set environment variables, make aliases, create shell functions, etc.

However,

• new researchers often receive blocks of ~/.bashrc lines from colleagues, incorporating those into their personal files.
• and some software writes critical lines into these files without the user knowing or realizing.

TRY TO AVOID THAT!

It is crucial to fully understand every single line in your ~/.bashrc file! If unsure about a line, remove it. Erroneous statements can lead to long timeouts due to unavailable location paths, or even render your account unusable or your computational results inaccurate!

Preferably, only use alias commands or shell functions in your .bashrc. Modifying environment variables directly (e.g. not in an alias) is generally unnecessary and can be very counterproductive. If you have a question regarding the matter, don't hesitate to ask IT via Mattermost or write a Ticket.

Using Environment Wrappers Over Variables in .bashrc

Complex software, like FSL, requires extensive environment setup. Instead of manually configuring your .bashrc, consider using software-specific aliases as shortcuts. There's a lot of Software which requires setup like that. Most of these packages come in different (numeric) versions.

You might feel compelled to enable software (like FSL) by default via export statements in .bashrc : DON'T DO THAT! Continue reading to learn how to use an alias as shortcut instead.

Software Sessions

IT provides simple methods for using pre-installed software. For example, to use FSL version 6.0.3, enter:

user@host > FSL --version 6.0.3

fsl_user@host >

This creates a session with the specified FSL version. Different versions can be used in separate terminals without conflict.

To run a script utilizing FSL commands within this session:

fsl_user@host > myscript.sh

Note: The --version option ensures reproducibility since the it will fail hard if the version is unavailable.

Wrapping a single command

For computations requiring FSL commands, especially in batch environments, use:

FSL --version 6.0.3 myscripts.sh [...]

The [...] indicates script arguments.

Shortcuts

Starting an environment - e.g. via

user@host > FSL --version 6.0.3

is time consuming and error prone when done often. If you put a shortcut definition like this line into .bashrc

alias f="FSL --version 6.0.3"

all subsequently started shells (open a new terminal window to open a new shell) will recognize this new custom command:

user@host > f

to start a FSL session using a never changing FSL release. You can even use it as prefix to run script in the environment of the specific FSL release:

user@host > f myscript-.sh

If you have any questions regarding Shortcuts in the Shell, do not hesitate to ask people who use them all the time .

FAQ

Purpose and usage of files Like .bashrc

Permanent Link:

Command-line environments can be customized similarly to graphical interfaces, using variables for fine-tuning and aliases/functions for command line convenience. Rather than manually customizing each shell session, preferences can be put into files which are executed automatically, affecting a lot or your running programs. However, incorrect settings will lead to subtle program malfunctions.

The ~/.bashrc is the most important of these files. Located in the user's home directory, its content is applied to all shell interpreters that are being started. The "Dot-Command" (. or source) can manually apply these configurations by executing the .bashrc file in the current shell. This file plays a key role in personalizing the shell behavior for the user.

Why does IT discourage files like .bashrc?

Permanent Link:

The use of ~/.bashrc and similar files is discouraged due to potential for unwanted side effects, login issues, software malfunctions, and increased IT workload. Aliases and shell functions are acceptable if declared error-free. When issues arise, IT may require the removal of these files and a re-login before attempting any troubleshooting.

Unintentional Modifications to Such Files

Permanent Link:

Software like Conda may auto-modify ~/.bashrc, assuming a need for omnipresence in your environment, which can be problematic for networked computing environments.

What to do with existing custom lines in .bashrc?

Permanent Link:

If you want to avoid such problems with problematic ~/.bashrc configuration, put the respective line (or block of lines) into a separate file and use the "Dot-Command" whenever you need the respective configuration. Example:

• Conda put some lines into ~/.bashrc
• Move the lines to another file - e.g. ~/conda1.bashrc (the name is up to you - it's just a file).
• Use it when necessary by typing
  user@host > . ~/bashrc.conda1
• Optionally, make your life easier by defining a shortcut. You might want to use the conda configuration by assigning it a short command - e.g. con. This is how it's done:
  • Place this line in ~/.bashrc
alias con='. ~/bashrc.conda1
    This line defines an alias.
  • As long as the new alias name doesn't overshadow an existing important command, you're in the clear.
  • You might want to try it beforehand - in this case by typing con on the command line and see what happens.
  • The alias only works in shells that were started after the change to .bashrc. Just open a new terminal.