Fri, 1 Jul 2016 22:59:16 +0200 Ingo Schwarze <[email protected]> > Hi Andy, > > >>> Using OpenBSD 5.8-stable. > >>> > >>> I used to have the following in /etc/man.conf: > >>> > >>> tcl85 /usr/local/lib/tcl/tcl8.5/man/ > >>> tcl86 /usr/local/lib/tcl/tcl8.6/man/ > >>> > >>> Which made it easy to view one or the other by using the section > >>> argument: > >>> > >>> man tcl85 Tcl > >>> man tcl86 Tcl > >>> > >>> man(1) still appears to be documented to have this functionality: > >>> > >>> man [-acfhklw] [-C file] [-I os=name] [-K encoding] [-M path] [-m path] > >>> [-O option=value] [-S subsection] [-s section] [-T output] [-W level] > >>> [section] name ... > >>> ^^^^^^^^^ > >>> > >>> But I see no way of expressing it in the new man.conf or addressing it > >>> in the command line. Here is what I have added according to the new > >>> man.conf(5): > >>> > >>> manpath /usr/local/lib/tcl/tcl8.5/man > >>> manpath /usr/local/lib/tcl/tcl8.6/man > > That's not necessarily a good idea; it adds both directories to the > default search path, so you may end up seeing Tcl documentation > when looking for something completely different. Then again, nothing > wrong with that if you do indeed want to have both Tcl dirs searched > by default... > > >>> But I don't see how to use [section] anymore. man(1) does mention using > >>> [-s section] with n as the section, but that only seems to display the > >>> first match of tcl8.5 and does not allow further granularity (as far as > >>> I can tell). > >>> > >>> Have I missed something in the man pages, or what am I doing wrong? > > >> i don;t think it's currently possible to do exactly what you propose. > >> i think ingo stripped man.conf pretty bare. > > Correct. > > In my 2015 BSDCan talk, i offered to implement, in man.conf(5), > > alias aliasname dirname > > such that for example > > alias tcl85 /usr/local/lib/tcl/tcl8.5/man > > would allow saying > > man -M tcl85 Tcl > > But i also said: > > "So far, there is no noticeable demand -> KISS." > > That is still true a year later, and personally, i consider > shell aliases a very good solution, not merely a workaround. > > All the same, if enough people want the feature, in particular if > somebody can present a compelling argument why shell aliases are > not a good solution, i'm still willing to implement it. > > >> the workarounds would be: > >> > >> - have multiple conf files and use man -C to get the one you want > >> - use man -m on the command line (or aliases) to get what you want > > That's what i recommend. For example: > > alias man85="man -M /usr/local/lib/tcl/tcl8.5/man" > > That doesn't even require editing /etc/man.conf, > and it can be used like this: > > $ man85 -k search > Tcl_GetEncodingSearchPath(3) - Tcl_GetEncodingSearchPath > Tcl_SetEncodingSearchPath(3) - Tcl_SetEncodingSearchPath > lsearch(n) - lsearch > $ man85 lsearch > lsearch(n) Tcl Built-In Commands lsearch(n) > [...] > > >> i think man(1) is currently wrong regarding the section values in -s > >> (i'll look into that). > > That was just fixed. > > > The multiple configuration files is one working approach to multiple > > work directory invocation, and these can coexist. Then more over so, > > there must be a way to call tcl85 and tcl86 something else than both > > "Tcl" right? Meaning maybe also seek ways to reconcile these in Tcl > > land & potentially other multiple versions environments. W/ regards, > > please excuse me, if this is out of line or just plain inappropriate. > > I don't think renaming stuff in ports would be wise. It would cause > a considerable maintenance burden for the port maintainer, and > having stuff renamed to something differing from upstream might > also surprise people who only use one single version.
I agree completely, thank you for enumerating these consequences as well. I presumed it'd be offsetting to add the question of branching & version numbering of software (programming languages most frequently), ending up in various cuts (as the "maintained" releases). Still I wanted to query your stance on the version names in relation to manual pages, as this is where it all ends (and just begins depending on view point, introductory approach, development methods). Thanks for considering this byway point. > Having manual pages of the same name is not a problem as long as they > live in different manpath trees. > > Yours, > Ingo
