linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Ingo Schwarze <schwarze@usta.de>, Colin Watson <cjwatson@debian.org>
Cc: linux-man@vger.kernel.org, g.branden.robinson@gmail.com,
	man-db-devel@nongnu.org
Subject: Re: Linux man-pages Makefile portability
Date: Sun, 24 Jul 2022 13:09:23 +0200	[thread overview]
Message-ID: <ff01b98c-563f-dfd3-4996-65ff5e5f44ce@gmail.com> (raw)
In-Reply-To: <Ytw65nGl1qouSU5R@asta-kit.de>

[TO += Colin; CC += man-dv-devel@;
there's a bug in man(1)'s autocomplete]

Hi Ingo (and Colin),

On 7/23/22 20:16, Ingo Schwarze wrote:
> [...]
>>> The system making the heaviest use of section suffixes i'm aware of
>>> is Solaris:
>>>
>>>     > uname -a
>>>     SunOS unstable11s 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise
>>>     > ls /usr/share/man/
>>>     entities      man3dat       man3mvec      man3sysevent    man4b
>>>     fr            man3dax       man3nsl       man3tcl         man5
>>>     fr.ISO8859-1  man3devid     man3nvpair    man3tecla       man5oldap
>>>     fr.UTF-8      man3devinfo   man3oldap     man3tiff        man5openssl
>>>     it            man3dlpi      man3openssl   man3tsol        man7
>>>     it.ISO8859-1  man3dns_sd    man3p         man3uuid        man7d
>>>     it.UTF-8      man3elf       man3pam       man3volmgt      man7fs
>>>     ja_JP.UTF-8   man3exacct    man3pcap      man3x           man7i
>>>     man-index     man3ext       man3perl      man3x11         man7ipp
>>>     man.cf        man3f         man3pi        man3xau         man7m
>>>     man1          man3fcoe      man3picl      man3xaw         man7openssl
>>>     man1b         man3fm        man3picltree  man3xcb         man7p
>>>     man1c         man3fstyp     man3plot      man3xcomposite  man8
>>>     man1m         man3gen       man3pool      man3xcurses     man8oldap
>>>     man1oldap     man3gss       man3proc      man3xcursor     man8s
>>>     man1openssl   man3hbaapi    man3project   man3xevie       man9
>>>     man1s         man3head      man3rad       man3xext        man9e
>>>     man1t         man3iscsit    man3reparse   man3xi          man9f
>>>     man2          man3kstat     man3resolv    man3xinerama    man9p
>>>     man3          man3kvm       man3rpc       man3xmu         man9s
>>>     man3archive   man3layout    man3sasl      man3xnet        pl
>>>     man3c         man3ldap      man3scf       man3xrandr      pl.ISO8859-2
>>>     man3c_db      man3lgrp      man3sec       man3xss         pl.UTF-8
>>>     man3cc4       man3lib       man3sip       man3xt          ru.KOI8-R
>>>     man3cfgadm    man3m         man3slp       man3xtsol       ru.UTF-8
>>>     man3cmi       man3mail      man3snmp      man3xtst        zh_CN.UTF-8
>>>     man3commputil man3malloc    man3socket    man3xv
>>>     man3contract  man3mlib      man3srpt      man3xxf86vm
>>>     man3cpc       man3mp        man3ssh2      man3zonestat
>>>     man3curses    man3mpapi     man3stmf      man4
> 
>> Wow!
>> Although it's interesting to know that this list exists:
>> I can check it when trying to come up with a section name.
> 
> I would somewhat advise against that.  While i do think that consistency
> is good *if* you decide to use a section suffix, i'd still recommend
> to use section suffixes sparingly, at least in operating systems
> that use them sparingly now.  They provide relatively little value,
> make the top directory of the manpath larger and less readable,

I don't think there's any benefit of keeping $(mandir) contain only the 
standard man? subdirs.  Everybody already knows about them, so nobody 
needs to read the output of ls(1) in such a system.  On the other hand, 
reading the output of ls(1) in a system with free use of subsections 
provides useful information.  If one needs to filter a bit, standard 
Unix tools come into play.

