SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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!
bash $ strings /usr/bin/man | grep man.conf
/usr/lib/man.conf
/etc/man.conf
/etc/man.config
/usr/lib/man.config
/usr/share/misc/man.conf
/usr/share/misc/man.config
man-config.c: internal error: string %s not found
You may wanna check if you have a configuration file in "/usr/lib/" and if that maybe overrides the one in "/etc/". I don't know - I haven't looked at the man source code.
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.
If you have a clean installation you should not even have a "man.conf".
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:
Code:
export MANPATH="${MANPATH}:${JAVA_HOME}/man"
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.
I wonder where it came from. I installed Slackware64-14.2 then upgraded to Slackware64-current. At what point did man.conf disappear upstream?
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 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:
Code:
export MANPATH="${MANPATH}:${JAVA_HOME}/man"
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.