The request script

The request script solicits interaction during installation and is the only place where your package can interact directly with the installer. It can be used, for example, to ask the installer if optional pieces of a package should be installed.

The output of a request script must be a list of parameters and their values. This list can include any of the parameters you created in the pkginfo(4) file (not including the 21 standard parameters) and the CLASSES parameter. The list can also introduce parameters that have not been defined elsewhere.

When your request script assigns values to a parameter, it must then make those values available to the installation environment for use by pkgadd(1M) and also by other packaging scripts. The following example shows a request script segment that performs this task for the four parameters CLASSES, NCMPBIN, EMACS, and NCMPMAN:

   # make parameters available to installation service
   # and any other packaging script we might have
   cat >$1 <<!
   CLASSES='$CLASSES'
   NCMPBIN='$NCMPBIN'
   EMACS='$EMACS'
   NCMPMAN='$NCMPMAN'
   !

Request script naming conventions

There can only be one request script per package and it must be named request.

Request script usage rules

• The request script is executed as uid=root and gid=other.

• The request script should not modify any files, with the exception of the ``response'' file (described below) which is the output of the request script. It is intended only to interact with users and to create a list of parameter assignments based upon that interaction.

• pkgadd(1M) calls the request script with one argument that names the file to which the output of this script will be written. This file is referred to as the response file.

• The parameter assignments should be added to the installation environment for use by pkgadd(1M) and other packaging scripts (as shown in the previous example.

• System parameters and standard installation parameters, except for the CLASSES parameter, cannot be modified by a request script. Any of the other parameters available can be changed.

• The format of the output list should be PARAMETER="value". For example:
  
  CLASSES="none class1"

• The list should be written to the file named as the argument to the request script.

• The user's terminal is defined as standard input to the request script.

• The request script is not executed during package removal. However, the parameter values assigned in the script are saved and are available during removal.

Soliciting user input in request scripts

A tool is provided in the base package for generating full-screen menus for handling user input. This tool is called menu, and should be used when user input is solicited in a request script. Using a form description file (see menu(4)), menu generates a full-screen form that can be used for displaying information, entering a selection from a numbered list, or filling out a more complex, multiple-field form. The menu tool can also contain help text so that a user can get more information about the current step in the installation.

The menu tool output is a file that contains Bourne/Korn shell statements of the form:

VARIABLE="value"

After the user completes the menu, this output file can be read in and executed in the request script using the shell '.' command. The values obtained can be used to generate the response file, the output of the request script.

The menu tool should be used when soliciting user input from the request script. The menu tool can also be used in the postinstall script for a package to inform the user about the status of the installation at completion. (See the manual pages for menu(1) and menu(4) for more information.)