Provided by: gnats_4.1.0-0.7_i386 bug

NAME

       gnatsd - GNATS network server

SYNOPSIS

       gnatsd [--database database | -d database] [--not-inetd | -n] [--max-
              access-level level | -m level] [--version | -V] [--help | -h]

DESCRIPTION

       gnatsd is used to service remote GNATS requests such as  querying  PRs,
       PR creation, deletion, and editing, and miscellaneous database queries.
       It uses a simple ASCII-based command protocol (similar to SMTP or POP3)
       for communicating with remote clients.

       It   also   provides   a   security  model  based  either  on  IP-based
       authentication  (generally  a  terrible  idea)  or  username/passwords.
       Passwords  may  be  encrypted  using UNIX crypt() or MD5 (for operating
       systems that support it).  Plaintext passwords are also  supported  but
       strongly discouraged.

       All  of  the  GNATS  clients are capable of communicating via the GNATS
       remote protocol to perform their functions.

       gnatsd should be run by the GNATS user (by default gnats),  and  it  is
       usually started from inetd(8).

OPTIONS

       -V, --version
            Prints the program version to stdout and exits.

       -h, --help
            Prints a short help text to stdout and exits.

       -d, --database
            Specifies  the  default  database  which is to be serviced by this
            invocation of gnatsd.  (The selected database may be  changed  via
            the CHDB command; this is simply the default if no CHDB command is
            issued.)  If no database is specified, the database named  default
            is  assumed.   This option overrides the database specified in the
            GNATSDB environment variable.

       --not-inetd, -n
            As its name suggests, indicates that gnatsd is not  being  invoked
            from  inetd.  This can be used when testing gnatsd, or if it being
            run via ssh or some other mechanism.

            This has the effect of using the local hostname  where  gnatsd  is
            being  invoked for authentication purposes, rather than the remote
            address of the connecting client.

       --max-access-level, -m
            Specifies the maximum access level that the connecting client  can
            authenticate  to.  Authentication  is as normal but if the user or
            host authenticates at a higher level, access level is set to  this
            level.

COMMAND PROTOCOL

       Commands  are  issued  to  gnatsd  as  one  or more words followed by a
       carriage-return/linefeed  pair.   For   example,   the   CHDB   (change
       databases) command is sent as
              CHDB database<CR><LF>
       [the CRLF will not be explicitly written for future examples]

       Replies  from  gnatsd  are  returned  as  one  or  more  response lines
       containing a 3-digit numeric code followed by a human-readable  string;
       the line is terminated with a <CR><LF> pair.  For example, one possible
       response to the CHDB command above would be:
              210 Now accessing GNATS database ’database’.

       The three-digit code is normally  followed  by  a  single  ASCII  space
       (character  0x20).   However,  if  additional  response lines are to be
       returned from the server, there will be a single dash (‘-’) instead  of
       the space character after the three-digit code.

       Response code values are divided into ranges.  The first digit reflects
       the general type of response (such as "successful" or "error"), and the
       subsequent digits identify the specific type of response.

       Codes 200-299
              Positive  response  indicating  that the command was successful.
              No subsequent data will be transmitted with the  response.   [In
              particular,  code  210  (CODE_OK) is used as the positive result
              code for most simple commands.]

              Commands that expect additional data from the  client  (such  as
              SUBM  or  VFLD)  use  a two-step mechanism for sending the data.
              The server will respond to the initial command with either a 211
              (CODE_SEND_PR)  or  212  (CODE_SEND_TEXT)  response  line, or an
              error code if an error occurred with the initial  command.   The
              client  is  then  expected  to send the remaining data using the
              same quoting mechanism as described for server responses in  the
              300-349  range.  The server will then send a final response line
              to the command.

       Codes 300-399
              Positive  response  indicating  that  the  query   request   was
              successful,  and  that  a  PR  or other data will follow.  Codes
              300-349 are used when transmitting PRs, and 350-399 are used for
              other responses.

              Codes  in  the  300-349  range are followed by a series of CRLF-
              terminated lines containing the command response, usually a  PR.
              The  final  line of the result is a single period (‘.’).  Result
              lines that begin with a period have an extra period prepended to
              them.

              Codes  in  the  350-399 range use a different scheme for sending
              their responses.  The three-digit numeric code will be  followed
              by  either  a  dash  (‘-’)  or  a  single space.  If the code is
              followed by a dash, that indicates that  another  response  line
              will  follow.  The final line of the response has a single space
              after the three-digit code.

              In previous versions  of  the  protocol  the  first  line  of  a
              CODE_INFORMATION  (310)  response was to be ignored.  This is no
              longer  the  case.   Instead,  any  lines   marked   with   code
              CODE_INFORMATION_FILLER  (351)  are  to be ignored.  This allows
              the server  to  transmit  additional  headers  or  other  human-
              readable text that can be safely ignored by the clients.

       Codes 400-599
              An error occurred, usually because of invalid command parameters
              or invalid input from  the  client,  missing  arguments  to  the
              comamand,  or  a command was issued out of sequence.  The human-
              readable message associated with the response line describes the
              general problem encountered with the command.

              Multiple  error messages may be returned from a command; in this
              case the ‘-’ continuation character is used on all but the  last
              response line.

       Codes 600-799
              An  internal  error  occurred  on the server, a timeout occurred
              reading data from the client, or  a  network  failure  occurred.
              These  errors  are  of  the  "this should not occur" nature, and
              retrying the operation may resolve  the  problem.   Fortunately,
              most  GNATS  transactions are idempotent; unfortunately, locking
              the database or a PR  are  not  repeatable  actions  (we  cannot
              determine   if  an  existing  lock  is  the  one  we  originally
              requested, or someone else’s).

