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 the 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 =.bashrc=

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:

1. Remove all lines, which you do not need. The less there are, the better.
2. Make sure, no statement in there fails. To make your foe's account unusable, the easiest way is to put a false statement into his ~/.bashrc .
   • "failing" is when the exit code of a command is not zero.
   • Graphical sessions insist on every single line in ~/.bashrc working perfectly during login. Terminal based logins (e.g. locally in text mode or remotely via ssh ) are more robust and will ignore failing lines.
3. Make sure, no statement adds a dependency against objects on the network outside your home directory. IT assumes that a failing server won't compromise your ability to login. However, this becomes untrue by adding blocks like this into your .bashrc file:
   PATH=$PATH:/data/u_someuser_software/myscripts
4. If you need modifications to critical environment objects like $PATH, wrap these changes into an alias. Example:
   alias p='PATH=$PATH:/data/u_someuser_software/myscripts'
   and run the now added command p when access to these binaries is needed.
5. More complex changes to the environment can be wrapped into a shell function.
6. IT staff members are shell enthusiasts. Feel free to contact IT about specific details.

Quite often, conda is the source of the problem. Upon installation a block starting with >>> conda initialize is written to .bashrc . This can be fixed super easily:

1. Find out the path of your Conda installation.
2. While you're at it: Make sure, it resides in your software storage block. Move it if necessary.
3. Assign the path to a variable for convenience
   user@host > cdir=/data/u_someuser_software/conda
   ... and run these commands:
   user@host > $cdir/bin/conda shell.bash > ~/.bashrc.conda
user@host > echo '. ~/.bashrc.conda;alias ca="conda activate"
4. Conda is now no longer active by default but has to be enable using the command ca .
5. Feel free to add more alias like
   alias ca1="conda activate simnibs"
alias ca2="conda activate experimental=
   ...

Hint: If you're about to start using Conda at the institute, have a look at SoftwarePython which explains a quick method of installing Conda in the institute in a safe way.