Applications Setup

Initial Setting Up

Add to your .cshrc (note the upper-case S):

source /Local/bin/Setup.csh

Then restart the shell (terminal or xterm, to taste), or start another one. This will add an alias called Activate to your running shell, which can then be used to invoke initialisation shims (which live in /Local/bin/init) on an as-needed basis, as shown below. Remember:

• The additional line in your .cshrc is done once for all time.
• Each Activate command is used once per shell.

If you use bash instead of tcsh, you should instead add to your .bashrc:

. /Local/bin/Setup.bash

(including the initial dot, which is how Bourne shells pronounce "source"). This will have exactly similar results to the tcsh version, except (for us pedants) that Activate is a shell function, rather than an alias which sources an external script to do its dirty work. You will also need to ensure that your .bash_profile (or .profile) contains something along the following lines:

if [ -r $HOME/.bashrc ] ; then
  . $HOME/.bashrc
fi

(don't forget the dot in the middle line). This makes sure that the contents of .bashrc are acted upon when bash is invoked as a "login shell".

Test the Setup mechanism:

Activate foo

This says "foo" at the prompt; adds a shell variable called "foo", and an environment variable called "bar", to your running shell; and tells you what it's done. Check the results for yourself with

set | grep -i foo
printenv | grep -i foo

This test and demo may mutate, but probably won't disappear altogether.

Usage

To Activate (eg) the Starlink collection, say at your command prompt:

Activate starlink

This will set up your ${PATH}, alter certain environment variables (often ${DYLD_LIBRARY_PATH} and co-conspirators), and/or add certain aliases, in order to make the Activated suite or program available to you in your current shell. De-Activating a program or suite is as simple as starting up a new shell, and working in that instead. Again, remember:

• The additional line in your .cshrc is done once for all time.
• Each Activate command is used once per shell.

If you wish to use one particular set of commands frequently, put them in a file, and "source" that file on a need-to-use basis.

Possible error messages:

• Activate: command not found

  You've forgotten to source /Local/bin/Setup.{csh,bash} by hand, or haven't restarted your shell since putting the line in the relevant startup file. (Alternatively, if you're using a laptop or other system that hasn't been connected in a while, Applications Setup may be a bit out-of-date. Please see above.)

• prog: Command not found (where you know program prog is in package package)

  You've forgotten to say "Activate package" at the prompt of your current shell. This can be most misleading when you don't know that (eg) SuperMongo is part of Scisoft (Activate search supermongo will be your friend here).

• Sorry: can't set up package

  Applications Setup doesn't know about package. Try using it anyway: there may be no need for an Activation.

• *** Sorry: package not available

  Applications Setup knows about package, but it's not installed yet. Try (re)installing it from Self-Service.

• A complaint of the form setenv: too many variables

  This suggests some pathname may have a space in it, and hasn't been quoted correctly somewhere along the line. If you've recently edited any startup files (most notoriously, .tshrc), check any aliases and environment variables you may have set therein for syntax errors of this sort.

Please note that problems of this form may not manifest themselves immediately (like a rake in the long grass, waiting to be trodden on).

TIP: when debugging this sort of thing, don't cut things out; comment them out instead. This'll save you a lot of (mis)remembering and (re)typing.

Updates and Additions:

The files which constitute the Applications Setup are distributed to all desktop systems on a weekly basis, to correct problems and to distribute functional updates. Please contact IT Support at the usual address if you need an urgent update (eg to a laptop system which has not been in contact with the Central Physics server for a while), or if you wish to suggest some new or revised Activation, or if you have spotted some inconsistency or other shortcoming in the help and search facilities.

The Help and Search Facilities

The Application Setup facility has "help" and "search" commands. Thus:

Activate help

gives a brief summary of all possible available packages to which Applications Setup applies;

Activate help idl

(for example) gives further information about IDL;

Activate help gnuplot

will find and document (on an Astro system) two different versions of GNUplot, plus a command-line wrapper script which avoids certain problems with the executables without disturbing your current shell environment; and, also for viewers in Astrophysics,

Activate help macports
Activate help scisoft
Activate help starlink

additionally list the manifests for the respective suites, including version information.

Since some of these yield copious output, piping the output of Activate help into some other program will be useful. Thus,

Activate help | less

will permit you to page through the list, and

Activate help starlink | a2ps

would send a paginated version of the Starlink helpfile and manifest to your default printer.

The Search and Help facilities have now been merged, and made more verbose; the chief difference now is whether to give a summary, or the full help info (plus manifests for suites). Thus,

Activate help gsl
Activate search gsl

will both show you that MacPorts, Scisoft and Starlink all sport instances of the GNU Scientific Library, in three different versions. (As it happens, SciSoft's instance is gsl-1.14, not 2.14 as alleged in its manifest file. Moral: measure twice, cut once.)

Searching in greater depth

Activate help foo or Activate search foo does a whole-word match a la Google (or grep -iw). If you wish to match part of a word, try something of the form:

Activate help scisoft | grep -i gsl

This will show you that Scisoft has PyGSL present, as well as GSL.

Beware of attempting to use this to seek excessively short strings:

Activate help scisoft | grep -i c

matched 38% of the known universe (at the time of writing) without finding a single C compiler. On the other hand,

Activate help scisoft | grep -i sci

will find both ScientificPython and scipy (though you might have to look harder). I understand these are different things.

Alison Crocker's script example

The following (slightly edited) script has been used in real life [Alison Crocker, semi-pri comm]; it demonstrates what should be done, and manages to mostly avoid what shouldn't (I liked it so much that I stole it, and made it the basis of many of the wrapper scripts in /Local/bin). I presume the script in question is in a file on her path, and has been rendered executable --- "man chmod" will be your friend.

I just type 'iraf' now in a terminal and it works, just tested to be sure. When I do that, the following script is called (starting ds9 is superfluous, obviously):

#!/bin/tcsh
source /Local/bin/Setup.csh
Activate iraf
cd ${HOME}/iraf/
ds9 &
xgterm -fn 9x15 -sb -e ecl &
exit 0

Hope that helps!
Ali

Another example: using an alias

Here's an example of how to use an alias to do an Activation and launch an application in one go, all in the current shell. This is tcsh-specific; translation to bash is left as an exercise (extra marks for putting it all in a self-destroying shell function).

WARNING: This trick will fail dramatically if the Activation causes an alias to be defined, rather than putting the executable in question on your $PATH. Known offenders include IDL (as of at least version 8.1), and much of the Starlink software.

The application in this example is SuperMongo, which is part of the Scisoft suite (available in all good Astrophysics installations). Normally, one would do

Activate scisoft
sm

to invoke it. To save having to remember to do the first step, create a file called ".sm_launch.csh" in your home directory, with the following contents:

source /Local/bin/Setup.csh # .... if not
                # already in your .cshrc
Activate scisoft # Do relevant Hack
unalias sm # Cut out the middleman (see below)
\sm "$*" # Pass on command-line args
                # to SuperMongo

Then put the following line in your .cshrc:

alias sm 'source $HOME/.sm_launch.csh '

Now watch it in action:

• User says "sm" at the command line.
• The alias sources the setup file into the current shell, in case User's forgotten to put that in .cshrc as well.
• The Activation is performed in the current shell. In particular, the SuperMongo program is put on the $PATH.
• The script blows the alias away in the current shell, but itself continues to execute.
• The SuperMongo program itself is invoked.
• User exits from SuperMongo in due course, at which point the script also exits.
• Somewhat later, User says "sm" again at the command line in the same shell.
• The alias is no longer in place, but SuperMongo program is now on the $PATH in that shell, so the system directly invokes the SuperMongo executable.

The "unalias" line is doubly important:

• The Activation need only be done once for your current shell. Re-Activating the same Hack would needlessly extend your path.
• There's the danger that the last line would recursively activate the same alias, with hilarious consequences. Adding the leading backslash should also prevent this, but I'm a believer in belt-and-braces.