A key concept to how shells function is that they use system-defined variables (called environmental variables). These standardized variables refer to commonly used things such as your user name and your home area, but can also be used in ways that help the computer accomplish the tasks you tell it. Many of the nuts-and-bolts that the computer uses in order for you to use the system are handled with such environmental variables, even if you as a user are totally unaware that they exist. The Modules system works in part by creating new variables and modifying existing ones. In addition, users often find it helpful to create their own user-specific variables. A table containing some useful variables (starting with system-defined variables and ending with a few set by the cryoem Modules environment) can be found here.
Values for the environmental variables are accessed using a "$" followed by the variable name, and so (for example), there is a HOME variable that refers to a user's home directory but your specific home directory is specified using ${HOME} (or $HOME, if you chose to leave out the delimiting {}'s). The easiest way to see the value for any variable is to use the echo command and on Karst, echo $HOME will produce the full name of your home directory (/N/u/yourUserName/Karst). Keep in mind that linux is case sensitive and that ${HOME} will likely mean something completely different from ${home}!
Another way to think about these environmental variables is as a type of shorthand that the computer uses. For example, all the software for the cryoem module on Karst is located in the directories below /N/soft/rhel6/cryoem, and the Modules system sets the variable CRYO_PREFIX to this location. If you wanted to see what was there, you could type ls $CRYO_PREFIX instead of ls /N/soft/rhel6/cryoem.
A major advantage to using such a variable is that all the user needs to know is the name of the variable (and not the variable's value). Imagine that for some reason, all the software for the cryoem module was moved to a different location. Such a change would cause every reference to software in directories below /N/soft/rhel6/cryoem to fail (i.e., a script such as /N/soft/rhel6/cryoem/bin/dm2mrc.sh would no longer exist, and so trying to use it with that pathname simply wouldn't work). However, since it is possible to use $CRYO_PREFIX to designate wherever the software is located, using the $CRYO_PREFIX shorthand in the pathname for dm2mrc.sh avoids all the problems of trying to access files that no longer exist (i.e., while /N/soft/rhel6/cryoem/bin/dm2mrc.sh may or may not exist, $CRYO_PREFIX/bin/dm2mrc.sh will exist as long as the cryoem module is well maintained). This ability to redefine the value of existing variables is one important reason that the Modules system is such a powerful way to manipulate a user's working environment.
One of the most important variables is called PATH. PATH specifies the set of places you the user know about that contain files for system-wide linux commands, executable programs and shell scripts. If, for example, a shell script is in a place that is on your PATH, you can run the script simply by typing its name. When you do this, the shell searches your PATH to find a match to the name you typed, and runs the first match that it finds. When no match can be found, the shell tells you that and does nothing. In most cases (but not all), you can run a command, program or script that cannot be found on your PATH by typing the absolute name (i.e., the full path to that file, starting at /). Since it is much easier to type just the names, your PATH should include all the places where useful things reside. The Modules system works to a large extent by adding and subtracting places from your PATH.
Another extremely important variable similar to PATH is LD_LIBRARY_PATH. This variable specifies the places you know about that contain the shared libraries that are needed when certain programs run. Many of the programs you will use on a linux machine use dynamically linked libraries, meaning that at least some of the functions and subroutines needed by the program are not included in the program itself but are located in other places that must be found when the program is executed. There are system-wide locations for such shared libraries and also executable-specific (or module- or user-specific) repositories for them. If you attempt to run an executable that requires a shared library that cannot be found on your LD_LIBRARY_PATH, the executable will generate an error indicating the name of the shared library it can not find and stop before doing anything else.
The number of environmental variables and their use is essentially unlimited, and all you really need to know about them is that they exist and are an extremely powerful way to keep things organized both for the computer system itself and for the people responsible for maintaining it. However, if you start to write you own shell scripts, you will find it useful to define your own variables.
Read about the fundamentals of scripting in Linux