Bug 227408 - apropos(1) doesn't sort
Summary: apropos(1) doesn't sort
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Baptiste Daroussin
Depends on:
Reported: 2018-04-10 07:42 UTC by Edward Tomasz Napierala
Modified: 2018-10-05 22:30 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Edward Tomasz Napierala freebsd_committer 2018-04-10 07:42:18 UTC
It appears that apropos(1) fails to sort.  It kind of does, but in a funny way.  You can see it with "apropos -s 9 map", and look for eg "pmap" in the output.
Comment 1 Yuri Pankov 2018-10-05 22:30:19 UTC
That's interesting one.

mandoc is trying to be smart here applying what seems to be a "relevance" comparison depending on the "bits" described in mandoc.db.5 (which we don't ship, so src/contrib/mandoc/mandoc.db.5):

    0x10: The name appears in a filename.
    0x08: The name appears in a header line, i.e. in a .Dt or .TH macro.
    0x04: The name is the first one in the title line, i.e. it
          appears in the first .Nm macro in the NAME section.
    0x02: The name appears in any .Nm macro in the NAME section.
    0x01: The name appears in an .Nm block in the SYNOPSIS section.

...so we sort first based on these "bits".  Doing direct arithmetical comparison for bitfields doesn't seem to be correct, more so I'm not sure we should care about them at all -- first section, then alphabetically seems to be "just enough" for me, i.e. I don't see why the page not having relevant .Nm in the SYNOPSIS section would sort less than one containing it if the .Dt sorts otherwise, and that's what going to happen when doing "(bits1 - bits2) != 0".

To sum it up, the proposal is to remove bits comparison from src/contrib/mandoc/mansearch.c:manpage_compare(), and let it sort in "first section, then alphabetically" order.