NB: this post has been superseded by my more recent post on conda and bash configuration
Gadi’s shell system and conda init interact poorly, requiring one to use login shells (bash -l) in PBS jobs to be able to access conda.
Gadi only sources ~/.bashrc for login shells, and not for batch jobs. This is correct by a strict interpretation of bash’s guidance, and allows one to put e.g. complex or resource intensive things only useful during interactive use in ~/.bashrc. The conda package manager puts its initialisation code (generated during install or conda init) into ~/.bashrc, which is also sensible as this file is sourced by the vast majority of shells any user will interact with (e.g. via a terminal emulator on a laptop/desktop, or on a virtual machine or cluster head node).
However, most of the actual use of clusters like Gadi is non-interactive, in Gadi’s case via PBS. These jobs use a non-interactive (bash) shell, which does not source ~/.bashrc and consequently does not know about conda. If jobs either directly use conda, or depend on tools available only in a conda environment, then one will get errors about missing commands that can be annoying to debug as they won’t occur in any interactive shell.
The simplest solution to this is to instruct PBS to use an interactive shell for non-interactive jobs. Specifically, one should tell PBS to use a bash login shell, by invoking bash with the -l option (NB: that’s lower case “ELL”, for login, not a numeral one). In script files, this is done using a crunchbang line like #!/bin/bash -l as the first line of the script. For interactive jobs, use the -S option to PBS, like -S '/bin/bash -l'.