2 Packages

 2.1 General
 2.2 Package Help Libraries
 2.3 Shell Package Startup Scripts
 2.4 ICL Package Definition Files

2.1 General

The term ‘package’ in this document may be taken to mean a related group of ADAM applications. Packages are described as standard if they are installed at every Starlink site or option if the are only installed when requested by users. Allowance is also made for local packages which are non-Starlink packages set up for general use at particular sites. It is assumed that packages may be run directly from the shell or from ICL; where this is not the case, the inappropriate files are omitted from the installation.

In most cases applications in the package will all be linked into a single monolith (see SUN/144) for efficient running from ICL and to save disk space. Packages could however be defined to consist of any mixture of task types and procedures – they could, in fact, include elements from other packages. Because a package may well consist of applications written by a number of different authors, the term Package Administrator is used for the person with overall responsibility for the package.

Executable files, shell scripts, ICL command files and compiled interface files associated with a package will usually be installed in a directory referred to by environment variable package_DIR. For most applications packages this directory is /star/bin/package. If the package can be run direct from the shell, package_DIR should also contain links with the name of each application in a monolith pointing to that monolith.

e.g.  % ln $KAPPA_DIR/kappa_pm $KAPPA_DIR/add

Individual interface files will also be required in addition to the monolithic interface file in this case.

2.2 Package Help Libraries

Each package should provide a Package Help Library. This is a Starlink HELP library (see SUN/124). The structure of the HELP library is at the Package Administrator’s discretion but at the very least it should contain an overall description of the package with subtopics for each application.

The usual format is described below:

Level 0
A general description of the package.
Level 1
A description of individual applications and other general topics such as ‘Getting Started’.
Level 2
As required. Each application will normally have a subtopic ‘parameters’ which has subtopics describing each parameter. These parameter subtopics may be referred to in parameter help specifications in task interface files (see SUN/115).

Package Help Libraries will usually be installed in directory /star/help/package and named package.shl. Environment variable package_HELP should be defined to point to the Package Help Library and this used in the relevant commands.

2.3 Shell Package Startup Scripts

Generally, to start up a package for use direct from the shell, the user will type:

% package

The Starlink login procedures will have defined command, package, which, when issued by the user, will cause commands in the Package Startup Script to be obeyed.

The Package Startup Script will define commands for running the individual applications and for obtaining help. It should also issue a ‘Welcome’ message stating the package name and version. Typically it will contain mainly alias commands of the form:

% alias application $package_DIR/application


% alias add $KAPPA_DIR/add

(Note that here $KAPPA_DIR/add is a link to the KAPPA monolith as described in Section 2.1).

The Package Startup Script should be provided by the Package Administrator and be installed in package_DIR.

2.4 ICL Package Definition Files

Generally, to start up a package under ICL, the user will type:

ICL> package

This will cause ICL commands in the Package Definition Command File to be obeyed. All but the simplest packages will contain a Package Definition Command File which is a file containing ICL commands to:

Define the commands which the user will use to run the package.
Specify the source(s) of help information for the package.
Display information about the package.

For example, the Package Definition Command File for KAPPA on Unix could be something like:

  { KAPPA - Package Definition Command File}
  { Re-define the top-level help topic
  { Define the individual commands
  ... etc...
  PRINT  " --    Initialised for KAPPA    --"
  PRINT  " -- Version 0.8-SU, 1993 January --"

The Package Definition Command File is controlled by the Package Administrator and should be installed in package_DIR.

For very simple packages, a Package Definition Command File may not be appropriate – the commands required to run such a package may be set up directly by the overall system startup procedures.