/usr/local/share/man not in MANPATH
 

Self-compiled Tcl defaults to installing its man pages to /usr/local/share/man, but this directory is not in the MANPATH environment variable set by /etc/profile. Thus the Tcl documentation is not found.

However, /usr/local/share/man is in /etc/man.conf and /etc/man_db.conf (not sure why these are two separate files, but whatever). Therefore, all I have to do to get access to the self-compiled Tcl man pages is unset MANPATH and let the defaults kick in.

Why does /etc/profile set MANPATH? Why does it leave out some directories present in the man*.conf files?

Observation: /usr/lib64/java/man is in man_db.conf and the /etc/profile MANPATH but not man.conf. Unsetting MANPATH does not prevent "man javadoc" from working even though the underlying man page file is /usr/lib64/java/man/man1/javadoc.1. This adds to my confusion about why we have both man.conf and man_db.conf. Furthermore, man.conf says to read man.conf(5), but not such man page exists. Irony!

Foobar :banghead:

The only one of these files I have is /etc/man.conf. Thanks for looking up alternative names.

I've tried to minimize customizing my Slackware system aside from installing/upgrading packages since I want to be able to replicate my setup later without spending engineering hours tracking down every little tweak I've made by hand throughout the filesystem. Changes within ~ are fine of course, but I don't feel it's reasonable to ask every user to adjust their environment to overcome what appears to be an inconsistency in the base OS install.

In other news, I found there's a separate mandb program, which is why we have both man.conf and man_db.conf. I doubt I've ever used mandb, unless it's being invoked automatically.

Foobar :banghead:

Foobar :banghead:

Foobar :banghead:

I wonder where it came from. I installed Slackware64-14.2 then upgraded to Slackware64-current. At what point did man.conf disappear upstream?

ap/man-1.6g-x86_64-3.txz in Slackware64-14.2 contains /etc/man.conf.new. Slackware64-current doesn't have an ap/man package, rather ap/man-pages and ap/man-db. Neither package has man.conf. Also I'll note that 14.2 has package ap/man-pages but not ap/man-db.

At some point in my upgrade, presumably when jumping from 14.2 to current, the man package was uninstalled. Apparently its old man.conf was left behind. How are such things supposed to be identified and cleaned up when removing obsolete packages?

With MANPATH unset, I ran "strace -o log man -w n clock" to get the list of files being opened by man in its quest to locate the man pages. Sure enough, it reads /etc/man_db.conf, and it doesn't even look at /etc/man.conf. The latter file might as well not even exist, so I'll happily delete it.

Today, about five hours ago, Pat released a/etc-15.0-x86_64-7.txz which removes the MANPATH lines from /etc/profile and /etc/csh.login. This fixes my problem and lets /etc/man_db.conf prevail.

However, that's not to say I don't still have a MANPATH environment variable. It's being set by /etc/profile.d/jdk.{sh,csh} as follows:

This file isn't part of Slackware64. Rather, it came in jdk-8u172-x86_64-1_SBo. Perhaps the SlackBuilds script should be updated to patch out that one line since /usr/lib64/java/man is already present in man_db.conf. Without a MANPATH being set by /etc/profile, I end up with a MANPATH of ":/usr/lib64/java/man:/usr/lib64/java/man". (Yes, twice. Dunno why.) I'll contact Robby Workman about it, since it's his SlackBuilds script.

It's considered a config file, since it was moved over upon initial installation from the man.conf.new file. The package system won't remove existing config files even if the packages are removed.

I replied via email, but for those following along, I'll write it here too. SBo targets the latest stable Slackware release, so this won't be changed for now. You might get ponce's attention and see if he'll change it in his -current repo though.

pushed!