suggested fixes from Tom Lane. I played it safe and went with (my
variation of) the minimal fix.
port-hppa/56118: sporadic app crashes in HPPA -current
There's no point initializing database state if we're then going to
fail to locate any man page sources. Make all the initial state checks
contiguous for simplicity and readability. Also, free the variable
"command" on the error path, and correct the error message.
In revision 1.6 of whatis.c the query was modified to return matches for names found
in MLINKS of the man pages as well. However it was slow. The reason probably being that it
required a join. But more importantly the where condition on an FTS virtual table column
is very slow. To avoid the join and the expensive where condition on the virtual table,
add the name_desc column to the mandb_links table as well. This improves the performance
of whatis(1) to the original level at the expense of slight data duplication.
Bump the schema to force database rebuild to take account for the new column addition
mparse_alloc() altered - update the call here to compensate.
This fixes the build (of makemandb), but I am not sure that
the changed version is what is desired - someone who knows
something about all of this should validate ... I just copied
the invocation from mandoc's demandoc.c (which seems likely
to be at least a similar kind of usage).
mandoc(3) already generates the text node representing the value for the .Nm macro.
Doing our own parsing for .Nm on top of that leads to large duplication of text
in the database. This gets specially worse for man pages with large NAME sections,
such as queue(3).
There can be symlinks which are pointing to man pages not installed in
one of the _default locations mentioned in man.conf or MANPATH. For example
there are man pages in /usr/pkg/man which are symlinked to pages in
/usr/pkg/lib/perl5/man. If we ignore symlinks, we would not be able to
index such pages installed outside the default set of directories.
(Also, the symlink test was incorecct, so we never noticed this issue)
Ok christos@, wiz@
sections multiple times. This started to happen because, pmdoc_Sh(), the handler function
responsible for parsing the Sh macros, used to recursively go through all the child
nodes and then the next nodes starting from top level Sh block node.
Now, once it has processed all the child nodes of the top level block node,
it moves to the next node, which is the top level block node of the next section and
in this way one call to pmdoc_Sh() was causing a complete pass through the
man page. Since, mandoc(3) calls pmdoc_Sh() for each .Sh macro in the man
page, it would result in parsing some of the sections multiple times.
This never happened with the previous versions of mandoc, so we never noticed.
I've fixed this by starting the parse sequence of the Sh macro from its body, which gurantees
that we will stop once that section ends.
ok christos@
than parsing it by hand.
With the latest mandoc(3), the .Nd macro was getting parsed twice. This fixes
that problem and cleans up the code as well.
ok christos@
With the latest API, mdoc_validate()/man_validate() needs to be called before
reading the roff_man.meta field, otherwise it is NULL.
Also, if a man page doesn't specify machine architecture, don't default to '?'
, let it be stored as null in the db. Otherwise, the output of apropos(1) shows
the names of the results as \?/<title>
before actually updating anything, since changing the db while the query
that extracts the list of files is still in progress results in
the extraction query failing before it finds everything.
gutteridge