Re: Emulating apropos/man.cgi behaviour.

[Kristaps Dzonsons <kristaps@bsd.lv>]

>> I'm trying to duplicate the behaviour of OpenBSD's apropos(1) and
>> man.cgi.  I find they're somewhat inconsistent, but enclosed is a
>> patch that does so.  My notes follow.
>>
>> First, OpenBSD's apropos(1) accepts `-S' in that it prints manuals
>> that have no architecture alongside those that have specified the
>> same one. Try apropos -S amd64 intro for an example.  I'd think an
>> architecture would select ONLY those manuals with that architecture,
>> but...
>
> Well, that behaviour makes some sense: -S amd64 gets you all
> manuals valid for amd64.

I checked this in, although I left the manuals as-is (your explanation 
made sense).

>> Second, man.cgi outright throws away architecture and section when
>> running apropos.  Er...?
>
> That sounds like a bug, i don't think we need to copy that.
> There *are* bugs in man.cgi, you know.  ;-)

Great!  If this is really desired, it's easy to add legacy fiddling back 
in (the code extracting query values is abstracted).

>> Note that my man.cgi is a bit different from OpenBSD's.  Mine has a
>> "whatis" or "apropos" search type, which return the same results of
>> the command-line of the same.  If, however, there's only one result,
>> that result is displayed.  My reasoning was behind a personal
>> distaste for how man(1) unintuitively handles multiple manuals
>> matching the same query (e.g., man intro): it seems intuitive to
>> display all matches and let the user decide, instead of picking the
>> first one and hoping it matches PATH order.
>
> Sounds reasonable on first sight, in particular on the web.
> A clickable list on the web is easy to use.
>
> Regarding apropos(1), i think staying rather close to established
> behaviour is relevant.  But for man.cgi, what matters is not breaking
> links; if we can present information in a better way, that's not
> necessarily a problem, i don't thing people will request slavishly
> following the old way - in particular since the old script has so
> many deficiencies.

As of now, man.cgi is still ignoring:

  (1) output format.  I guess this can be added in, but why?  It seems 
strange to have non-HTML for a browser, unless somebody's using this to 
remotely fetch manuals to their terminal.
  (2) release.  We've discussed this already and it's the subject of my 
scrutiny now.
  (3) the "title" key, which changes the title of the page.  Fui.
  (4) search bar in header of found pages.  Is this necessary?  I've 
never really liked it, but it's trivial to add in.

One nit I just noticed is that passing a legacy man.cgi query of 
"(section)" shows all the manuals in that section (like from the man.cgi 
main page).  I can easily intercept this (noting "legacy" mode and a 
strcmp) and translate it to the proper form, which is ~.* and a section 
number.

Thanks,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv