[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: our broken man package



Steve Greenland <stevegr@debian.org> writes:
> Joey Hess <joeyh@debian.org> wrote: 
>> Lars Wirzenius wrote:

>>> And, anyway, caching might be done in a cronjob: look at the pages
>>> a in manpath every night, check which ones have been accessed
>>> since the past run, and format those. Then delete anything older
>>> than N days in the cache. When displaying, use the cached version
>>> only if it is newer than the source.
>> 
>> That's a good idea.
> 
> The only (small) problem is that you don't cache the first day. Thus
> the sequence
> 	
> 		man bash
> 		try something
> 		man bash
> 		try something else
> 		man bash
> 		(etc...)
> 
> results in the bash man page being formatted each time. (Yeah, if I
> *knew* was going to be looking at it several times, I'd save it myself,
> or use another window/console, but it never seems to work out that way.)

I spent some time writing a userv-based man implementation a while
ago.  The basic idea was something like this:

 * The man front end calls userv to re-invoke itself as a "man" user,
   and expects data back which it can feed into the pager (or write to
   stdout or whatever it is the user wants).

 * When invoked as the "man" user, it looks at the ownership of the
   file it's supposed to format.  If it's root (or "man", I suppose)
   then it invokes groff directly; otherwise it uses userv to get the
   user that owns the file to format it (presumably via groff again).

   All the caching takes place as the "man" user.

Where you do the searching in all this ... well, you could add another
userv service to ask for man pages matching a name/section pair in a
named directory, and have the standard version do whatever
request->path caching you felt best.

The binary in my /usr/local still seems to work, so perhaps I should
bring it up to scratch and let the rest of the world have a look...

-- 
http://www.greenend.org.uk/rjk/



Reply to: