> Joseph Kowalski wrote: > Roland Mainz wrote: > >> Joseph Kowalski wrote: > >> Roland Mainz wrote: > >> > Joseph Kowalski wrote: > >> >> Peter Tribble wrote: [snip] > >> 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"). > > When I wrote this, I actually meant both. > > However, based on further thought, its probably best read now as > applying only to setting MANPATH. I don't want to see anything > that even smells like an extended interface implemented here > without fully understanding > what the final interface should be. (and ../man s**ks as an > interface, IMHO)
What about the idea to create a tool called "pathtomanpath" which takes care about the conversion in /etc/profile and may be used by plain users in their ~/.profile, too ? [snip] > > 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... > > I propose we table backporting issues until we know what we would be > backporting. Grumpf... ... agreed. [snip] > > 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 ? > > > > > The main reason is that it never worked in certain locales for Linux > users. If it > had never worked for Solaris users, perhaps we could consider it, but > alas, it > did work. (I say perhaps, because Solaris also has some "big rules" > about i18n > always being done.) > > WE DON'T REGRESS. 1. /usr/bin/more is _not_ CSI-enabled and barely works with multibyte locales (I am ignoring /usr/xpg4/bin/more since most end-users never used that unless some admin was really clever and/or (more likely) set PATH to include "/usr/xpg4/bin:/usr/bin"). The newer "less" versions are better than that. 2. In theory we could add a plain check for "zh_CN.GB18030" and set PAGER=/usr/xpg4/bin/more to make sure it works in this case... but we don't have any manual pages in "zh_CN.GB18030" which reduces the issue to "mailx". An alternative may be that a Sun manager steps up and declares that some resources get allocated to "fix" /usr/xpg4/bin/more (e.g. add cursor keys for document navigation like in "less", add seach result highlighting (=reverse video), a way to edit he regular expression lines, fix any remaining multibyte locale issues etc.) and move the resulting application to /usr/bin/more (e.g. EOL/EOF /usr/bin/more and replace it with /usr/xpg4/bin/more). > >> 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" ? > > Yea, spelling isn't my strong point.... Umpf... my spelling is likely much worse (maybe time to switch to a better email client (once Seakmonkey (ex-Mozilla) stops eating emails for fun...)) ... > >> 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... ;-/ > > > > > I see the smiley, but the important point is "no regression". I see > that your view is > that the "good" outweighs the "bad". We officially don't think that > way (and > in practical terms, acceptable regressions need to be tiny and I don't > think being > "in your face" to a couple of billion folk is tiny). Right... but did you use /usr/bin/more in ja_JP.PCK recently ? I doubt "less" would be much worse for those users... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
