Hi Colin and Ingo, At 2025-05-05T11:50:10+0100, Colin Watson wrote: > FWIW, with man-db, it's usually best for most people not to set > MANPATH at all unless manual pages are somewhere that can't be > straightforwardly derived from PATH. man-db will normally work it out > based on PATH, and that way it's harder for them to get out of sync.
At 2025-05-05T17:41:48+0200, Ingo Schwarze wrote: > Actually, mandoc(1) does not really recommend setting MANPATH either. > > I consider it the job of the maintainer of the mandoc package on each > operating system to set MANPATH_DEFAULT to a value that is reasonable > for the operating system, as documented in configure.local.example. [...] > So even a highly specialized developer who spends about half his time > on manual page development barely needs MANPATH at all. The thought > that ordinary users might feel compelled to use it is rather > surprising. I can't be sure because I haven't kept my dot files under version control for sufficiently long, but I think I figured out why I've carried $MANPATH construction logic in my .bashrc for so long. About 18 years ago when taking a job at $FIRM, I had the option to be issued either an Intel-based Macintosh laptop (the choice of all the cool turtleneck kids) or one with a GNU/Linux distro officially supported by the firm's IT department...but it was an RPM-based distro. It might have been CentOS and not a fresh spin thereof. In other words the distro might have been so old that the man(1) in use was Brouwer/Lucifredi man, of which I did not have a high opinion. Having to manage my own $MANPATH was likely a major reason I was annoyed with it. But as I noted later in a groff commit message, that program "as of this writing [2020] saw its last release in 2011 (1.6g)." So thanks for the pointing the opportunity I can take to kick some cruft out of shell startup files. :) Regards, Branden
signature.asc
Description: PGP signature
