hunt — Retrieve items from an mkey index.


hunt [-agp] [-Cn] [-F[ynd]] [-i string] [-l n] [-o string] [-T[ynd]] [-t string] < file


The hunt program retrieves items from an index. It combines, as mentioned above, the two parts of that process: search and delivery. The reason why it is efficient to combine delivery and search is partly to avoid starting unnecessary processes, and partly because the delivery operation must be a part of the search operation in any case. Because of the hashing, the search part takes place in two stages: first items are retrieved which have the right hash codes associated with them, and then the actual items are inspected to determine false drops, i.e. to determine if anything with the right hash codes doesn’t really have the right keys. Since the original item is retrieved to check on false drops, it is efficient to present it immediately, rather than only giving the tag as output and later retrieving the item again. If there were a separate key file, this argument would not apply, but separate key files are not common.

Input to hunt is taken from the standard input, one query per line. Each query should be in mkey -s output format; all lower case, no punctuation. The hunt program takes one argument which specifies the base name of the index files to be searched. Only one set of index files can be searched at a time, although many text files may be indexed as a group, of course. If one of the text files has been changed since the index, that file is searched with fgrep; this may occasionally slow down the searching, and care should be taken to avoid having many out of date files.

The following option arguments are recognized by hunt:

The timing of hunt is complex. Normally the hash table is overfull, so that there will be many false drops on any single term; but a multi-term query will have few false drops on all terms. Thus if a query is underspecified (one search term) many potential items will be examined and discarded as false drops, wasting time. If the query is overspecified (a dozen search terms) many keys will be examined only to verify that the single item under consideration has that key posted.

As would be expected, the optimal search is achieved when the query just specifies the answer; however, overspecification is quite cheap. In general, overspecification can be recommended; it protects the user against additions to the data base which turn previously uniquely-answered queries into ambiguous queries.


@BINDIR@/hunt Executable.


The text of this manual page comes from Some application of Inverted Indexes in the UNIX System by M. E. Lesk, which is distributed under the bsd4 license. The software hunt is distributed under the cddl license.


refer(1), referformat(7), sortbib(1), hunt(1), mkey(1), inv(1), and Some application of Inverted Indexes in the UNIX System by M. E. Lesk.


M. E. Lesk, modified by Pierre-Jean Fichet.