[OpenIndiana-discuss] man pages to solaris cmds

[Albert Lee]

On Sun, Dec 19, 2010 at 9:46 PM, Harry Putnam <reader at newsguy.com> wrote:
> Calum Mackay <calum.mackay at cdmnet.org> writes:
>
>> hi Harry,
>>
>>> What is the MANPATH to the solaris cmds that there are also gnu
>>> versions of.
>>
>>       man -M /usr/share/man ls
>>
>> is what you're after :)
>>
>> Assuming your MANPATH is by default:
>>
>>       /usr/gnu/share/man:/usr/share/man:/usr/X11/share/man
>>
>> so you get the GNU man pages first...
>
> Nice ... thanks
>
>
> Mike Gerdts <mgerdts at gmail.com> writes:
>
>
> [...]
>
> Calum M wrote:
>
>>> so you get the GNU man pages first...
>>
>> And if you don't set your MANPATH, it will man will give you the man
>> page that is appropriate for your path.  For most users, having
>> MANPATH set is more likely to do harm than good.
>
> Mine isn't set, but I've been able to do man /bin/ls in the past
> .. not sure why not now.
>
>> http://arc.opensolaris.org/caselog/PSARC/2007/688/20071212_mike.gerdts
>
> I couldn't make heads or tails of that. . sorry.
>
>
> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
>
>> On 12/18/10 05:04 PM, Harry Putnam wrote:
>>> What is the MANPATH to the solaris cmds that there are also gnu
>>> versions of.
>>
>> /usr/share/man
>>
>>> /bin/ls  for example
>>>
>>> If I call man /bin/ls
>>>
>>> I get warnings about opening a binary file, and when the man page
>>> opens there is lots of guff in it like escape sequences.
>>
>> Strange - works for me on S11 Express - not sure what OI could have
>> done to break it.   (It is a little known feature that man will take
>> the command path to find the matching man page - not sure when it was
>> added.)
>
> I've been able to do it from before opensolaris 134... not sure how
> long before, but 133 for sure.
>
> I may have caused the problem with it myself by setting $LANG.
>
> I have had a problem reading man pages from the start on oi 148. I
> don't mean `man /bin/ls' but just the normal usage.
>
>  Someone advised me to set LANG=en_US.ISO8859-1.  When I did that, it
> does cure my on-going problem, .... but now wondering if when calling
> `man /bin/ls' ... it may act differently with LANG set that way.
>
> Yup... I just tested that theory out.
>
> When I do a fresh login (to oi 148) $LANG is en_US.UTF-8.  On that
> setting all man pages have goofy characters like this (from man ls)
>
>
>  DESCRIPTION
>       List  information  about the FILEs (the current directory by
>       default).  Sort entries alphabetically if none of  ââctuvSUX
>       nor ââsort.
>
> But I can call `man /bin/ls' and it opens the right page... with no
> warnings about binary, but it does have the guff above in it.
>
> If I set LANG=en_US.ISO8859-1 then man pages open nice and clean but
> it does cause the warnings about binary files (and fail) if I should
> try `man /bin/ls'  with that setting.
>
> Another poster here or on openindiana explained it best he could to me
> and seems a mismatch of some sort between my terminal program and
> $LANG setting.  I can correct if I happen to be using putty from
> windows, but logging in from linux or another solaris machine... I'm
> not really sure what terminal program is involved... the TERM setting
> when from linux is `TERM=linux', when from solaris TERM=sun-color.
>
> But what actual program is running the terminal... I don't know for sure.
>
The problem is probably not the terminal application itself, but TERM
which tells applications which terminal definition to use to
communicate with it. It's a relic of the days of physical terminals
when every vendor had its own incompatible protocol.

(That said, the standard terminal app is gnome-terminal and has a
Help->About dialog which should be impossible to miss...)

Anyway, I can't reproduce the problem here. What would help is to provide:
The output of 'env', the error you're seeing from 'man /bin/ls' and
the file contents from 'truss -f man /bin/ls 2>logfile'.

-Albert