|const struct mansearch *search|
Search options, defined in
.In mansearch.h .
|const struct manpaths *paths|
Directories to be searched, defined in
.In manpath.h .
|int argc, char *argv|
|Search criteria, usually taken from the command line.|
The const char *outkey selects which data to return in the output field of the res structures. It takes any of the macro keys defined in mansearch_const.c and described in apropos(1).
The output arguments are as follows:
|struct manpage **res|
Returns a pointer to an array of result structures defined in
.In mansearch.h . The user is expected to call free(3) on the file, names, and output fields of all structures, as well as the res array itself.
|Returns the number of result structures contained in res.|
To speed up searches, the mansearch_setup function can optionally be called with a start argument of 1 before mansearch to set up an SQLite3 pagecache. If it was called, it has to be called again with a start argument of 0 after the last call to mansearch to release the memory used for the pagecache.
For each manual page tree, the search is done in two steps. In the first step, a list of pages matching the search criteria is built. In the second step, the requested information about these pages is retrieved from the database and assembled into the res array.
All function mentioned here are defined in the file mansearch.c. No functions except mansearch and sql_statement build any SQL code, and no functions except mansearch, buildnames, and buildoutput execute it.
The query is built using the following grammar:<query> ::= "SELECT * FROM mpages WHERE" <condition> <condition> ::= "(" <condition> ")" | <condition> "OR" <condition> | <condition> "AND" <condition> | "desc" <operator> "?" | "id IN (SELECT pageid FROM" <subquery> ")" <subquery> ::= "names WHERE name" <operator> "?" | "keys WHERE key" <operator> "? AND bits & ?" <operator> ::= "MATCH" | "REGEXP"
The MATCH and REGEXP operators are implemented by the functions sql_match and sql_regexp, respectively. This is required because SQLite3 natively neither supports case-insensitive substring matching nor regular expression matching, but only string identity, shell globbing, and the weird home-brewed LIKE operator.
Command line parsing is done by the function exprcomp building a singly linked list of
.Vt expr structures, using the helper functions exprterm and exprspec. The resulting SQL statement is assembled by the function sql_statement and evaluated in the main loop of the mansearch function.
The names, sections, and architectures of the manuals found are assembled into the names field of the result structure by the function buildnames, using the following query:
SELECT * FROM mlinks WHERE pageid=? ORDER BY sec, arch, name
If the outkey differs from "Nd", the requested output data is assembled into the output field of the result structure by the function buildoutput, using the following query:
SELECT * FROM keys WHERE pageid=? AND bits & ?
mandoc.db The manual page database.
The simplest invocation
results in the following SQL query:SELECT * FROM mpages WHERE ( id IN (SELECT pageid FROM names WHERE name MATCH keyword) OR desc MATCH keyword );
A more complicated request like
apropos -s 2 Nm,Xr=getuid
results in:SELECT * FROM mpages WHERE ( id IN (SELECT pageid FROM names WHERE name MATCH getuid) OR id IN (SELECT pageid FROM keys WHERE key MATCH getuid AND bits & 4) ) AND id IN (SELECT pageid FROM keys WHERE key REGEXP ^2$ AND bits & 2);
apropos(1), mandoc.db(5), makewhatis(8)
The mansearch subsystem first appeared in
.Ox 5.6 .
.An -nosplit A module to search manual page databases was first written by
.An Kristaps Dzonsons Aq Mt email@example.com in 2011, at first using the Berkeley DB; he rewrote it for SQLite3 in 2012. The current version received major changes from
.An Ingo Schwarze Aq Mt firstname.lastname@example.org .