6 The ‘Full’ IFD File

The basic keywords in an IFD have already been described but in order to produce complete versions of the required environment files automatically, additional syntax and keywords are available. This section outlines what is available; see elsewhere (Section 7) for complete descriptions of all the keywords.

6.1 IFD Initial Keywords

The following are examples of the additional keywords which may appear within the package description (i.e. after package name {). They are all optional and will be ignored for environments for which they are not relevant.

6.2 Additional Action Keywords

The following are examples of the additional keywords which may appear within the action description (i.e. after action name {). They are all optional and will be ignored for environments for which they are not relevant.

6.3 Parameter Definition Keywords

6.3.1 General

Within the parameter description (i.e. after parameter name {), The following keywords may appear (example arguments are given):

They are all optional and will be ignored for environments for which they are not relevant. There is an obvious correspondence between most of these keywords and the parameter definition fields of an ADAM interface file as described in SUN/115 which should be consulted for the finer details of permitted values but remember that lists, such the ppath value, are space-separated in the IFD but comma-separated in the Interface File, and character constants only need to be quoted in the IFD (with {}) if they contain spaces or $.

The keywords which do not have a corresponding ADAM Interface File field are dynamic, outputpar, repeated and size (see the following sections).

6.3.2 The dynamic keyword

This keyword forces the parameter to be classed as ‘dynamic’ or ‘non-dynamic’ regardless of the normal default.

A dynamic parameter is one whose value cannot easily be set as a static default or calculated by the user at runtime. The Starlink Software Environment allows such values to be set by means of VPATH GLOBAL or VPATH DYNAMIC but this is not available for other environments so they must be handled as special cases. In the case of IRAF, for instance, dynamic parameters are handled by forcing the ADAM task to issue a parameter request message with a suggested value. This message is intercepted by the IRAF/Starlink adaptor process which returns the suggested value without asking IRAF for a value. For more information on this, see SSN/35.

In the absence of a dynamic keyword, all parameters with VPATH starting with GLOBAL are classed as dynamic and all others (including VPATH DYNAMIC) as non-dynamic.

So that users are warned, particularly when using IRAF epar, that changing the parameter is likely to have an unexpected effect, the prompt string has *! prepended to it.

6.3.3 The outputpar keyword

For non-primitive parameter types, there is a potential confusion between the access required to the parameter and the access required to the file or device whose name is given by the parameter. ADAM requires to be told the access to the file or device and IRAF (more accurately the IRAF/Starlink inter-operability system) needs to know if the value of the parameter itself is output and thus that the IRAF parameter must be updated after the application has run. The list of parameters which must be updated is read from the Output Parameter File created by ifd2iraf.

The system will assume that primitive types need updating if the access mode (as defined by the access keyword) is ‘WRITE’ or ‘UPDATE’ and that other types are not output. For this reason, the outputpar keyword is provided to force a non-primitive parameter to be output if necessary.

6.3.4 The repeated keyword

This keyword is used to indicate that new values for the parameter may required repeatedly during one invocation of the program. This will usually mean that the user must be prompted each time. In IRAF the recommended default ‘automatic’ mode allows prompting to be overridden and the same value supplied each time a value is requested so ‘query’ mode must be set for ‘repeated’ parameters.

6.3.5 The size keyword

ADAM does not require to know the size of a parameter, or even whether it is a scalar, vector or array. However, this information is required for some parameter systems so the size keyword is provided in the IFD format.

The IRAF/Starlink inter-operability system only needs to know that the parameter is non-scalar so currently the argument is ignored and may be given as *.

6.4 The command Keywords

A keyword command is provided to define commands for the command language in use (ICL, CL etc.) which will do various generic things as follows:

• Define a command which will display a message to the user.
      command task1 {
        print {task1 has been renamed to task2}
      }
• Define a command which will obey a command in the underlying shell.
      command cleanup {
        obey {rm *.tmp}
      }
• Define a command to run an action with set parameters
      command fitsexist {
        task fitsmod { taskinherit ndf
                       taskinherit keyword
                       taskparam edit=exist
                       taskparam mode=interface
                 }
      }

  The taskinherit subcommand gives the names of parameters of the command whose values will be inherited by the action named in the task subcommand. The taskparam subcommand gives the name and fixed value of the other parameters to be passed to the action. The code above will result in command fitsexist being defined with two parameters, ndf and keyword so that obeying

    fitsexist comwest simple

  is equivalent to obeying fitsmod with: parameter ndf set to comwest; parameter keyword set to simple; parameter edit set to exist and parameter mode set to interface.

  Note that in Starlink mode, the csh, sh and ICL user-interfaces will just append anything following the fitsexist command to the fitsmod command, following the fixed parameters. The taskinherit keyword has no effect.

• Define an obsolete command – if it is obeyed, the message is displayed.
      command oldcommand {
        obsolete {Command oldcommand is obsolete - use newcommand}
      }

Note that in addition to the subcommand print, obeyetc. the command definition may contain alias specifications.

6.5 File-specific Output

Sometimes output is required only for one particular file. The following keywords allow lines to be put, verbatim, into the appropriate file. They are ignored if that file is not being produced.

For example: