Roland Mainz wrote:
> Joseph Kowalski wrote:
>
>> Peter Tribble wrote:
>>
>>> I'm all in favour of helping man find more manpages, but deriving it from
>>> the PATH here seems wrong - assuming that the initial PATH is set there,
>>> then just hardcode the MANPATH to match.
>>>
>> Roland,
>>
>> I see two options for you:
>>
>> 1) Reduce the case to the just above.
>>
>
> Reduce to what ?
>
I thought Peter's suggestion was fairly clear. (And it seems to address the
setting of the default MANPATH rather well)
However, this was over-statement on my part. There are a lot of "smaller"
proposals which could be fast-track appropriate. Sorry about that.
> 1. My primary concern is the choice for PAGER. I know that /usr/bin/less
> has some holes (I am very unhappy about the issues with "/usr/bin/less
> vs. zh_CN.GB18030&co." - much work has been invested into ksh93 to get
> it properly working with multibyte locales (even the non-UTF-8 ones) and
> now I have to propose the PAGER=/usr/bin/less thing... ;-( ) but it
> would _improve_ the usuablity situation at least to a level which is in
> sync with Linux (and most Linux users live happily with this choice).
>
> I know that the "better" solution may be to do a "rm -f /usr/bin/more ;
> mv /usr/xpg4/bin/more /usr/bin/more" and then starting to fix "more" -
> but in reality the time I can contribue to OpenSolaris.org is currently
> occupied by the ksh93-integration work (and I can't do more since the
> current time is taken from the amount of time spend at night where I
> should be sleeping (and I doubt that someone suddently starts hiring me
> to get more work in this area done... ;-( ) ...) and I doubt that new
> engineers will fall from the sky and start fixing/improving "more" in
> the next couple of months. Therefore - maybe only as a temporary
> solution - it may be nice to use PAGER=/usr/bin/less to get an
> improvement _now_.
>
This is a part that's not fast-track appropriate (and the zh_CN issue is
an absolute
stopper IMHO).
> 2. For the default value of MANPATH I proposed a small alternative
> ealier - what about moving the glue which calculates the MANPATH value
> from PATH into a seperate script (e.g. /usr/lib/shell/pathtomanpath (or
> /usr/sbin/pathtomanpath)) that it can be used for end-users in their
> ~/.profile, too ? Putting the code into /usr/bin/man would be an option
> but AFAIK it would rule-out any possibilty for a backport to Solaris 10
> (and it would be more risky, too).
>
Another interface to support forever when we know the changes should
really be
made to the man command itself? (Er, I think we know that - I saw it
asserted without
disagreement.)
Why would this rule-out a backport? It would be interface compatible,
wouldn't it?
>
>> 2) Bring this forward as a full case (or, I will derail it and get
>> it there anyway).
>> This is not an assessment of "good or bad". It simply does not
>> meet the
>> requirement of "obvious" for a fast-track (while option #1 does
>> seem obvious).
>>
>
> Darren: Any comments/objections/suggestions/etc. about this ?
>
>
Several things seem less than obvious to me.
Changing the default value of PAGER. less has enhancements and
regressions wrt more. The regressions need to be addressed. There are
also Don's standard based concerns (hummm,... maybe they would eliminate
the backport option).
Any form new "interfaces" as in "pathtomanpath" which may further
complicate "the right fix".
Depending on the hieristic "../bin". It makes me feel downright
unclean. That said, it may be acceptable if we document it as a
hierestic (again, possibly getting in the way of "the right fix".
There may be good answers to these concerns. They just aren't "obvious".
- jek3
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/shell-discuss/attachments/20070427/ffb87c82/attachment.html>
