swask(8)swask(8)NAMEswask - ask for user response
SYNOPSISswask [-v] [-c catalog] [-C session_file] [-f software_file] [-s
source] [-S session_file] [-t target_file] [-x option=value] [-X
options_file] [software_selections] [ target_selections]
STANDARDS
Interfaces documented on this reference page conform to industry stan‐
dards as follows:
POSIX 1387.2, XDSA
Refer to the standards(5) reference page for more information about
industry standards and associated tags.
DESCRIPTION
The swask command runs interactive software scripts for the software
objects selected to one or more targets specified by These scripts
store the responses in a file (named response) for later use by the
swinstall and swconfig commands. The swinstall and swconfig commands
can also run the interactive request scripts directly, using the ask
option.
If the -s option is specified, software is selected from the distribu‐
tion source. If the -s option is not specified, software installed on
the target systems is selected. For each selected software that has a
request script, executing that script generates a response file. By
specifying the -c catalog option, swask stores a copy of the response
file to that catalog for later use by swinstall or swconfig
Options
The swask command supports the following options:
-v Turns on verbose output to stdout.
-c catalog Specifies the pathname of an exported catalog
which stores the response files created by the
request script. swask 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, catalog.
-C session_file
Saves the current options and operands to ses‐
sion_file. You can enter a relative or absolute
path with the file name. The default directory
for session files is $HOME/.sw/sessions/ You can
recall a session file with the -S option.
-f software_file
Reads the list of software_selections from soft‐
ware_file instead of (or in addition to) the com‐
mand line.
-s source Specifies the source depot (or tape) from which
software is selected for the ask operation.
(SWMGR can read both tar and cpio tape depots.)
-S session_file
Executes swask based on the options and operands
saved from a previous session, as defined in ses‐
sion_file. You can save session information from
a command-line session with the -C session_file
option.
-t targetfile Specifies a default set of targets for swask.
-x option=value
Sets the session option to value and overrides
the default value (or a value in an alternate
option_file specified with the -X option). Multi‐
ple -x options can be specified.
-X option_file Reads the session options and behaviors from
option_file.
Operands
swask supports two types of operands: followed by These operands are
separated by the "@" (at) character. This syntax implies that the com‐
mand operates on "software selections at targets".
Software Selections
The selections operands consist of
swask supports the following syntax for each software_selection:
bundle[.product[.subproduct][.fileset]][,version]
product[.subproduct][.fileset][,version]
· The = (equals) relational operator lets you specify
selections with the following shell wildcard and pattern-
matching notations:
[ ] * ?
· Bundles and subproducts are recursive. Bundles can con‐
tain other bundles and subproducts can contain other sub‐
products.
· The * software specification selects all products. Use
this specification with caution.
The version component has the form:
[,r <op> revision][,a <op> arch][,v <op> vendor]
[,c <op> category][,q=qualifier][,l=location]
[,fr <op> revision][,fa <op> arch]
· location applies only to installed software and
refers to software installed to a location other
than the default product directory.
· fr and fa apply only to filesets.
· The <op> (relational operator) component can be of
the form:
== >= <= < > or !=
which performs individual comparisons on dot-sepa‐
rated fields. For example, r>=B.10.00 chooses all
revisions greater than or equal to B.10.00 The
system compares each dot-separated field to find
matches.
· The = (equals) relational operator lets you spec‐
ify selections with the shell wildcard and pat‐
tern-matching notations:
[ ] * ? !
For example, the expression r=1[01].* returns any
revision in version 10 or version 11.
· All version components are repeatable within a
single specification (e.g. r>=AA.12 r<AA.20 If
multiple components are used, the selection must
match all components.
· Fully qualified software specs include the r= a=
and v= version components even if they contain
empty strings. For installed software, l= is also
included.
· No space or tab characters are allowed in a soft‐
ware selection.
· The software can take the place of the version
component. It has the form:
[instance_id]
within the context of an exported catalog, where
is an integer that distinguishes versions of prod‐
ucts and bundles with the same tag.
Target Selections
swask supports the following syntax for each target_selection.
[host][:][/directory]
The : (colon) is required if both a host and directory are specified.
EXTERNAL INFLUENCES
Default Options
In addition to the standard options, several SWMGR behaviors and policy
options can be changed by editing the default values found in:
/var/adm/sw/defaults the system-wide default values.
$HOME/.swdefaults the user-specific default values.
Values must be specified in the defaults file using this syntax:
[command_name.]option=value
The optional prefix denotes one of the SWMGR commands. Using the prefix
limits the change in the default value to that command. If you leave
the prefix off, the change applies to all commands.
You can also override default values from the command line with the -x
or -X options:
The following section lists all of the keywords supported by the swask
commands. If a default value exists, it is listed after the "=".
ask=true Executes the request script, if one is associated with
the selected software, and stores the user response in
a file named response
If ask=as_needed the swask command first determines if
a response file already exists in the catalog and exe‐
cutes the request script only when a response file is
absent.
autoselect_dependencies=true
Controls the automatic selection of prerequisite and
corequisite software that is not explicitly selected
by the user. When set to true requisite software will
be automatically selected for configuration. When set
to false requisite software which is not explicitly
selected will not be automatically selected for con‐
figuration.
autoselect_patches=true
Automatically selects the latest patches (based on
superseding and ancestor attributes) for a software
object that a user selects. The patch_filter option
can be used in conjunction with autoselect_patches to
limit which patches will be selected. Requires patches
that are in an enhanced SWMGR format. Patches not in
enhanced format will not respond to autoselect_patches
enforce_scripts=true
Controls the handling of errors generated by scripts.
If true, swask stops and an error message appears. The
message gives the script location and says execution
cannot proceed until the problem is fixed. If false,
all script errors are treated as warnings, and swask
attempts to continue operation. A message appears giv‐
ing the script location and saying that execution will
proceed.
installed_software_catalog=products
Defines the directory path where the Installed Prod‐
ucts Database (IPD) is stored. When set to an absolute
path, this option defines the location of the IPD.
When this option contains a relative path, the SWMGR
controller appends the value to /var/adm/sw to deter‐
mine the path to the IPD. For alternate roots, this
path is resolved relative to the location of the
alternate root. This option does not affect where
software is installed, only the IPD location.
log_msgid=0
Controls the log level for the events logged to the
command log file, the target agent log file, and the
source agent log file by prepending identification
numbers to log file messages:
0 No such identifiers are prepended (default).
1 Applies to ERROR messages only.
2 Applies to ERROR and WARNING messages.
3 Applies to ERROR, WARNING, and NOTE messages.
4 Applies to ERROR, WARNING, NOTE, and certain other
log file messages.
logdetail=false
Controls the amount of detail written to the logfile.
When set to true this option adds detailed task infor‐
mation (such as options specified, progress state‐
ments, and additional summary information) to the log‐
file. This information is in addition to log informa‐
tion controlled by the loglevel option.
See loglevel below and the sd(5) manual page, by typ‐
ing man 5 sd for more information.
logfile=/var/adm/sw/swask.log
Defines the default log file for swask.
loglevel=1
Controls the log level for the events logged to the
command logfile and the target agent logfile. A value
of
0 provides no information to the logfile.
1 enables verbose logging of key events to the log
files.
2 enables very verbose logging, including per-file
messages, to the log files.
patch_filter=*.*
Used in conjunction with the autoselect_patches or
patch_match_target criteria specified by the filter. A
key use is to allow filtering by the "category"
attribute. Requires patches that are in an enhanced
SWMGR patch format.
verbose=1 Controls the verbosity of the output (stdout):
0 disables output to stdout. (Error and warning
messages are always written to stderr).
1 enables verbose messaging to stdout.
Session Files
Each invocation of swask defines a task session. The invocation
options, source information, software selections, and target hosts are
saved before the task actually commences. This lets you re-execute the
command even if the session ends before proper completion.
Each session is saved to the file $HOME/.sw/sessions/swask.last This
file is overwritten by each invocation of swask
To save session information in a different location, execute swask with
the -C session__file option.
A session file uses the same syntax as the defaults files. You can
specify an absolute path for a session file. If you do not specify a
directory, the default location for a session file is $HOME/.sw/ses‐
sions/
To re-execute a session, specify the session file as the argument for
the -S session__file option.
When you re-execute a session file, the values in the session file take
precedence over values in the system defaults file. Likewise, any com‐
mand line options or parameters that you specify when you invoke swask
take precedence over the values in the session file.
Software and Target Lists
You can use files containing software and target selections as input to
the swask command. See the -f and -t options for more information.
Environment Variables
The environment variable that affects the swask command is:
LANG Determines the language in which messages are dis‐
played. If LANG is not specified or is set to the
empty string, a default value of C is used. See
lang(5) for more information.
NOTE: The language in which the SWMGR agent and daemon
log messages are displayed is set by the system con‐
figuration variable script, /etc/rc.config.d/LANG For
example, /etc/rc.config.d/LANG must be set to
LANG=ja_JP.SJIS or LANG=ja_JP.eucJP to make the agent
and daemon log messages display in Japanese.
LC_ALL Determines the locale to be used to override any val‐
ues for locale categories specified by the settings of
LANG or any environment variables beginning with LC_
LC_CTYPE Determines the interpretation of sequences of bytes of
text data as characters (e.g., single-versus multibyte
characters in values for vendor-defined attributes).
LC_MESSAGES
Determines the language in which messages should be
written.
LC_TIME Determines the format of dates (create_date and
mod_date) when displayed by swlist Used by all utili‐
ties when displaying dates and times in stdout logging
TZ Determines the time zone for use when displaying dates
and times.
Environment variables that affect scripts:
SW_CATALOG
Holds the path to the Installed Products Database
(IPD), relative to the path in the SW_ROOT_DIRECTORY
environment variable. Note that you can specify a path
for the IPD using the installed_software_catalog
default option.
SW_CONTROL_DIRECTORY
Defines the current directory of the script being exe‐
cuted, either a temporary catalog directory, or a
directory within in the Installed Products Database
(IPD). This variable tells scripts where other con‐
trol scripts for the software are located (e.g. sub‐
scripts).
SW_CONTROL_TAG
Holds the tag name of the control_file being executed.
When packaging software, you can define a physical
name and path for a control file in a depot. This lets
you define the control_file with a name other than its
tag and lets you use multiple control file definitions
to point to the same file. A control_file can query
the SW_CONTROL_TAG variable to determine which tag is
being executed.
SW_LOCATION
Defines the location of the product, which may have
been changed from the default product directory. When
combined with the SW_ROOT_DIRECTORY this variable
tells scripts where the product files are located.
SW_PATH A PATH variable which defines a minimum set of com‐
mands available for use in a control script (e.g.
/sbin:/usr/bin
SW_ROOT_DIRECTORY
Defines the root directory in which the session is
operating, either "/" or an alternate root directory.
This variable tells control scripts the root directory
in which the products are installed. A script must
use this directory as a prefix to SW_LOCATION to
locate the product's installed files. The configure
script is only run when SW_ROOT_DIRECTORY is "/".
SW_SESSION_OPTIONS
Contains the pathname of a file containing the value
of every option for a particular command, including
software and target selections. This lets scripts
retrieve any command options and values other than the
ones provided explicitly by other environment vari‐
ables. For example, when the file pointed to by
SW_SESSIONS_OPTIONS is made available to a request
script, the targets option contains a list of soft‐
ware_collection_specs for all targets specified for
the command. When the file pointed to by SW_SES‐
SIONS_OPTIONS is made available to other scripts, the
targets option contains the single software_collec‐
tion_spec for the targets on which the script is being
executed.
SW_SOFTWARE_SPEC
This variable contains the fully qualified software
specification of the current product or fileset. The
software specification allows the product or fileset
to be uniquely identified.
RETURN VALUESswask returns one of these codes:
0 Command successful on all targets
1 Command failed on all targets
2 Command failed on some targets
DIAGNOSTICS
The swask command writes to stdout, stderr, and to the swask logfile.
Standard Output
An interactive swask session does not write to stdout. A non-interac‐
tive swask session writes messages for significant events. These
include:
· a begin and end session message,
· selection, analysis, and execution task messages for each tar‐
get_selection.
Standard Error
An interactive swask session does not write to stderr. A non-interac‐
tive swask session writes messages for all WARNING and ERROR conditions
to stderr.
Logging
Both interactive and non-interactive swask sessions log summary events
at the host where the command was invoked. They log detailed events to
the swask.log logfile associated with each target_selection.
Command Log
The swask command logs all stdout and stderr messages to the the
logfile /var/adm/sw/swask.log Similar messages are logged by an
interactive swask session. You can specify a different logfile
by modifying the logfile option.
EXAMPLES
Run all request scripts from the default depot (/var/spool/sw) depot
and write the response file (named response) back to the same depot:
swask-s /var/spool/sw \*
Run the request script for Product1 from depot /tmp/sample.depot.1 on
remote host swposix create the catalog /tmp/test1.depot on the local
controller machine, and place the response file (named response) in the
catalog:
swask-s swposix:/tmp/sample.depot.1 -c /tmp/test1.depot Product1
Run request scripts from remote depot /tmp/sample.depot.1 on host
swposix only when a response file is absent, create the catalog
/tmp/test1.depot on the local controller machine, and place the
response file (named response) in the catalog:
swask-s swposix:/tmp/sample.depot.1 -c /tmp/test1.depot
-x ask=as_needed \*
FILES
$HOME/.swdefaults
Contains the user-specific default values for some or all SWMGR
options. If this file does not exist, SWMGR looks for user-spe‐
cific defaults in $HOME/.sw/defaults.
$HOME/.sw/sessions/
Contains session files automatically saved by the SWMGR com‐
mands or explicitly saved by the user.
/usr/lib/sw/sys.defaults
Contains the master list of current SWMGR options, with their
default values, for documentation purposes only.
/var/adm/sw/
The directory which contains all of the configurable (and non-
configurable) data for SWMGR. This directory is also the
default location of log files.
/var/adm/sw/defaults
Contains the active system-wide default values for some or all
SWMGR options.
/var/adm/sw/products/
The Installed Products Database (IPD), a catalog of all prod‐
ucts installed on a system.
/var/adm/sw/swask.log
Contains all stdout and stderr messages generated by swaskSEE ALSOsd(5), swconfig(8), swinstall(8), and the Managing Tru64 UNIX Software
With the SysMan Software Manager reference manual.
Compaq Computer Corporation swask(8)
