> "Richard L. Hamilton" wrote: > > > While looking at some other issue with japanese > > > manual pages on a system > > > where multiple users use different locales I hit > the > > > problem that there > > > wasn't a "windex" (manual page index file) for > the > > > japanese manual > > > pages: > > > -- snip -- > > > $ find /usr/share/man -name windex > > > /usr/share/man/windex > > > -- snip -- > > > > > > A quick check shows that "catman -w" creates the > > > manual pages if the > > > locale matches the manual page subdir, e.g. > > > -- snip -- > > > $ (LC_ALL=ja_JP.UTF-8 MANPATH=/usr/share/man > catman > > > -w) > > > $ find /usr/share/man -name windex > > > /usr/share/man/ja_JP.UTF-8/windex > > > /usr/share/man/windex > > > -- snip -- > > > > > > Erm... is this intentional or a bug ? At least I > > > would expect that a > > > "catman -w" crawls/indexes all manual pages of > all > > > locales in one > > > step... or is there a reason why this shouldn't > be > > > done ? > > > > Since I don't see code in > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/ > usr/src/cmd/man/src/man.c > > or > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/ > usr/src/cmd/man/src/makewhatis.sh > > to do them all, I would suppose it is intentional, > or at worst, an omission. > > I'd view it as a feature, since doing > /usr/share/man is already slow enough. > > Erm, I disagree... this and many other small nits > renders the feature of > localiseable manual pages more or less defunct in a > multilinguar > environment (e.g. like an university where everyone > is allowed to run > his/her preferred locale). And exactly this problem > then ends-up in a > problem for contributors: Why should anyone > contribute translated manual > pages when noone can use them properly ? > > Anyway... I'm working on a permanent solution which > should handle most > of the major problems of the current /usr/bin/man > suite, including: > - Doesn't handle localised manual pages and index > information properly > - Doesn't support DocBook/XML manual pages > - alias pages (don't remeber their correct name > ("shadow page" ?), I > mean those SolBook documents which use SGML entities > to use the content > from another SolBook page) rely on an "interesting" > hack in > /usr/lib/sgml/sgml2roff > - Doesn't supress malformed and duplicate entries for > windex > - Doesn't report broken manual pages during windex > generation > - The code is hard to maintain > - The manual page's title should be displayed somehow > - "appropos"&co. should support pattern matching > - <... some more problems...> > > Unfortunately this doesn't solve all problems, e.g. > Linux has some nice > stuff which gets enabled for unicode locales (e.g. > en_US.UTF-8), e.g. > the use of graphical characters beyond ASCII etc. - > but AFAIK one of the > next steps can handle these issues, too > (unfortunately we can't use the > Linux "man" stuff since it has other problems > (zh_CN.GB18030 being one > of them... ;-/ )). > > [snip] > > Since probably very few of my users are likely to > read man pages at all, > > let alone in other than English, I never got too > worried about this; I have > > enough fun digging all man directories out of > /var/sadm/install/contents, > > so as to run catman -w on all of them. > > > > I would like to see a shortcut in makewhatis to > speed it up if nothing had > > changed; i.e something using find with -newer to > check for subdirectories > > that were newer than the windex file. That way, it > wouldn't be unreasonable > > to run something at boot or from cron to > periodically update the windex files. > > Known problem, however it's not easily solveable > (e.g. you can't fully > rely on timestamps and still have to deal with things > like (SGML/XML) > entities included from other places). AFAIK the only > way to do that is > to dump the current "windex" format (which leads to > the question... is > this format "Consolidation Private" ?) and create > something which can > hold more entries per document (e.g. timestamps, > references, included > entities etc.).
Random thoughts: I'll agree with this much - that the "man" toolset is a lot less slick than it could be. A graphical client much better than xman would be nice too. I still miss the old AnswerBook; yes, it depended on dead proprietary technology (not to mention DPS), but it was pretty, and fast, and I think it even had live links. Troff/nroff can't support those, but I would suppose SGML/XML source could allow for them; and if there were tools to generate PDF, I think most PDF readers should be able to support embedded links, although I haven't tried that in the x86 alternatives to acroread. Or maybe alternatives like TkMan or Multivalent should be considered for a GUI user interface. A text interface remains handy; sometimes stuff happens, and you need to look something up in the middle of nowhere with just a serial console. I don't know how much it's worth enhancing though. Some quick and probably inadequate searches didn't show me anything other than makewhatis.sh and man.c in ON that use the windex files. Unfortunately, the catman man page does document the windex file format (and for all I know may have done so prior to any concerns about interface taxonomy), so people could have written scripts to run against that format. Perhaps one could still have a better file format, out of which windex could be regenerated for compatibility, and that better file format might contain enough info to correctly determine whether regenerating it or windex was necessary. I suspect that regenerating windex at package install/remove time is not practical, although at first glance, it's tempting. At the very least, the catman man page should document that one needs to run catman -w for each locale subdirectory (that one wishes to support) of each man directory. But then, none of the apropos(1), catman(1m), man(1), and whatis(1) man pages seem to have been updated to document the existence of or support for man pages in multiple locales. This message posted from opensolaris.org
