Re: Be insane.

[Kristaps Dzonsons <kristaps@bsd.lv>]

> I strongly detest this change and am definitely not going to merge it
> to OpenBSD.
>
> This is very un-UNIXish.  We want small tools doing one thing well,
> not monsters gobbling up all functionality everywhere, asking us
> stupid questions.  I consider this bloat seriously reducing usability.
> When a utility has done what i asked for, i want my shell prompt back,
> not some other prompt i first have to cut out of before i can type
> my next command.  I'm not even willing to accept that as an option.

Hi Ingo,

While re-writing mandocdb.c (I'd posted an early version a few weeks ago 
and will properly checkin soon, with the apropos_db.c re-write in tow), 
I've taken the opportunity to critically examine the man(1), apropos(1), 
and whatis(1) tools.

While I understand your opposition, I beg you to approach these tools 
from a position of curiosity and cool-headed analysis instead of 
painting with broad strokes: I certainly didn't spend these many hours 
simplifying, restructuring, and asking "what if..." to have them 
discarded as being "not UNIX-ish", no questions asked!

For that matter, mandoc(1) itself is a poster child of being 
non-UNIX-ish, discarding `tbl | eqn | nroff' for the sake of efficiency 
and simplicity at considerable benefit.  This was possible because of 
the intended usage of mandoc(1).

I claim the current behaviour is in this same spirit of efficiency and 
simplicity.  In short, I'm not concerned with how quickly my 
command-prompt returns to me: I'm concerned with getting the information 
that I want as quickly as possible.  I've observed the following, in my 
own personal usage:

   1.  Calls to apropos(1) and whatis(1) are overwhelmingly followed by 
a call to man(1).
   1a. It sometimes takes a few calls to apropos(1) as I fool around 
with "Gaussian" versus "gaussian" versus "standard normal".
   2.  I barely use whatis(1).
   3.  man(1) is ill-equipped to handle multiple pages by the same name 
(or "identity", broadly speaking).

Point 1. is significant.  We currently use apropos(1) to find a manual, 
then man(1) to look at it.  apropos(1) as a standalone tool makes no 
sense, no?  I rarely just want to know whether a manual exists:  I want 
to read it.  Why not stop pretending apropos(1)/man(1) serve independent 
purposes?  Isn't this bloat?

As for point 2., why do we have two tools that do pretty much the same 
thing?  Isn't this also bloat?

Point 3., for me, is quite annoying.  I have several local trees of 
manuals whose names and sections clobber those of installed utilities. 
man(1) came from a time when all manuals were in one directory and there 
was an assumption that foo1/foo.1 was unique.  This is no longer the 
case, but nobody's stepped forward to say "how do I ask for the SECOND 
foo1/foo.1"?  From OpenBSD's `man -a', what is the "first" manpage 
anyway?  Once multiple manpaths came into play, the assumption of 
uniqueness was violated.  Trying to ignore this is silly.

I think there's room for improvement.  Don't you?

I've not entirely gone off the deep end: regardless of whether I think 
whatis(1) is useless, I'll build in support for it.

Thus, I've settled---this isn't checked in yet because my time's so 
insanely limited these days---on the mandocdb.c re-write and a single 
library function, manpage_search(), passing a search expression and 
getting back results.  I built the search-ask-display behaviour into a 
new manpage(1) utility, then an apropos(1) and whatis(1) doing their 
current silly dance.

Thus, if one chooses to stay with the "UNIX" way, one can do so.  But to 
be honest, I'm happy as a clam running manpage(1) and having it ask me 
when it encounters multiple manuals corresponding to my search.  I don't 
think I've run apropos(1) since.  Certainly none of my time-wasting 
grep(1)ing and locate(1)ing.

Please bear with me: it will take a little while to get all of this put 
in, but in the meantime, it's alright to try new things, then back them 
off (or not!).  The bsd.lv repository, after all, is a good place to do 
that: Bill Joy isn't exactly calling me to denounce my transgressions.

If OpenBSD doesn't want it downstream, so be it---that's ok, it can 
stick with the apropos and whatis.  In the same way, if you want to 
stick with Berkeley DB, then by all means be my guest.  There's no 
reason why we can't push forward and try new things, but despising 
something and calling it monstrous is plain silly.

Best,

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