> Joseph Kowalski wrote: > 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)
I only wanted a clarification whether the proposal for "MANPATH" or "PAGER was" affected. IMO "PAGER" is currently the more imporant thing since it is the end-user interface for viewing the documents and both /usr/bin/more and /usr/xpg4/bin/more are in a very bad shape (looking at usuablity and comparing them to "less"). > However, this was over-statement on my part. There are a lot of > "smaller" > proposals which could be fast-track appropriate. Sorry about that. No problem... :-) > > 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). Technicially I agree. I would be ranting and sulking. I am one of the people who really pushed to get all the multibyte issues hunted down in ksh93 and I am a _huge_ fan of keeping the multibyte APIs in favor of unicode-specific ones (remeber when ISO2022 was "cool" in the last decade ? Now we have Unicode which is "cool". And maybe the next decade will have it's own cool encoding system (maybe called "interCode" or "iCode" ?) - the current multibyte API will work with all systems in all three decades but the unicode one will only work for unicode...). Messing around and replacing something like ja_JP.PCK or zh_CN.GB18030 with *.UTF-8 is more or less treated like a crime in the matching countries and I am not in favour of that either... ... but: Both /usr/bin/more and /usr/xpg4/bin/more are _that_ horrible for beginners that I am willing to swallow this temporary frog and _temporarily_ sacrify ja_JP.PCK + zh_CN.GB18030 support for a while to get an overall improvement for the other users in the "C"+singlebyte+"*.UTF-8" locales. This is not good but maybe a neccesarily evil we have to swallow. At least I am willing to do it... > > 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? It would change the defaults for a deployed product with a patch update. Maybe possible but AFAIK the best position to watch the matching ARC case is from behind a large rock... > >> 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. Right, but I guess the regressions for zh_CN.GB18030 are easier to fix than fixing/unifiying the two "more" things. Another consideration may be that "less" appears to be "good enougth" for the Linux users... why shouldn't it be good enougth for Solaris ? > 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". Erm... what is "hierestic" ? Do you mean "heuristic" ? > There may be good answers to these concerns. They just aren't > "obvious". Yes... but something needs to be changed. Somehow... maybe with a large axe and battle-club... ;-/ ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
