>
> 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
