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 ? 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_. 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). > 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 ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
