Roland Mainz wrote:
>> 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").
>
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)
There are equivalently important issues with PAGER. See below. However
I now see this strong a statement as not appropriate for PAGER.
>
>> 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...
>
I propose we table backporting issues until we know what we would be
backporting.
>>>> 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 ?
>
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.
>
>> 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....
>
>> 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).
Summary about switching "more" to "less"...
1) less must not be a regression from more (currently identifies
as Asian lang.
support, but maybe there is more).
2) I believe such a switch requires a Minor binding. Even if we
could make
a patch out of it, its such an in-your-face change that it
goes against the
expectations of a patch (Update) release.
Could other ARC members chime with opinions on the above two bullets?
- jek3
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/shell-discuss/attachments/20070502/f9292b07/attachment.html>