COMMANDS

       Note that the set of GNATS commands and  their  responses  is  somewhat
       inconsistent  and  is  very much in flux.  At present the GNATS clients
       are  rather  simple-minded  and  not  very  strict   about   processing
       responses.   For  example,  if  the  server  were  to  issue a code 300
       (CODE_PR_READY) response to a CHDB command, the  client  would  happily
       expect to see a PR appear (and would print it out if one was sent).

       It  is  thus  suggested that any clients that use the GNATS protocol be
       equally flexible about the  way  received  responses  are  handled;  in
       particular, only the first digit of the response code should be assumed
       to be meaningful, although subsequent digits are needed in  some  cases
       (codes 300-399). No attempt should be made to parse the message strings
       on error response lines; they are only intended to be read  by  humans,
       and will be changed on a regular basis.

       Almost  every  command may result in the response 440 (CODE_CMD_ERROR).
       This indicates that there was a problem  with  the  command  arguments,
       usually  because of insufficient or too many arguments being specified.

       USER [<userid> [<password>]]
            Specifies the userid and password for  database  access.   Both  a
            username  and  a  password  may  be  given, only a username may be
            given, or both may be omitted; if both are  omitted,  the  current
            access level is returned.

            The possible server responses are:

            350 (CODE_INFORMATION)
                   The current access level is specified.

            422 (CODE_NO_ACCESS)
                   A matching username and password could not be found.

            200 (CODE_OK)
                   A  matching  username and password was found, and the login
                   was successful.

       QUIT Requests that the connection be closed.  Possible responses:

            201 (CODE_CLOSING)
                   Normal exit.

            The quit command has the dubious distinction  of  being  the  only
            command that cannot fail.

       LIST <list type>
            Describes various aspects of the database.  The lists are returned
            as a list of records, one per  line.   Each  line  may  contain  a
            number of colon-separated fields.

            Possible values for list type include

               Categories
                      Describes the legal categories for the database.

               Submitters
                      Describes the set of submitters for the database.

               Responsible
                      Lists  the names in the responsible administrative file,
                      including their full names and email addresses.

               States Lists the states  listed  in  the  state  administrative
                      file,  including  the state type (usually blank for most
                      states; the closed state has a special type).

               FieldNames
                      Lists the entire set of PR fields.

               InitialInputFields
                      Lists the fields that should be present  when  a  PR  is
                      initially entered.

               InitialRequiredFields
                      Lists fields that have to be present and nonempty when a
                      PR is initially entered (fields  containing  only  blank
                      characters  such  as  spaces  or newlines are considered
                      empty.)

               Databases
                      Lists the set of databases.

            The possible responses are:

            301 (CODE_TEXT_READY)
                   Normal response, followed by the records making up the list
                   as described above.

            416 (CODE_INVALID_LIST)
                   The requested list does not exist.

       FTYP <field> [<field> ...]
            Describes the type of data held in the field(s) specified with the
            command.  The currently-defined data types are:

            Text   A plain text field, containing exactly one line.

            MultiText
                   A text field possibly containing multiple lines of text.

            Enum   An enumerated data field; the value is  restricted  to  one
                   entry out of a list of values associated with the field.

            MultiEnum
                   The  field  contains one or more enumerated values.  Values
                   are separated with spaces or colons (:).

            Integer
                   The field contains an integer value, possibly signed.

            Date   The field contains a date.

            TextWithRegex
                   The value in the field  must  match  one  or  more  regular
                   expressions associated with the field.

            The possible responses are:

            350 (CODE_INFORMATION)
                   The normal response; the supplied text is the data type.

            410 (CODE_INVALID_FIELD_NAME)
                   The specified field does not exist.

            If  multiple  field names were given, multiple response lines will
            be sent, one for  each  field,  using  the  standard  continuation
            protocol;  each  response  except  the last will have a dash (‘-’)
            immedately after the response code.

       FTYPINFO <field> <property>
            Provides  field-type-related  information.   Currently,  only  the
            property  ‘separators’  for  MultiEnum  fields is supported.  When
            ‘separators’ is specified, the possible return codes are:

            350 (CODE_INFORMATION)
                   A proper MultiEnum field was  specified  and  the  returned
                   text is the string of separators specified for the field in
                   the dbconfig file, quoted within ’’.

            435 (CODE_INVALID_FTYPE_PROPERTY)
                   The ‘separators’ property is not defined  for  this  field,
                   i.e. the specified field is not of type MultiEnum.

            Currently,  specifying  a  different  property  than  ‘separators’
            results in return code 435 as above.

       FDSC <field> [<field> ... ]
            Returns a human-readable description of the listed field(s).   The
            possible responses are:

            350 (CODE_INFORMATION)
                   The  normal  response;  the  supplied  text  is  the  field
                   description.

            410 (CODE_INVALID_FIELD_NAME)
                   The specified field does not exist.

            Like the FVLD command, the standard continuation protocol will  be
            used if multiple fields were specified with the command.

       FIELDFLAGS <field> [<field> ... ]
            Returns  a  set  of  flags describing the specified field(s).  The
            possible  responses  are   either   410 (CODE_INVALID_FIELD_NAME),
            meaning  that  the  specified  field is invalid or nonexistent, or
            350 (CODE_INFORMATION) which contains the set  of  flags  for  the
            field.   The  flags  may  be blank, which indicate that no special
            flags have been set for this field.

            Like the FDSC and FTYP  commands,  multiple  field  names  may  be
            listed  with the command, and a response line will be returned for
            each one in the order that the fields appear on the command  line.

            The flags include:

            textsearch
                   The  field  will  be  searched  when a text field search is
                   requested.

            allowAnyValue
                   For fields that contain enumerated values, any legal  value
                   may  be used in the field, not just ones that appear in the
                   enumerated list.

            requireChangeReason
                   If the field is edited, a reason for  the  change  must  be
                   supplied  in  the new PR text describing the reason for the
                   change.  The reason must be  supplied  as  a  multitext  PR
                   field  in the new PR whose name is field-Changed-Why (where
                   field is the name of the field being edited).

            readonly
                   The field is read-only, and cannot be edited.

       FVLD <field>
            Returns one or more regular expressions or strings  that  describe
            the valid types of data that can be placed in field.  Exactly what
            is returned is dependent on the type of data that can be stored in
            the  field.  For most fields a regular expression is returned; for
            enumerated fields, the returned  values  are  the  list  of  legal
            strings that can be held in the field.

            The possible responses are:

            301 (CODE_TEXT_READY)
                   The  normal  response,  which  is  followed  by the list of
                   regexps or strings.

            410 (CODE_INVALID_FIELD_NAME)
                   The specified field does not exist.

       VFLD <field>
            VFLD can be used to validate a given value  for  a  field  in  the
            database.  The client issues the VFLD command with the name of the
            field to validate as an argument.  The server will either  respond
            with 212 (CODE_SEND_TEXT), or 410 (CODE_INVALID_FIELD_NAME) if the
            specified field does not exist.

            Once the 212 response is received  from  the  server,  the  client
            should  then  send  the line(s) of text to be validated, using the
            normal quoting mechanism described for PRs.   The  final  line  of
            text  is  followed  by a line containing a single period, again as
            when sending PR text.

            The server will then either respond with 210 (CODE_OK), indicating
            that the text is acceptable, or one or more error codes describing
            the problems with the field contents.

       INPUTDEFAULT <field> [<field> ... ]
            Returns the suggested default value for  a  field  when  a  PR  is
            initially    created.    The   possible   responses   are   either
            410(CODE_INVALID_FIELD_NAME), meaning that the specified field  is
            invalid  or  nonexistent, or 350 (CODE_INFORMATION) which contains
            the default value for the field.

            Like the FDSC and FTYP  commands,  multiple  field  names  may  be
            listed  with the command, and a response line will be returned for
            each one in the order that the fields appear on the command  line.

       RSET Used  to  reset  the  internal  server  state.   The current query
            expression is cleared, and the index of PRs may be  reread  if  it
            has been updated since the start of the session.
            The possible responses are:

            200 (CODE_OK)
                   The state has been reset.

            440 (CODE_CMD_ERROR)
                   One or more arguments were supplied to the command.

            6xx (internal error)
                   There  were  problems  resetting the state (usually because
                   the index could  not  be  reread).   The  session  will  be
                   immediately terminated.

       LKDB Locks  the main GNATS database.  No subsequent database locks will
            succeed until the lock is removed.  Sessions that attempt to write
            to the database will fail.
            The possible responses are:

            200 (CODE_OK)
                   The lock has been established.

            440 (CODE_CMD_ERROR)
                   One or more arguments were supplied to the command.

            431 (CODE_GNATS_LOCKED)
                   The  database  is already locked, and the lock could not be
                   obtained after 10 seconds.

            6xx (internal error)
                   An internal error occurred, usually because  of  permission
                   or  other filesystem-related problems.  The lock may or may
                   not have been established.

       UNDB Unlocks the database.  Any session may steal a database  lock;  no
            checking of any sort is done.
            The possible responses are:

            200 (CODE_OK)
                   The lock has been removed.

            432 (CODE_GNATS_NOT_LOCKED)
                   The database was not locked.

            440 (CODE_CMD_ERROR)
                   One or more arguments were supplied to the command.

            6xx (internal error)
                   The  database lock could not be removed, usually because of
                   permissions or other filesystem-related issues.

       LOCK <PR> <user> [<pid>]
            Locks the specified PR, marking the lock with the  name  user  and
            the  optional  pid.   (No  checking  is  done that the user or pid
            arguments are valid or meaningful;  they  are  simply  treated  as
            strings.)

            The  EDIT  command requires that the PR be locked before it may be
            successfully executed.  However, it does not require that the lock
            is  owned by the editing session, so the usefulness of the lock is
            simply as an advisory measure.

            The APPN and REPL commands lock the PR  as  part  of  the  editing
            process, and they do not require that the PR be locked before they
            are invoked.

            The possible responses are:

            440 (CODE_CMD_ERROR)
                   Insufficient or too many arguments were  specified  to  the
                   command.

            300 (CODE_PR_READY)
                   The  lock  was  successfully  obtained;  the text of the PR
                   (using the standard quoting mechanism for PRs) follows.

            400 (CODE_NONEXISTENT_PR)
                   The PR specified does not exist.

            430 (CODE_LOCKED_PR)
                   The PR is already locked by another session.

            6xx (internal error)
                   The PR lock  could  not  be  created,  usually  because  of
                   permissions or other filesystem-related issues.

       UNLK <PR>
            Unlocks  PR.   Any user may unlock a PR, as no checking is done to
            determine if the requesting session owns the lock.

            The possible responses are:

            440 (CODE_CMD_ERROR)
                   Insufficient or too many arguments were  specified  to  the
                   command.

            200 (CODE_OK)
                   The PR was successfully unlocked.

            433 (CODE_PR_NOT_LOCKED)
                   The PR was not locked.

            6xx (internal error)
                   The PR could not be unlocked, usually because of permission
                   or other filesystem-related problems.

       DELETE <PR>
            Deletes the specified PR.  The user making the request  must  have
            admin  privileges.   If  successful,  the  PR  is removed from the
            filesystem and the index file; a gap will be left in the numbering
            sequence for PRs.  No checks are made that the PR is closed.

            The possible responses are:

            200 (CODE_OK)
                   The PR was successfully deleted.

            422 (CODE_NO_ACCESS)
                   The   user  requesting  the  delete  does  not  have  admin
                   privileges.

            430 (CODE_LOCKED_PR)
                   The PR is locked by another session.

            431 (CODE_GNATS_LOCKED)
                   The database has been locked, and no  PRs  may  be  updated
                   until the lock is cleared.

            6xx (internal error)
                   The  PR  could not be successfully deleted, usually because
                   of permission or other filesystem-related problems.

       CHEK [initial]
            Used to check the text of an entire PR  for  errors.   Unlike  the
            VFLD  command,  it  accepts  an  entire  PR at once instead of the
            contents of an individual field.

            The initial argument indicates that the PR text to be  checked  is
            for  a  PR  that  will  be  newly  created, rather than an edit or
            replacement of an existing PR.

            After the CHEK command is issued, the  server  will  respond  with
            either a 440 (CODE_CMD_ERROR) response indicating that the command
            arguments were incorrect, or a 211  (CODE_SEND_PR)  response  code
            will be sent.

            Once  the  211  response  is  received from the server, the client
            should send the PR using the  normal  PR  quoting  mechanism;  the
            final  line  of  the  PR  is  then followed by a line containing a
            single period, as usual.

            The server will then respond with either a 200 (CODE_OK) response,
            indicating  there  were no problems with the supplied text, or one
            or more error codes listing the problems with the PR.

       EDIT <PR>
            Verifies  the  replacement  text  for  PR.   If  the  command   is
            successful,  the  contents  of PR are completely replaced with the
            supplied text.  PR must previously have been locked with the  LOCK
            command.

            The possible responses are:

            431 (CODE_GNATS_LOCKED)
                   The  database  has  been  locked, and no PRs may be updated
                   until the lock is cleared.

            433 (CODE_PR_NOT_LOCKED)
                   The PR was not previously locked with the LOCK command.

            400 (CODE_NONEXISTENT_PR)
                   The specified  PR  does  not  currently  exist.   The  SUBM
                   command should be used to create new PRs.

            211 (CODE_SEND_PR)
                   The  client  should  now  transmit  the replacement PR text
                   using the normal PR quoting mechanism.  After  the  PR  has
                   been  sent,  the  server  will  respond  with  either a 200
                   (CODE_OK) response indicating the edit was  successful,  or
                   one  or  more error codes listing problems with either with
                   the  replacement  PR  text,  or  errors  encountered  while
                   updating the PR file or index.

       APPN <PR> <field>

       REPL <PR> <field>
            Appends  to  or  replaces  the  contents  of  field in PR with the
            supplied  text.   The  command  returns   a   201 (CODE_SEND_TEXT)
            response;  the  client should then transmit the new field contents
            using the standard PR quoting mechanism.   After  the  server  has
            read  the  new  contents,  it  then attempts to make the requested
            change to the PR.

            The possible responses are:

            200 (CODE_OK)
                   The PR field was successfully changed.

            400 (CODE_NONEXISTENT_PR)
                   The PR specified does not exist.

            410 (CODE_INVALID_FIELD_NAME)
                   The specified field does not exist.

            402 (CODE_UNREADABLE_PR)
                   The PR could not be read.

            431 (CODE_GNATS_LOCKED)
                   The database has been locked, and no  PRs  may  be  updated
                   until the lock is cleared.

            430 (CODE_LOCKED_PR)
                   The  PR is locked, and may not be altered until the lock is
                   cleared.

            413 (CODE_INVALID_FIELD_CONTENTS)
                   The supplied (or resulting) field contents  are  not  valid
                   for the field.

            6xx (internal error)
                   An  internal  error occurred, usually because of permission
                   or other filesystem-related problems.  The PR  may  or  may
                   not have been altered.

       SUBM Submits a new PR into the database.  The supplied text is verified
       for correctness, and if no problems are found a new PR is created.

            The possible responses are:

            431 (CODE_GNATS_LOCKED)
                   The database has been locked, and no PRs may  be  submitted
                   until the lock is cleared.

            211 (CODE_SEND_PR)
                   The  client  should  now transmit the new PR text using the
                   normal quoting mechanism.  After the PR has been sent,  the
                   server  will  respond  with either a 200 (CODE_OK) response
                   indicating that the new PR has been created (and mail  sent
                   to  the  appropriate  persons),  or one or more error codes
                   listing problems with the new PR text.

       CHDB <database> [<userid> [<password>]]
              Switches the current database  to  the  name  specified  in  the
              command.   An  optional  username  or  an  optional username and
              password may be given.

            The possible responses are:

            422 (CODE_NO_ACCESS)
                   The user does not have permission to access  the  requested
                   database.

            417 (CODE_INVALID_DATABASE)
                   The  database  specified  does  not  exist,  or one or more
                   configuration errors in the database were encountered.

            210 (CODE_OK)
                   The current  database  is  now  database.   Any  operations
                   performed  will  now be applied to that database.  The user
                   access level for the new database is also returned.

       DBLS   Lists the known set of databases.

            The possible responses are:

            6xx (internal error)
                   An internal error was encountered while  trying  to  obtain
                   the  list  of  available  databases, usually due to lack of
                   permissions or other filesystem-related  problems,  or  the
                   list of databases is empty.

            301 (CODE_TEXT_READY)
                   The  list  of  databases  follows,  one per line, using the
                   standard quoting mechanism.  Only the  database  names  are
                   sent.

       DBDESC <databasename>
              Returns  a human-readable description of the specified database.
              Responses include:

            6xx (internal error)
                   An internal error was encountered while trying to read  the
                   list  of  available  databases,  usually  due  to  lack  of
                   permissions or other filesystem-related  problems,  or  the
                   list of databases is empty.

            350 (CODE_INFORMATION)
                   The  normal  response;  the  supplied  text is the database
                   description.

            417 (CODE_INVALID_DATABASE)
                   The specified database name does not have an entry.

       EXPR <query expression>
              Specifies a  query  expression  used  to  limit  which  PRs  are
              returned  from the QUER command.  The expression uses the normal
              query expression syntax, as described in the  manual  entry  for
              query-pr(1).

            Multiple  EXPR commands may be issued; the expressions are boolean
            ANDed together.

            Expressions are cleared by the RSET command.

            Possible responses include:

            415 (CODE_INVALID_EXPR)
                   The specified expression  is  invalid,  and  could  not  be
                   parsed.

            200 (CODE_OK)
                   The expression has been accepted, and will be used to limit
                   the results returned from QUER.

       QFMT <query format>
            Use the specified query format to format the output  of  the  QUER
            command.   The  query  format  may  be  either the name of a query
            format known to the server, or an actual query format.
            The possible responses are:

            200 (CODE_OK)
                   The normal response, which indicates that the query  format
                   is acceptable.

            440 (CODE_CMD_ERROR)
                   No query format was supplied.

            418 (CODE_INVALID_QUERY_FORMAT)
                   The  specified query format does not exist, or could not be
                   parsed.

       QUER [PR] [PR] [...]
            Searches the contents of the  database  for  PRs  that  match  the
            (optional)  specified  expressions  with  the EXPR command.  If no
            expressions were specified with EXPR, the entire  set  of  PRs  is
            returned.

            If  one  or  more PRs are specified on the commandline, only those
            PRs will be searched and/or output.

            The format of the output from the command  is  determined  by  the
            query format selected with the QFMT command.

            The possible responses are:

            418 (CODE_INVALID_QUERY_FORMAT)
                   A  valid  format  was  not  specified with the QFMT command
                   prior to invoking QUER.

            300 (CODE_PR_READY)
                   One or more PRs will be output using  the  requested  query
                   format.   The  PR  text  is quoted using the normal quoting
                   mechanisms for PRs.

            220 (CODE_NO_PRS_MATCHED)
                   No PRs met the specified criteria.

       ADMV <field> <key> [<subfield>]
            Returns an entry from an adm file associated with field.   key  is
            used  to  look  up  the  entry  in  the data file.  If subfield is
            specified, only the value of that subfield is returned; otherwise,
            all  of the fields in the adm data file are returned, separated by
            colons (‘:’).

            The responses are:

            410 (CODE_INVALID_FIELD_NAME)
                   The specified field does not exist.

            221 (CODE_NO_ADM_ENTRY)
                   An adm entry matching the key was not found, or  the  field
                   does not have an adm file associated with it.

            350 (CODE_INFORMATION)
                   The  normal  response;  the  supplied text is the requested
                   field(s).

