Date: Thu, 07 Mar 2024 02:16:12 +0000 From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 108980] list of missing man pages Message-ID: <bug-108980-9-vH7ju8xOfM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-108980-9@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=108980 Alexander Ziaee <concussious.bugzilla@runbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |concussious.bugzilla@runbox | |.com --- Comment #27 from Alexander Ziaee <concussious.bugzilla@runbox.com> --- Hmm... a lot of these missing manual pages are pages that a running, set-up system would have, they just don't come from src/share/man/*. I myself have contributed some of new ones deliberately, such as "see x(7), if installed", and even more flagrantly "see automount(8) or bsdisks(8)". I thought that was very nice, if you have files in /media/ you didn't create, one of those is creating them. One is in base and the other is pulled as a dependency by afaik every desktop environment. The FreeBSD manual concisely tells you everything you need to know. Is this incorrect? This concept also works... backwards, for example, we have manual pages that are built unconditionally describing parts of the system that MINIMAL wouldn't have, such as msdosfs(5). The synopsis says that you need to build it into your kernel, so if someone doesn't have it, and they look for it in the manual, they should know at first glance that... they could have it. I think this behavior is reasonable and massively more useful than the manual speaking authoratively as if the pages in src/share/man are all that exists. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-108980-9-vH7ju8xOfM>