On Sun, Dec 19, 2010 at 9:46 PM, Harry Putnam <rea...@newsguy.com> wrote: > Calum Mackay <calum.mac...@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 <mger...@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.coopersm...@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 _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
