Added support in MacPorts base to set PATH and MANPATH automatically in Leopard

[Juan Manuel Palacios]

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