ENVIRONMENT VARIABLES

       The GNATSDB environment variable is used to determine which database to
       use.   For  a  local  database, it contains the name of the database to
       access.  gnatsd cannot  service  remote  databases  (tho  it  might  be
       interesting if it could) so the database is always assumed to be local.

       If GNATSDB is not set and the --database option is not supplied, it  is
       assumed that the database is local and that its name is default.

SEE ALSO

       Keeping  Track: Managing Messages With GNATS (also installed as the GNU
       Info file gnats.info)

       databases(5), dbconfig(5), delete-pr(8),  edit-pr(1)  file-pr(8),  gen-
       index(8),  gnats(7),  gnatsd(8),  mkcat(8), mkdb(8), pr-edit(8), query-
       pr(1), queue-pr(8), send-pr(1).

COPYING

       Copyright (c) 2000, 2003 Free Software Foundation, Inc.

       Permission is granted to make and distribute verbatim  copies  of  this
       manual  provided  the  copyright  notice and this permission notice are
       preserved on all copies.

       Permission is granted to copy and distribute modified versions of  this
       manual  under  the  conditions  for verbatim copying, provided that the
       entire resulting derived work is  distributed  under  the  terms  of  a
       permission notice identical to this one.

       Permission  is  granted  to  copy  and  distribute translations of this
       manual into another language, under the above conditions  for  modified
       versions,  except  that  this  permission  notice  may  be  included in
       translations approved by the Free Software Foundation instead of in the
       original English.