> and they are in particular *not* well suited to moving stuff out of
> the non-suffix directories that users may not wish to see by default.
> For example, suppose you created a directory man3py to document
> python library functions.  As explained above, these pages will *still*
> show up even when people type "man 3" or "man 3p" rather than "man 3py".

But the good thing is they can be put the last in the list of pages to 
be shown by man(1), so they won't hide another page.

In my Debian system, man(1) shows:

  1 n l 8 3 0 2 3posix 3pm 3perl 3am 5 4 9 6 7

3type and 3const could go at the end of that, to avoid hiding pages in 
section 7.

While testing some related stuff to add to my arguments, I just 
understood of a bug that I knew existed but never thought too much about 
it, and related to one that Branden reported to me recently:

man 3 foo[TAB]

autocomplete is smart enough to only search pages in section 3 (I don't 
know if it finds pages in subsections from 3; I guess it does).

man [-s]3type foo[TAB]

autocomplete should search in 3type, but it doesn't quite work.
However, I noticed there's a difference in behavior between 3posix and 
3type (3posix only exists as a suffix, but pages live in man3; 3type is 
a correct subsection, using man3type and .3type), so maybe my work can 
help fix that bug in the autocomplete scripts.


I know you don't use autocomplete for those things, but it comes in 
handy to me :)

> 
>> I guess Illumos shares this subsectioning scheme.
> 
> More or less, according to
> https://src.illumos.org/source/xref/illumos-gate/usr/src/man/ -
> it's not identical though.
> 
>> Do you know from the top of your head if any of those is dedicated to
>> constants such as NULL, PATH_MAX, or BUFSIZ?
> 
> I doubt it, for two reasons.  On the one hand, my impression is that
> at least in Solaris, section suffixes are not so much used for
> logical subdivision of sections but more according to provenance;
> for example, man1b is for BSD compat features, man1s is for commands
> specific to SunOS, man3c is for libc, man3ext is for an "extended
> library", man3p is for the Sun performance library (available for
> both C and FORTRAN 95), and so on.
> 
> On the other hand, naming manual pages after symbolic constants
> or after type names is so unsual that i doubt any scheme exists
> for that.

Actually, man3type exists in several systems.  Solaris has it (I guess 
Illumos too), and I've seen it in other systems (something from Oracle, 
IIRC).  libbsd(7) also documents types, although they put them in the 
global namespace, which I think you and I agree that it's not quite 
right because of "documentation about a non-function in man3".

>  The most widely used way to look up manual pages
> by the names of symbolic constants or type names probably is
> using macro keys as implemented in the mandoc version of apropos(1).
> That is used by most FreeBSD, OpenBSD, Alpine Linux, and Void Linux.
> I admit that doesn't qualify as "widely used", but "most widely used"
> is probably true all the same.  ;-)

That leaves out man(7).  And types tend to be not very well documented 
if they are documented as part of a function page.  And they also tend 
to be documented several times (out of sync, of course).


Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2022-07-24 11:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-19 17:52 Linux man-pages Makefile portability Alejandro Colomar
2022-06-19 21:06 ` Ingo Schwarze
2022-06-19 22:23   ` Alejandro Colomar
2022-06-20 13:49     ` Ingo Schwarze
2022-07-03 21:44       ` Alejandro Colomar
2022-07-21 14:17         ` Alejandro Colomar
2022-07-22 16:59           ` Ingo Schwarze
2022-07-22 17:37             ` Alejandro Colomar
2022-07-23 18:16               ` Ingo Schwarze
2022-07-24 11:09                 ` Alejandro Colomar (man-pages) [this message]
2022-07-24 15:57                   ` Ingo Schwarze
2022-07-24 17:29                     ` Semantic man(7) markup (was: Linux man-pages Makefile portability) G. Branden Robinson
2022-07-24 21:26                       ` Ingo Schwarze
2022-07-25  9:28                   ` Linux man-pages Makefile portability Colin Watson
2022-07-25 12:46                     ` bash-completion doesn't support man subsections (was: Linux man-pages Makefile portability) Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ff01b98c-563f-dfd3-4996-65ff5e5f44ce@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=cjwatson@debian.org \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=man-db-devel@nongnu.org \
    --cc=schwarze@usta.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).