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 <somepath>
> then put manpages in either <somepath>/man/man* or
> in <somepath>/../man/man*, and either drops something into
> /etc/profile.d (prefered) or the users add <somepath> 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
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
