Alas, any such script must be cognizant of the detailed structure of the user's environment - a matter of local operating policy. In particular, sowhat must be able to reconstruct any environment available to a user in order to test for problems within each one.
At Tufts EECS, we utilize a simple derivative of software module management [4,5,6] to allow users to dynamically add modules to their environment, modifying both their PATH and LD_LIBRARY_PATH as needed. Users need only type the shell command:
use packname(where packname is the name of the package) in order to modify their environments for a specific package. We use this mechanism to allow users access to a variety of software that is not accessible except by specific request, such as vendor software for computer-aided design.
The `use' command above invokes a package-specific startup script to
modify the user's environment appropriately so that the desired
package will work properly. For example, use new executes
/local/env/new.cshrc:
set path = ($path[1-3] \
/local/new/bin $path[4-])
setenv MANPATH \
/local/new/man:${MANPATH}
setenv LD_LIBRARY_PATH \
/local/new/lib:${LD_LIBRARY_PATH}
which has the effect of including the beta software testing tree
/local/new in the user's PATH, MANPATH, and
LD_LIBRARY_PATH.
The way the use command works is quite straightforward. The tcsh alias:
alias use \ 'set packages = ( \!* ) ; \ source /local/lib/use'sources the script
/local/lib/use with $packages set to the
appropriate package name:
#! /usr/bin/tcsh
if ($?packages) then
foreach pkg ($packages)
if (-f /local/env/$pkg.cshrc) then
echo Using package $pkg : \
setting up your environment
source /local/env/$pkg.cshrc
else
echo There is no package $pkg : \
please check your spelling.
endif
end
endif
unset packages
This script in turn sources a setup script from /local/env
(starting with the package name) that sets PATH and
LD_LIBRARY_PATH appropriately for the new module.