On Dec 2, 2007, at 2:06 PM, James Berry wrote:
Hi Juan,
On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote:
So, has any conclusion been reached for this issue? I'm inclined
to backing this feature out of the release_1_6 branch until a
working consensus is reached, and only release it to the public at
that time (in 1.6.x (x > 0)). Until now we've only been modifying
the user "profile" for a range of bourne based shells and the
"cshrc" file for equivalent C based shells, which has worked fairly
well, I believe; anyone experienced enough to create something like
~/.bash_profile or anything else very shell specific would be savvy
enough to setup his/her own environment to their content, I'm sure.
I'd strongly favor sticking to this approach in 1.6.0 until
something better is found, unless it explicitly breaks expected
behavior on Leopard. Does it?
Well, given that man pages are broken at present with a standard
MacPorts install under Leopard, something has to be done. A few
choices:
(1) Use this scheme, as implemented. (Downsides: affects /etc,
MacPorts paths are added at the end of PATH and MANPATH).
(2) Supplement this scheme by munging PATH inside the MacPorts code
to ensure that $prefix is always at the head of the path during
builds, and to guard against the sort of build problems suggested by
kvv.
(3) Modify existing path modification code to also add MacPorts
paths to MANPATH. (This might break other man pages on Tiger where
the system provides no meaningful default for MANPATH—maybe we do it
only if MANPATH is already defined?)
I've been mulling over this situation for the last week or so, but
haven't done anything because I'm not very happy with any of the
solutions.... I think (3), however is the lowest risk approach.
James
So, using approach number 3) to add our settings to the MANPATH
variable on both Tiger and Leopard only if it the latter exists, James
and I have two suggestions that we believe work equally well, either
one to be added to the base/portmgr/dmg/postflight script:
1) A conditional that would be added to each of the two important
cases of the "case $USHELL in" clause:
*csh)
if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL -lc "/usr/
bin/printenv MANPATH" | grep -q /opt/local/share/man; then
echo "set manpath=(/opt/local/share/man" '$path'")" >>
$HOME/.cshrc
fi
*sh)
if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL -lc "/usr/
bin/printenv MANPATH" | grep -q /opt/local/share/man; then
echo "export MANPATH=/opt/local/share/man:\$PATH" >>
$HOME/.profile
fi
With this approach, a static setting is added to the proper files if
the conditional matches.
2) No conditional what-so-ever is added to either of the cases, but
rather code to test for manpath at shell runtime is output to both
cshrc and profile files:
*csh)
echo "[ -n \"\$MANPATH\" ] && echo \$MANPATH | grep "/opt/local/"
> /dev/null && set manpath=(/opt/local/share/man '$path')" >>
$HOME/.cshrc
*sh)
echo "[ -n \"\$MANPATH\" ] && \$(echo \$MANPATH | grep "/opt/local/"
>& /dev/null) && export MANPATH=/opt/local/share/man:\$MANPATH" >>
$HOME/.profile
With this approach, a dynamic check for the variable would be
performed upon each shell invocation, but I wouldn't be too sure about
the proper escaping needed to get everything through to the files
appropriately.
So, opinions? Option 1? Option 2? Corrections to either? Something
completely different?
Regards,...
-jmpp
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
