Software Distributor Administration Guide HP-UX 11i v1, 11i v2, and 11i v3 (5900-2561, March 2013)

3. If your checkremove script can generate error or warning conditions based on the current
activity or configuration of the target system, then enable those conditions to ensure that the
checkremove script correctly detects them.
4. Re-run the first test by installing into an alternate root directory (swinstall -r) instead of
the primary root directory (“/”). Make sure that the scripts perform all of their operations (if
any) within the alternate root directory. (This verifies the correct use of
${SW_ROOT_DIRECTORY} by your scripts.)
5. If your product is locatable (that is, it can be installed into a different location), then re-run the
tests by installing the product into a different location. When removing the product, make sure
that the removal scripts perform all of their operations in the new location, and not the default
location. (This verifies the correct use of $SW_LOCATION by your scripts.)
6. If you have a complex script, run additional tests for your product that you feel will give you
confidence your product has been installed correctly on the system. For example, only install
certain subsets of your product instead of the full product, then perform the remove operations.
(Or only remove subsets of the fully installed product.)
11.10 Requesting User Responses (swask)
SD-UX packaged applications can use interactive control scripts to query a user and obtain
installation or configuration information that cannot be known at package time. For example,
different hardware or OS versions may require different configuration, or some software may need
a specific IP address or hostname for configuration.
SD-UX runs the interactive control scripts by the swask command or by the ask default option for
the swinstall and swconfig commands. (SD-UX does not query the user but the control script
does.)
11.10.1 Using swask
• The swask command runs interactive software request scripts for the software objects selected.
• These scripts store the responses in a response file (named response) for later use by the
swinstall or swconfig commands. (swinstall and swconfig can also run the
interactive request scripts directly, using the ask option.)
• A response file is generated for each piece of selected software that has a corresponding
request script.
• swask uses the command-line only; there is no Graphical User Interface.
Syntax
swask[-v] [-c catalog] [-C session_file] [-f software_file]
[-s source][-S session_file][-x option=value][-X option_file]
[software_selections][@target_selections]
Options and Operands
-v Turns on verbose output to stdout and displays all activity to the
screen.
-c catalog Specifies the pathname of an exported catalog which stores the
response files created by the request script. The swask command
creates the catalog if it does not already exist.
If the -c catalog option is omitted and the source is local, swask
copies the response files into the source depot:
distribution.path/catalog.
11.10 Requesting User Responses (swask) 227