Re: Altering the MANPATH in RPM
> > >is invoked from /opt/bin which then sets the environment > > >before launching the application from /opt/application/bin. > > > > > So add a man link farm as /opt/man to match those in > > /opt/bin > > > It does work, though migh not be pretty if you have > many man pages. > Also, I imagine that name space issues would occur quickly (i.e. man pages with the same name), which is one of the reason's one might decide to install their software in a different base directory. > I said it would be nice feature and wrote set of patches > to implement both features. It's no sour grapes from me > if it does not go mainstream, it was just proposal with > some code thought with no obligations. This happens a lot > in Linux community, code is written to show functionality, > some is used some isn't and I've become familiar with that > along years. > But just as a vote of confidence, this feature does exactly what I was looking for. It provides a fairly clean way to handle adding to the man search path in an additive way which is what most packages would want to do. Also, I have not checked it out yet, but I bet your change will allow any man.config directives in the man.config.d directory, which gives you some other flexebility. > But, that's ofcourse just my opinion and as if man is considered > perfect already there isn't much need to touch it further. > I am laughing! Its the best documentation system in the known universe; why its the flower of intelectual efforts (-; Cheers...james ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
> > > > >Some of the ways to work out environment for /opt > >applications are > > > > a) You add PATH, MANPATH, LD_LIBRARY_PATH etc to all > > > Handled by man by default with AUTOPATH so > MANPATH can be left alone. Just fix PATH > Again, this is only handled if your files you have man pages for are executables. If they are executables this is good aproach albeit not necessarily intuitive. > > >One very important thing that I have learned past years, > >"One size fits for all" does not work for all for all > >and it's very good to have options how to set up software. > > > >IMO, the man.config.d and MANPATH globbing serves b) and > >c) very well :) > > > The man.config.d idea is nice. But solutions already exist. > The question related to a way for RPM to do this. > > The solution is if RPM installs executables in > then put manpages in either /man/man* or > in /../man/man*, and either drops something into > /etc/profile.d (prefered) or the users add to > their login scripts. > Well, it does not work, because once you set MANPATH the config file is ignored, per the docs. > This works with man on recent linux distributions > like Red Hat 7+ at least, probably older ones. > It does not work on RH 7.2 for sure if you wish to maintain the existing /etc/man.config setup, and add your stuff to it. Your right /etc/profile.d is a good place to drop things that modify global environment variables, but the problem here is modifying the global variable will destroy the existing setup (well at least make it ignored). Gaining your packages manpages while losing the system ones will cause loss of hapiness in unsuspecting sys-admins quickly. /etc/man.config.d and the globbing solutions, and some extra flexability that that can easily be used as an RPM package best practice (that would be a nice document (-; ). Cheers...james > -Thomas > > > > > ___ > Redhat-devel-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
On Tue, 30 Apr 2002, Thomas Dodd wrote: > Riku Meskanen wrote: > > a) You add PATH, MANPATH, LD_LIBRARY_PATH etc to all > > > Handled by man by default with AUTOPATH so > MANPATH can be left alone. Just fix PATH > Yes I hear you. You explained it already on your first post, no offence but no need to keep repeating just for me :) > > > > b) You create and maintain shell function or aliases > > > This could also add MANPATH at import time. > Practically, you can't read man page before you import environment. This can be good or bad depending your stance. > > c) You set up link- and/or shellscript farm to /opt/bin > >which is only /opt entry included in PATH variable. > >When user references the applicatinon the shell script, > >is invoked from /opt/bin which then sets the environment > >before launching the application from /opt/application/bin. > > > So add a man link farm as /opt/man to match those in > /opt/bin > It does work, though migh not be pretty if you have many man pages. > The man.config.d idea is nice. But solutions already exist. > The question related to a way for RPM to do this. > > The solution is if RPM installs executables in > then put manpages in either /man/man* or > in /../man/man*, and either drops something into > /etc/profile.d (prefered) or the users add to > their login scripts. > Which provides support for only the a) option with it's downsides explained earlier. > This works with man on recent linux distributions > like Red Hat 7+ at least, probably older ones. > Yes, profile.d has been around for a while, been using it from the beginning. You came clear that you don't like the feature, and you are free to do that as is anyone else. I said it would be nice feature and wrote set of patches to implement both features. It's no sour grapes from me if it does not go mainstream, it was just proposal with some code thought with no obligations. This happens a lot in Linux community, code is written to show functionality, some is used some isn't and I've become familiar with that along years. Anyway it's not in my hands any more if it will be used, though just if you consider it plain bloat and increase of binary size, it will increase the stripped binary size 2216 bytes which is about 1396 less than the statically linked RMS glob.o (unstripped object file 3612 bytes) takes in there, that could be replaced with few lines of code and call to libc. But, that's ofcourse just my opinion and as if man is considered perfect already there isn't much need to touch it further. Cheers, :-) riku -- [ This .signature intentionally left blank ] ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
Riku Meskanen wrote: >On Mon, 29 Apr 2002, Thomas Dodd wrote: > >>So the package needs to drop a file in /etc/profile.d >>that sets the executable path to /opt/foo/bin >>and man will aututomatically add /opt/foo/man >>to the MANPATH. It will also look for /opt/foo/bin/man >>if you don't want seperate bin and man dirs for each package. >> >>I losty the exact layout you wanted to use, but I think these >>options should do what you need. >> >I agree, provided that you have the PATH included >all applications bin directories there, but that's >unfortunately the weak point too because you don't >have PATH populated with all software you have insalled. > >As you build a servers of your own or work on some that >someone else has built you may find that there are few >options how to set up software. Some styles are simple, >some not but work better when you have lot of software. > >Some of the ways to work out environment for /opt >applications are > > a) You add PATH, MANPATH, LD_LIBRARY_PATH etc to all > Handled by man by default with AUTOPATH so MANPATH can be left alone. Just fix PATH > > b) You create and maintain shell function or aliases > This could also add MANPATH at import time. > c) You set up link- and/or shellscript farm to /opt/bin >which is only /opt entry included in PATH variable. >When user references the applicatinon the shell script, >is invoked from /opt/bin which then sets the environment >before launching the application from /opt/application/bin. > So add a man link farm as /opt/man to match those in /opt/bin >One very important thing that I have learned past years, >"One size fits for all" does not work for all for all >and it's very good to have options how to set up software. > >IMO, the man.config.d and MANPATH globbing serves b) and >c) very well :) > The man.config.d idea is nice. But solutions already exist. The question related to a way for RPM to do this. The solution is if RPM installs executables in then put manpages in either /man/man* or in /../man/man*, and either drops something into /etc/profile.d (prefered) or the users add to their login scripts. This works with man on recent linux distributions like Red Hat 7+ at least, probably older ones. -Thomas ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
On Mon, 29 Apr 2002, Thomas Dodd wrote: > > So the package needs to drop a file in /etc/profile.d > that sets the executable path to /opt/foo/bin > and man will aututomatically add /opt/foo/man > to the MANPATH. It will also look for /opt/foo/bin/man > if you don't want seperate bin and man dirs for each package. > > I losty the exact layout you wanted to use, but I think these > options should do what you need. > I agree, provided that you have the PATH included all applications bin directories there, but that's unfortunately the weak point too because you don't have PATH populated with all software you have insalled. As you build a servers of your own or work on some that someone else has built you may find that there are few options how to set up software. Some styles are simple, some not but work better when you have lot of software. Some of the ways to work out environment for /opt applications are a) You add PATH, MANPATH, LD_LIBRARY_PATH etc to all users environment from profile or login scripts - Very straightforward to implement, but pollutes environment for the all users ie. hard to keep applications environments separate ... and does not scale well on large environments, requires definitions for each shell supported separately. Works nice environments with not too much different aged applications. As Linux matures more you will see more need to support old aplications too. b) You create and maintain shell function or aliases that user has to enter some specified command to 'import' (source) the proper environment before using application. - Takes some effort to set up, good applications separation -- scales well, but needs quite a bit work maintaining all the functions and aliases per each shell which then include desired environment for the user. Works relatively well where admins do know shell script programming, otherwise it's a pain. c) You set up link- and/or shellscript farm to /opt/bin which is only /opt entry included in PATH variable. When user references the applicatinon the shell script, is invoked from /opt/bin which then sets the environment before launching the application from /opt/application/bin. - scales well, takes some less effort to maintain than b), does not pollute user environment like a) and application environment separation works quite well. The bad point here is that if the application is formed from large number of small executables, you need a wrapper around each. Works quite well once the startup shell scripts have been created by someone understanding the workings of the applications -- a consultant or in-house admin, or the like. Which of the a) is propably most commonly used. The b) and c) are commonly used in large up to supercomputer class environments, a) does not scale well and will lead to very hard to maintain and debug system if problems arise subtly by the time. With c) individual /opt/*/man entries usually need to be added to MANPATH. One very important thing that I have learned past years, "One size fits for all" does not work for all for all and it's very good to have options how to set up software. IMO, the man.config.d and MANPATH globbing serves b) and c) very well :) HTH, :-) riku -- [ This .signature intentionally left blank ] ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
> > > > James Olin Oden wrote: > > ><- SNIP -> > > I like the man.config.d idea, but I think gnu-man has a solution already > in place. > > In the man(1) page MANPATH_MAP and the NOAUTOPATH control the > automatic construction of MANPATH. > > if NOAUTOPATH is not set in /etc/man.config then it can be autocreated. > > so If PATH=/opt/foo/bin > man will auto search /opt/foo/man > > I just tested this with man-1.5j-6 (in skipjack) > and /etc/man.config is the Red Hat default. > > So the package needs to drop a file in /etc/profile.d > that sets the executable path to /opt/foo/bin > and man will aututomatically add /opt/foo/man > to the MANPATH. It will also look for /opt/foo/bin/man > if you don't want seperate bin and man dirs for each package. > > I losty the exact layout you wanted to use, but I think these > options should do what you need. > Its very close, but if I understood MANPATH_MAP correctly it only works for directories you put in your path. So this does not work for man pages for libraries and such. man.config.d solution solves this problem. Cheers...james > -Thomas > > > > > ___ > Redhat-devel-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
James Olin Oden wrote: ><- SNIP -> > >>IMHO, best way I can think would be to enhance GNU man to >>support include directory, like xinetd with /etc/xinetd.d, >>logrotate with /etc/logrotate.d etc. >> >>Thus patch it use /etc/man.config.d if it already doesn't >>and contrib to project :) >> I like the man.config.d idea, but I think gnu-man has a solution already in place. In the man(1) page MANPATH_MAP and the NOAUTOPATH control the automatic construction of MANPATH. if NOAUTOPATH is not set in /etc/man.config then it can be autocreated. so If PATH=/opt/foo/bin man will auto search /opt/foo/man I just tested this with man-1.5j-6 (in skipjack) and /etc/man.config is the Red Hat default. So the package needs to drop a file in /etc/profile.d that sets the executable path to /opt/foo/bin and man will aututomatically add /opt/foo/man to the MANPATH. It will also look for /opt/foo/bin/man if you don't want seperate bin and man dirs for each package. I losty the exact layout you wanted to use, but I think these options should do what you need. -Thomas ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: glob'in the MANPATH (Was: Altering the MANPATH in RPM)
On Mon, 29 Apr 2002, James Olin Oden wrote: > > I was first thinking making these better configurable options, > > but the package does not use recent autoconfigure, so I simply > > made patches active by default. NOCONFIGD and NOGLOB can > > consequtively disable the features if not desired. > > > I would think that that is something that the gnu man mainteners could > get perfect if they want. Also, if I understand you right NOCONFIGD and > NOGLOB are config file directives, so that is easy enough for someone to > turn off. Also, its the kind of feature that unless you use it intentionally > it won't be activated (i.e. no globbing will occur until a path contains > a glob char). > No, actually NOCONFIGD and NOGLOB are c-preprosessor directives, thus directives have meanin only at build time. I don't think this is major drawback or is it? Should it really be configurable by the man config file? Not that it would be hard to add, but is there really need? I'm basing my point to it's _the distributor_ that should decide wether they like other packages touch the main config or support config directory... if the distributor does not compile in the support, then there is no use admin adding that directive later to main config and if the distributor has activated the support then if admin disables using the directive then he breaks the other packages, right? :-) riku -- [ This .signature intentionally left blank ] ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: glob'in the MANPATH (Was: Altering the MANPATH in RPM)
>
> On Sat, 27 Apr 2002, Riku Meskanen wrote:
> >
> Ok, spent some more time on it and it config directory is
> now fully functional with relevant IMHO security checks etc.
>
Thanks Riku. I will download them today and try them out. Also,
as soon as I get a chance I will closely examine your patch. I have
to go through an annoying surgery tommorow, so I won't be able to
look at it for a few weeks, but again I very glad you saw fit to
do this. I was considering doing it myself after talking with you,
but you acted much quicker than. KUDOs!
> RPM will add /etc/man.config.d (relative to your man config
> ofcourse) directory were the another package can add easily
> it's own foo.conf and declare required MANPATH there.
>
> Check http://people.jyu.fi/~mesrik/tmp/man the 'release' 8 has
> it built in and diffs follows, if you prefer those.
>
> I was first thinking making these better configurable options,
> but the package does not use recent autoconfigure, so I simply
> made patches active by default. NOCONFIGD and NOGLOB can
> consequtively disable the features if not desired.
>
I would think that that is something that the gnu man mainteners could
get perfect if they want. Also, if I understand you right NOCONFIGD and
NOGLOB are config file directives, so that is easy enough for someone to
turn off. Also, its the kind of feature that unless you use it intentionally
it won't be activated (i.e. no globbing will occur until a path contains
a glob char).
Cheers...james
> I would appreciate if Bero and Aeb give glimpse to these
> patches, please. They sure are worth that :)
>
> HTH,
>
> :-) riku
>
> ps. anybody knows why this man package still uses internal
> glob package that RMS wrote ages ago? It shouldn't be
> much work rewriting that one function to use system wide
> glob ...
>
> --- man-1.5j/src/man-config.c.distFri Apr 26 20:23:21 2002
> +++ man-1.5j/src/man-config.c Fri Apr 26 23:06:48 2002
> @@ -19,6 +19,14 @@
> #include
> #include
>
> +#ifndef NOGLOB
> +/* Can't refer to system as long as there is local glob.h
> + on this same directory. Is that really needed any more or would
> + it be better replace glob_filename() with few lines of code and
> + call to glob from libc ? -- [EMAIL PROTECTED] */
> +#include "/usr/include/glob.h"
> +#endif
> +
> #include "defs.h"
> #include "man-config.h"
> #include "man.h"
> @@ -201,7 +209,10 @@
> char *p;
> char buf[BUFSIZE];
> FILE *config = NULL;
> -
> +#ifndef NOGLOB
> + glob_t gs;
> + char**gp;
> +#endif
> if (cf) {
> /* User explicitly specified a config file */
> if ((config = fopen (cf, "r")) == NULL) {
> @@ -249,9 +260,24 @@
>
> if (!strncmp ("MANPATH_MAP", bp, 11))
> adddir (bp+11, 0);
> - else if (!strncmp ("MANPATH", bp, 7))
> + else if (!strncmp ("MANPATH", bp, 7)) {
> +#ifndef NOGLOB
> +/* config glob manpath support - [EMAIL PROTECTED] */
> +p = bp+7;
> +while (whitespace(*p))
> + p++;
> +if (!glob(p,0,NULL,&gs)) {
> + for (gp = gs.gl_pathv; *gp; gp++) {
> + adddir (*gp, 1);
> + }
> +} else {
> + adddir(bp+7,1);
> +}
> +globfree(&gs);
> +#else
> adddir (bp+7, 1);
> - else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible */
> +#endif
> + } else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible
>*/
> adddir (bp+17, 1);
> else if (!strncmp ("FHS", bp, 3))
> fhs = 1;
> --- man-1.5j/src/man.conf.in.diff Fri Apr 26 23:33:46 2002
> +++ man-1.5j/src/man.conf.in Fri Apr 26 23:34:13 2002
> @@ -40,6 +40,7 @@
> MANPATH /usr/X11R6/man
> MANPATH /usr/local/man
> MANPATH /usr/kerberos/man
> +MANPATH /opt/*/man
> MANPATH /usr/man
> #
> # Uncomment if you want to include one of these by default
>
> --- man-1.5j/src/man-config.c.distSat Apr 27 15:56:34 2002
> +++ man-1.5j/src/man-config.c Sat Apr 27 15:57:43 2002
> @@ -26,6 +26,13 @@
> call to glob from libc ? -- [EMAIL PROTECTED] */
> #include "/usr/include/glob.h"
> #endif
> +#ifndef NOCONFIGD
> +#include
> +#include
> +#include
> +#include
> +char *manconfigd = NULL; /* global used to pass possible config include dir */
> +#endif
>
> #include "defs.h"
> #include "man-config.h"
> @@ -213,6 +220,11 @@
> glob_t gs;
> char**gp;
> #endif
> +#ifndef NOCONFIGD
> + char*dn = NULL;
> + char*fn = NULL;
> + struct stat ds;
> +#endif
> if (cf) {
> /* User explicitly specified a config file */
> if ((config = fopen (cf, "r")) == NULL) {
> @@ -235,6 +247,31 @@
> gripe (CONFIG_OPEN_ERROR, CONFIG_FILE);
> return;
> }
> +#ifndef NOCONFIGD
> + /* build config dir and check that it us o
Re: glob'in the MANPATH (Was: Altering the MANPATH in RPM)
On Sat, 27 Apr 2002, Riku Meskanen wrote:
>
> I'm still thinking /etc/man.config.d/ support possibilities.
>
> As the /etc/man.config is just flat config with really no
> really need stacked options or anything and the /etc/man.config.d/
> could be achieved simply modifying read_config_file() to traverse
> the directory and include all configs. Will possibly look it further
> later, if someone else does not like to implement it.
>
> BTW The ready made RPMs with glob support for test can be found
> from http://people.jyu.fi/~mesrik/tmp/man/
>
Ok, spent some more time on it and it config directory is
now fully functional with relevant IMHO security checks etc.
RPM will add /etc/man.config.d (relative to your man config
ofcourse) directory were the another package can add easily
it's own foo.conf and declare required MANPATH there.
Check http://people.jyu.fi/~mesrik/tmp/man the 'release' 8 has
it built in and diffs follows, if you prefer those.
I was first thinking making these better configurable options,
but the package does not use recent autoconfigure, so I simply
made patches active by default. NOCONFIGD and NOGLOB can
consequtively disable the features if not desired.
I would appreciate if Bero and Aeb give glimpse to these
patches, please. They sure are worth that :)
HTH,
:-) riku
ps. anybody knows why this man package still uses internal
glob package that RMS wrote ages ago? It shouldn't be
much work rewriting that one function to use system wide
glob ...
--- man-1.5j/src/man-config.c.dist Fri Apr 26 20:23:21 2002
+++ man-1.5j/src/man-config.c Fri Apr 26 23:06:48 2002
@@ -19,6 +19,14 @@
#include
#include
+#ifndef NOGLOB
+/* Can't refer to system as long as there is local glob.h
+ on this same directory. Is that really needed any more or would
+ it be better replace glob_filename() with few lines of code and
+ call to glob from libc ? -- [EMAIL PROTECTED] */
+#include "/usr/include/glob.h"
+#endif
+
#include "defs.h"
#include "man-config.h"
#include "man.h"
@@ -201,7 +209,10 @@
char *p;
char buf[BUFSIZE];
FILE *config = NULL;
-
+#ifndef NOGLOB
+ glob_t gs;
+ char**gp;
+#endif
if (cf) {
/* User explicitly specified a config file */
if ((config = fopen (cf, "r")) == NULL) {
@@ -249,9 +260,24 @@
if (!strncmp ("MANPATH_MAP", bp, 11))
adddir (bp+11, 0);
- else if (!strncmp ("MANPATH", bp, 7))
+ else if (!strncmp ("MANPATH", bp, 7)) {
+#ifndef NOGLOB
+ /* config glob manpath support - [EMAIL PROTECTED] */
+ p = bp+7;
+ while (whitespace(*p))
+p++;
+ if (!glob(p,0,NULL,&gs)) {
+for (gp = gs.gl_pathv; *gp; gp++) {
+ adddir (*gp, 1);
+}
+ } else {
+adddir(bp+7,1);
+ }
+ globfree(&gs);
+#else
adddir (bp+7, 1);
- else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible */
+#endif
+ } else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible */
adddir (bp+17, 1);
else if (!strncmp ("FHS", bp, 3))
fhs = 1;
--- man-1.5j/src/man.conf.in.diff Fri Apr 26 23:33:46 2002
+++ man-1.5j/src/man.conf.inFri Apr 26 23:34:13 2002
@@ -40,6 +40,7 @@
MANPATH/usr/X11R6/man
MANPATH/usr/local/man
MANPATH /usr/kerberos/man
+MANPATH /opt/*/man
MANPATH/usr/man
#
# Uncomment if you want to include one of these by default
--- man-1.5j/src/man-config.c.dist Sat Apr 27 15:56:34 2002
+++ man-1.5j/src/man-config.c Sat Apr 27 15:57:43 2002
@@ -26,6 +26,13 @@
call to glob from libc ? -- [EMAIL PROTECTED] */
#include "/usr/include/glob.h"
#endif
+#ifndef NOCONFIGD
+#include
+#include
+#include
+#include
+char *manconfigd = NULL; /* global used to pass possible config include dir */
+#endif
#include "defs.h"
#include "man-config.h"
@@ -213,6 +220,11 @@
glob_t gs;
char**gp;
#endif
+#ifndef NOCONFIGD
+ char*dn = NULL;
+ char*fn = NULL;
+ struct stat ds;
+#endif
if (cf) {
/* User explicitly specified a config file */
if ((config = fopen (cf, "r")) == NULL) {
@@ -235,6 +247,31 @@
gripe (CONFIG_OPEN_ERROR, CONFIG_FILE);
return;
}
+#ifndef NOCONFIGD
+ /* build config dir and check that it us owned by root, in
+root group and group and others must not have write perms
+-- [EMAIL PROTECTED] */
+ dn = dirname(strdup(cf));
+ fn = basename(strdup(cf));
+ realloc(dn,strlen(dn)+strlen(fn)+5);
+ strcat(dn,"/");
+ strcat(dn,fn);
+ strcat(dn,".d");
+ if (!stat(dn,&ds) &&
+ S_ISDIR(ds.st_mode) &&
+ (ds.st_uid == 0) &&
+ (ds.st_gid == 0
glob'in the MANPATH (Was: Altering the MANPATH in RPM)
On Fri, 26 Apr 2002, James Olin Oden wrote:
> > I'm often more on design than a straight forward solution,
> > but you are right GNU man does not support /opt/*/man well,
> > hey that could be another way, enhance the GNU man to support
> > wildcards with glob() ... something like this
> >
> I like that idea also. If it is a security problem in a particular
> environment, it could be turned off. Really, it could be turned off by
> default, and then if someone needed it it could be turned on. For
> packagers thought the /etc/man.config.d would probably be for the best, but
> for a sysamdin the globbing approach would probably be best.
>
MANPATH globbing is also very easy to implement, actually so simple
I did it already :)
I'm still thinking /etc/man.config.d/ support possibilities.
As the /etc/man.config is just flat config with really no
really need stacked options or anything and the /etc/man.config.d/
could be achieved simply modifying read_config_file() to traverse
the directory and include all configs. Will possibly look it further
later, if someone else does not like to implement it.
BTW The ready made RPMs with glob support for test can be found
from http://people.jyu.fi/~mesrik/tmp/man/
I think the glob feature with MANPATH at /etc/man.config is useful,
and suggest that it would be worth merging it to main tree.
HTH,
:-) riku
--- man-1.5j/src/man-config.c.dist Fri Apr 26 20:23:21 2002
+++ man-1.5j/src/man-config.c Fri Apr 26 23:06:48 2002
@@ -19,6 +19,14 @@
#include
#include
+#ifndef NOGLOB
+/* Can't refer to system as long as there is local glob.h
+ on this same directory. Is that really needed any more or would
+ it be better replace glob_filename() with few lines of code and
+ call to glob from libc ? -- [EMAIL PROTECTED] */
+#include "/usr/include/glob.h"
+#endif
+
#include "defs.h"
#include "man-config.h"
#include "man.h"
@@ -201,7 +209,10 @@
char *p;
char buf[BUFSIZE];
FILE *config = NULL;
-
+#ifndef NOGLOB
+ glob_t gs;
+ char**gp;
+#endif
if (cf) {
/* User explicitly specified a config file */
if ((config = fopen (cf, "r")) == NULL) {
@@ -249,9 +260,24 @@
if (!strncmp ("MANPATH_MAP", bp, 11))
adddir (bp+11, 0);
- else if (!strncmp ("MANPATH", bp, 7))
+ else if (!strncmp ("MANPATH", bp, 7)) {
+#ifndef NOGLOB
+ /* config glob manpath support - [EMAIL PROTECTED] */
+ p = bp+7;
+ while (whitespace(*p))
+p++;
+ if (!glob(p,0,NULL,&gs)) {
+for (gp = gs.gl_pathv; *gp; gp++) {
+ adddir (*gp, 1);
+}
+ } else {
+adddir(bp+7,1);
+ }
+ globfree(&gs);
+#else
adddir (bp+7, 1);
- else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible */
+#endif
+ } else if(!strncmp ("MANDATORY_MANPATH", bp, 17))/* backwards compatible */
adddir (bp+17, 1);
else if (!strncmp ("FHS", bp, 3))
fhs = 1;
--- man-1.5j/src/man.conf.in.diff Fri Apr 26 23:33:46 2002
+++ man-1.5j/src/man.conf.inFri Apr 26 23:34:13 2002
@@ -40,6 +40,7 @@
MANPATH/usr/X11R6/man
MANPATH/usr/local/man
MANPATH /usr/kerberos/man
+MANPATH /opt/*/man
MANPATH/usr/man
#
# Uncomment if you want to include one of these by default
--- man.spec.dist Fri Apr 26 23:51:42 2002
+++ man.specFri Apr 26 23:15:55 2002
@@ -5,7 +5,7 @@
Summary: A set of documentation tools: man, apropos and whatis.
Name: man
Version: 1.5j
-Release: 6
+Release: 7
License: GPL
Group: System Environment/Base
Source0: ftp://ftp.win.tue.nl/pub/linux-local/utils/man/man-%{version}.tar.bz2
@@ -32,6 +32,7 @@
Patch24: man-1.5i2-initial.patch
Patch25: man-1.5i2-legacy.patch
Patch26: man-1.5j-sanitycheck.patch
+Patch27: man-1.5j-globfeat.patch
# Japanese patches
Patch51: man-1.5h1-gencat.patch
@@ -84,7 +85,7 @@
%endif
%patch26 -p1 -b .sanitycheck
-
+%patch27 -p1 -b .globfeat
#rm -f $RPM_BUILD_DIR/man-%{version}/man/en/man.conf.man
find $RPM_BUILD_DIR/man-%{version} -type f|xargs perl -pi -e
's,man\.conf\(5\),man.config(5),g'
@@ -227,6 +228,10 @@
%attr(0775,root,man) %dir %{cache}/X11R6/cat[123456789n]
%changelog
+* Fri Apr 26 2002 Riku Meskanen <[EMAIL PROTECTED]>
+- Added glob() to man.config MANPATH for supporting easier /opt
+ deployment, feature simplifies setting MANPATH /opt/*/man
+
* Mon Mar 25 2002 Bernhard Rosenkraenzer <[EMAIL PROTECTED]> 1.5j-6
- Fix bugs #60676 and #61105
- Add /usr/local/man and /usr/X11R6/man to makewhatis default paths
--
[ This .signature intentionally left blank ]
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
<- SNIP -> > IMHO, best way I can think would be to enhance GNU man to > support include directory, like xinetd with /etc/xinetd.d, > logrotate with /etc/logrotate.d etc. > > Thus patch it use /etc/man.config.d if it already doesn't > and contrib to project :) > Actually, I do think that idea is better now that I think about, 'cause what I was suggesting was really a distribution level hack/workaround to a problem endemic to gnuman. I think I have achieved what I sent the original email...better insight than my own. > > > esac > > > > > Nice code, but it assumes that you know what should be on the system before > > you alter things (at least thast was my cursory reading). At best you could > > get it tuned to a particular release of a distribution, but as soon as the > > maintaineers of the distribution alter man.config or the sysadmin does > > all bets are off. > > > > See my suggestion of /etc/man.config.d above. > > The code was just simple example how to edit PATH style > variables preserving portability. Not 1:1 solution to > your answer. Sorry if I wasn't clear on it. > I understand now. > I'm often more on design than a straight forward solution, > but you are right GNU man does not support /opt/*/man well, > hey that could be another way, enhance the GNU man to support > wildcards with glob() ... something like this > I like that idea also. If it is a security problem in a particular environment, it could be turned off. Really, it could be turned off by default, and then if someone needed it it could be turned on. For packagers thought the /etc/man.config.d would probably be for the best, but for a sysamdin the globbing approach would probably be best. <- SNIP -> > Right OT, but the HP-UX root shell is a /sbin/sh, which is > *statically linked* POSIX shell, I don't see any problem > with that :) > > The /bin/sh is the dynamically linked POSIX shell like the > /usr/bin/ksh (Version M-11/16/88i) is the Korn 88 shell, > and /usr/dt/bin/dtksh (Version M-12/28/93d) aka Korn 93 > shell. > > I just wish that Sun would follow HP and replace /sbin/sh > with *real* POSIX compatible shell on Solaris 9, another So do I! Heck, I would even be satisfied with ksh (which supports the [[ ]], but better yet it suports $( command ), and $(( expr )) math. Or just make it bash (-; Cheers...james ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
On Fri, 26 Apr 2002, Riku Meskanen wrote: > > Don't think GNU man is not SUID-root or SGID-man any > recent distribution or is it? > Sorry my goof, I should learn rereading before submitting :/ Drop the *not* and it becomes clear what I was trying to say, thus | I don't think GNU man is SUID-root or SGID-man any recent distribution | or is it?" :-) riku -- [ This .signature intentionally left blank ] ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
On Thu, 25 Apr 2002, James Olin Oden wrote:
> >
> > On Thu, 25 Apr 2002, James Olin Oden wrote:
> > >
> > The /opt/package/{etc,bin,man} practise can lead to quite riducule
> > length with PATH, MANPATH etc. components when you have plenty
> > of softare in your system, so beware.
> >
> Agreed, but there are times when you don't want your stuff to go in the
> same place as a distributions stuff, if only to keep a serperate "namespace"
> for your applications.
>
Exactly, the three separate domains; system distribution,
third party and local stuff should all be kept separate.
See http://www.pathname.com/fsh/ unless you haven't yet.
My point is that some care should be taken with
deploying /opt too, it's no panacea per se.
I've done quite large NMS setup with HP-UX and Solaris,
(set up NOC for large a telecom from ground up) and seen
what kind of problems /opt, /etc/opt, /var/opt scheme can
lead with shared volumes on a cluster. No fun, seriously.
But the largest problem with Red Hat & RPM system usage I see
is that most third party packages (contribs etc) still goes
under system distribution filespace, usually at /usr :(
Somehow the usage of /opt seem to be either too difficult or
unknown to many.
I don't know what would be best way promoting /opt use to
packagers, possibly some kind of consistency check-tool from
system distributor that would check wether the system and
package is tainted unless it follows FHS.
The tool would simply verify that package signature matches on
system distributor signature and if not it would check if it does
have files placed proper places or not.
Dunno, someone else has better idea?
The best point of keeping things separate is that it
provides best means for planning the disk usage for
long term and not running in to the large problems with
patches and upgrades in future.
LVM will ofcourse help you with that, but will cause some
suffling and juggling unless you have spare extents and need
to resize existing partitions. Here LVM is no solution, it's
just nice workaround for the problem, the real problem still
persists and will bite you later :/
> > Most common problems I have met are:
> >
> > - when reinstalling you often have duplicate paths added.
> >
> > - I've met many times // had been added there.
> >
> > - does not provide means of checking first that the
> >filesystem is mounted before reference to path is added
> >
> > This was just to point that the HP-UX practis IMHO is far
> > from ideal.
> >
> Sure, and that is why I was suggesting some sort of distribution tool
> to help handle this. In this way the packager does not right his or her
> own possbibly buggy tool handle this, but the maintner of the distribution
> provides a utility that handles this bug free (OK I'm dreaming).
>
Sure you are dreaming ;)
The same problem exist with *many* files especially under /etc,
think /etc/services, /etc/rpc, etc. xinetd has made life little
easier than it was with /etc/inetd.conf though.
> > I don't think you need that stuff at all ...
> >
> > I'd prefer this stuff done at /etc/profile.d/ with appropriate
> > scripts, those are executed after login.
> >
> I would prefere this too, but after re-reading the gnu man.config and man
> man pages, and the comments in /etc/man.config, I am positive that the
> behaviour you get from the man is if the MANPATH is set (which you would do
> in a /etc/profile.d script) it will ignore man.config. I do not want
> /etc/man.config ignored. I want to inherit the good work at RedHat, not
> go on my own. If on the other hand one in their RPM (because profile.d
> will not get you there) edits the /etc/man.config file you run into the
> same issues you mentioned with programs on HP that each on their own
> (rather than through a distribution supplied program) edit the MANPATH
> file.
>
IMHO, best way I can think would be to enhance GNU man to
support include directory, like xinetd with /etc/xinetd.d,
logrotate with /etc/logrotate.d etc.
Thus patch it use /etc/man.config.d if it already doesn't
and contrib to project :)
> > esac
> >
> Nice code, but it assumes that you know what should be on the system before
> you alter things (at least thast was my cursory reading). At best you could
> get it tuned to a particular release of a distribution, but as soon as the
> maintaineers of the distribution alter man.config or the sysadmin does
> all bets are off.
>
See my suggestion of /etc/man.config.d above.
The code was just simple example how to edit PATH style
variables preserving portability. Not 1:1 solution to
your answer. Sorry if I wasn't clear on it.
I'm often more on design than a straight forward solution,
but you are right GNU man does not support /opt/*/man well,
hey that could be another way, enhance the GNU man to support
wildcards with glob() ... something like this
$ cat
Re: Altering the MANPATH in RPM
>
> On Thu, 25 Apr 2002, James Olin Oden wrote:
> >
> The /opt/package/{etc,bin,man} practise can lead to quite riducule
> length with PATH, MANPATH etc. components when you have plenty
> of softare in your system, so beware.
>
Agreed, but there are times when you don't want your stuff to go in the
same place as a distributions stuff, if only to keep a serperate "namespace"
for your applications.
> The second problem with /etc/MANPATH and /etc/PATH with
> HP-UX is that fairly many especially third-party vendor
> packages (depots) that I have seen screwed up badly while
> editing those files, even packages from some HP departments
> have had these problems (ever tried JetDirect and HPNP packages?).
> Most common problems I have met are:
>
> - when reinstalling you often have duplicate paths added.
>
> - I've met many times // had been added there.
>
> - does not provide means of checking first that the
>filesystem is mounted before reference to path is added
>
> This was just to point that the HP-UX practis IMHO is far
> from ideal.
>
Sure, and that is why I was suggesting some sort of distribution tool
to help handle this. In this way the packager does not right his or her
own possbibly buggy tool handle this, but the maintner of the distribution
provides a utility that handles this bug free (OK I'm dreaming).
> > one to add a MANPATH statement to the man.config. This thing command would
> > be fully aware of the man.config syntax, so that it could:
> >
> > - add the MANPATH in clean way.
> > - make sure that it had not already been added.
> >
> I don't think you need that stuff at all ...
>
> I'd prefer this stuff done at /etc/profile.d/ with appropriate
> scripts, those are executed after login.
>
I would prefere this too, but after re-reading the gnu man.config and man
man pages, and the comments in /etc/man.config, I am positive that the
behaviour you get from the man is if the MANPATH is set (which you would do
in a /etc/profile.d script) it will ignore man.config. I do not want
/etc/man.config ignored. I want to inherit the good work at RedHat, not
go on my own. If on the other hand one in their RPM (because profile.d
will not get you there) edits the /etc/man.config file you run into the
same issues you mentioned with programs on HP that each on their own
(rather than through a distribution supplied program) edit the MANPATH
file.
> Let's say I have /etc/profile.d/localpath.sh
>
> # strip 'local' PATH components
> IFS=":"; NPATH=""
> for i in $PATH ; do
> case $i in
> /usr/local/bin|\
> /usr/local/sbin|\
> /usr/sbin|\
> /sbin) # strip these first, add again later
> ;;
> *) # store rest to NPATH, if they exist
> if [ -d "$i" ]; then
> if [ -z "$NPATH" ]; then
> NPATH="$i"
>else
> NPATH="$NPATH:$i"
>fi
> fi
> ;;
> esac
> done
> IFS="
> "
> export IFS
>
> # prepend local path to ordinary users, set TMOUT to root
> case $LOGNAME in
> root) PATH="/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:$NPATH"
> if [ -t ]; then
> TMOUT=600
> fi
> export PATH TMOUT
> ;;
>*) PATH="/usr/local/bin:$NPATH"
> export PATH
> ;;
> esac
>
Nice code, but it assumes that you know what should be on the system before
you alter things (at least thast was my cursory reading). At best you could
get it tuned to a particular release of a distribution, but as soon as the
maintaineers of the distribution alter man.config or the sysadmin does
all bets are off.
> You can traverse nicely the PATH with setting the shell
> field separatore (IFS) to : and then later construct new
> variable later. A nice and portable way too :)
Again, I agree its nice code (OK its very clean wonderful code (-:) but
it does not solve the problem.
>
> You should always remember to think that when runing commands via
> ssh (rsh) from remote machine too, hence the -t test for control-
> ling tty is very important!
>
Sure.
>
> It's shame that all Unix vendors have not yet
> picked setting the POSIX shell for root, it
> would make our lives much easier :|
>
Of topic, but yeah I agree. You know the only problem is you could use
the other shells, but Sun only provides sh statically linked (and in
a bad situation that is _so_ very important.
Cheers...james
___
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
On Thu, 25 Apr 2002, James Olin Oden wrote:
> I guess since know one has responded to this question concerning a
> clean way for an RPM to alter the MANPATH (i.e. alter it non-destructively
> and using a safe mechanism to do so) says that there is not such a
> clean method (please someone correct me if I am wrong). If this is the case
> then perhaps a later RedHat release could consider this. I can think of a
> few ways of acomplishing this, but probably the simplest would be to
> do something like HP does, which I mentioned in the P.S. of my previous
> email:
>
> P.S. on HP/UX the system MANPATH was constructed from the file
> /etc/MANPATH which contained a : delimited list of directories,
> which made it very easy for depots (HP rpms) to alter the MANPATH,
> and was very necessary in an architecture where most every package
> gets its own directory under /opt.
>
The /opt/package/{etc,bin,man} practise can lead to quite riducule
length with PATH, MANPATH etc. components when you have plenty
of softare in your system, so beware.
The Written Word, see [ http://www.thewrittenword.com/, has
created quite a nice symlink workaround with native HP-UX packages,
see ftp://ftp.thewrittenword.com/packages/INSTALL.pdf and
check how COMMON_BASE option can ease the PATH pollution.
The second problem with /etc/MANPATH and /etc/PATH with
HP-UX is that fairly many especially third-party vendor
packages (depots) that I have seen screwed up badly while
editing those files, even packages from some HP departments
have had these problems (ever tried JetDirect and HPNP packages?).
Most common problems I have met are:
- when reinstalling you often have duplicate paths added.
- I've met many times // had been added there.
- does not provide means of checking first that the
filesystem is mounted before reference to path is added
This was just to point that the HP-UX practis IMHO is far
from ideal.
> The key problem I see with this method is that I don't believe gnu man supports
> this (again I would like to be wrong), but what I think could easily be done is
> add a command that at startup would alter the man.config to contain the
> the MANPATH found in this file. On the other hand, another approach that
> may be better would be to provide command on a redhat system that would allow
> one to add a MANPATH statement to the man.config. This thing command would
> be fully aware of the man.config syntax, so that it could:
>
> - add the MANPATH in clean way.
> - make sure that it had not already been added.
>
I don't think you need that stuff at all ...
I'd prefer this stuff done at /etc/profile.d/ with appropriate
scripts, those are executed after login.
Let's say I have /etc/profile.d/localpath.sh
# strip 'local' PATH components
IFS=":"; NPATH=""
for i in $PATH ; do
case $i in
/usr/local/bin|\
/usr/local/sbin|\
/usr/sbin|\
/sbin) # strip these first, add again later
;;
*) # store rest to NPATH, if they exist
if [ -d "$i" ]; then
if [ -z "$NPATH" ]; then
NPATH="$i"
else
NPATH="$NPATH:$i"
fi
fi
;;
esac
done
IFS="
"
export IFS
# prepend local path to ordinary users, set TMOUT to root
case $LOGNAME in
root) PATH="/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:$NPATH"
if [ -t ]; then
TMOUT=600
fi
export PATH TMOUT
;;
*) PATH="/usr/local/bin:$NPATH"
export PATH
;;
esac
You can traverse nicely the PATH with setting the shell
field separatore (IFS) to : and then later construct new
variable later. A nice and portable way too :)
You should always remember to think that when runing commands via
ssh (rsh) from remote machine too, hence the -t test for control-
ling tty is very important!
The same suff for {,t}csh shells
# strip local PATH components
set npath=()
foreach i ( $path )
switch ( $i )
case /usr/local/bin:
case /usr/local/sbin:
case /usr/sbin:
case /sbin:
breaksw
default:
if ( -d $i ) then
set npath=( $npath $i )
endif
endsw
end
prepend local path to ordinary users
switch ($LOGNAME)
case root:
set path=(/usr/local/sbin /usr/local/bin /sbin /usr/sbin $npath)
/usr/bin/tty -s >& /dev/null
if ( ! $status ) then
setenv TMOUT 600
set autologout=10
endif
breaksw
default:
set path=(/usr/local/bin $npath)
endsw
unset npath
Some platforms like HP-UX (since 10.20) the POSIX shell compound
expressions like [[ expression ]], the problem with these extensions
are portability. Not all unixen have POSIX conformant shell yet for
root, most notably the Solaris 8 and before has stick
Re: Altering the MANPATH in RPM
> > > I guess since know one has responded to this question concerning a > > clean way for an RPM to alter the MANPATH (i.e. alter it non-destructively > > and using a safe mechanism to do so) says that there is not such a > > clean method (please someone correct me if I am wrong). If this is the case > > then perhaps a later RedHat release could consider this. I can think of a > > few ways of acomplishing this, but probably the simplest would be to > > do something like HP does, which I mentioned in the P.S. of my previous > > email: > > > > P.S. on HP/UX the system MANPATH was constructed from the file > > /etc/MANPATH which contained a : delimited list of directories, > > which made it very easy for depots (HP rpms) to alter the MANPATH, > > and was very necessary in an architecture where most every package > > gets its own directory under /opt. > > > > The key problem I see with this method is that I don't believe gnu man suppor > > ts > > this (again I would like to be wrong), but what I think could easily be done > > is > > > I'm sure it does, but I can't be bothered reading the man page. > > I'm sure reading the man page will provide all the answers. > I most humbly submit that I have read the man page (which I reffered to). Not to toot my horn, but I have been doing this UNIX thing in one fashion or another for at least 10 years. Reading the man page is the first thing I do (well in truth looking at configs and source is sometimes the first thing I do, but asking a question on a list where one is subject to public flogging is not the first thing I do). > > I'd not undo the changes when the rpm is removed though - it just might be > possible that something else wants the same change. Very good advice. > > I recommend using grep to test whether the change is actually needed, than maybe > ed to implement it. grep and sed and all their other ilk are all bad ideas for something that may be distributed to lots of places. The best procedure is to understand the format of the config, and parse it. Once you have the parse tree, you can then confidently (provided your undrstanding was true) parse it. > > Plenty of man pages to read there;-) > And info pages, and web pages probably if you can phrase your search query correctly. ...james ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
> I guess since know one has responded to this question concerning a > clean way for an RPM to alter the MANPATH (i.e. alter it non-destructively > and using a safe mechanism to do so) says that there is not such a > clean method (please someone correct me if I am wrong). If this is the case > then perhaps a later RedHat release could consider this. I can think of a > few ways of acomplishing this, but probably the simplest would be to > do something like HP does, which I mentioned in the P.S. of my previous > email: > > P.S. on HP/UX the system MANPATH was constructed from the file > /etc/MANPATH which contained a : delimited list of directories, > which made it very easy for depots (HP rpms) to alter the MANPATH, > and was very necessary in an architecture where most every package > gets its own directory under /opt. > > The key problem I see with this method is that I don't believe gnu man suppor > ts > this (again I would like to be wrong), but what I think could easily be done > is I'm sure it does, but I can't be bothered reading the man page. I'm sure reading the man page will provide all the answers. I'd not undo the changes when the rpm is removed though - it just might be possible that something else wants the same change. I recommend using grep to test whether the change is actually needed, than maybe ed to implement it. Plenty of man pages to read there;-) > add a command that at startup would alter the man.config to contain the > the MANPATH found in this file. On the other hand, another approach that > may be better would be to provide command on a redhat system that would allow > one to add a MANPATH statement to the man.config. This thing command would > be fully aware of the man.config syntax, so that it could: > > - add the MANPATH in clean way. > - make sure that it had not already been added. > > I guess you would have in the %pre r %post section of your spec file somethin > g > like: > > add2manpath directory_to_add > > > Food for thought...james > > > > ___ > Redhat-devel-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Re: Altering the MANPATH in RPM
I guess since know one has responded to this question concerning a clean way for an RPM to alter the MANPATH (i.e. alter it non-destructively and using a safe mechanism to do so) says that there is not such a clean method (please someone correct me if I am wrong). If this is the case then perhaps a later RedHat release could consider this. I can think of a few ways of acomplishing this, but probably the simplest would be to do something like HP does, which I mentioned in the P.S. of my previous email: P.S. on HP/UX the system MANPATH was constructed from the file /etc/MANPATH which contained a : delimited list of directories, which made it very easy for depots (HP rpms) to alter the MANPATH, and was very necessary in an architecture where most every package gets its own directory under /opt. The key problem I see with this method is that I don't believe gnu man supports this (again I would like to be wrong), but what I think could easily be done is add a command that at startup would alter the man.config to contain the the MANPATH found in this file. On the other hand, another approach that may be better would be to provide command on a redhat system that would allow one to add a MANPATH statement to the man.config. This thing command would be fully aware of the man.config syntax, so that it could: - add the MANPATH in clean way. - make sure that it had not already been added. I guess you would have in the %pre r %post section of your spec file something like: add2manpath directory_to_add Food for thought...james ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
Altering the MANPATH in RPM
Hi All, I have built a set of RPMs that install to some place like: /usr/build with bin, man and lib directories under their. I would like to in the RPM make the man pages from these RPM's available. I tried altering the MANPATH, but when I did this it completely overrided /etc/man.config such that my man pages were available but the system ones were not. I checked out the man.config man page, but it seemed to say that if you use the MANPATH that completely overrides what is set as a MANPATH in that config file. I know I can drop a script in profile.d, but doing so, according understanding means I would have to either: - parse the man.config MANPATH statements being sure to include them in my MANPATH. - override the man.config settings completely. With the second option I can try to guess that they wil have /usr/man in their man path, but on a system where the system admin has altered this config file, I will cause his mods to mysteriously go away. So my question is is there a way to alter the MANPATH that will complement the man.config file? Thanks...james P.S. on HP/UX the system MANPATH was constructed from the file /etc/MANPATH which contained a : delimited list of directories, which made it very easy for depots (HP rpms) to alter the MANPATH, and was very necessary in an architecture where most every package gets its own directory under /opt. ___ Redhat-devel-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-devel-list
