Prev: here-document in function and temp file
Next: trying to parametrize find ...
From: Phred Phungus on 16 Mar 2010 22:32
I've been able to update the capabilities that one expects from man
pages. I was particularly glad to find:

apt-get install manpages-dev

as this gives a person on ubuntu a way to see a man page for fork, for
example.

Geoff Clare posted elsethread some tricks with paging, and it made a
huge difference for me to be able to go backwards by pressing b. In
particular, I can use either of my recently sprained hands and toggle
back and forth on the space bar and the b key, keeping eyes forward.

One of my big problems with man pages is that I don't know what I'm
getting into. This screenshot shows man man in 2 terminals:

http://i39.tinypic.com/k368ah.png

How do I invoke man foo so that it looks like the left one, that is,
knowing how much there is of the whole thing, so I can know the right
balance between reading and scrolling. With the left terminal, I
scrolled through already. I feel like I'm missing a bunch of commands
like shift-q, that give you precise control here and don't see them in
man man.

I'm also interested in anyone's personal tips and tricks re man pages.

Thanks for your comment, and cheers,
--
fred
From: Jon LaBadie on 17 Mar 2010 02:41
Phred Phungus wrote:
> I've been able to update the capabilities that one expects from man
> pages. I was particularly glad to find:
>
> apt-get install manpages-dev
>
> as this gives a person on ubuntu a way to see a man page for fork, for
> example.
>
> Geoff Clare posted elsethread some tricks with paging, and it made a
> huge difference for me to be able to go backwards by pressing b. In
> particular, I can use either of my recently sprained hands and toggle
> back and forth on the space bar and the b key, keeping eyes forward.
>
> One of my big problems with man pages is that I don't know what I'm
> getting into. This screenshot shows man man in 2 terminals:
>
> http://i39.tinypic.com/k368ah.png
>
> How do I invoke man foo so that it looks like the left one, that is,
> knowing how much there is of the whole thing, so I can know the right
> balance between reading and scrolling. With the left terminal, I
> scrolled through already. I feel like I'm missing a bunch of commands
> like shift-q, that give you precise control here and don't see them in
> man man.
>
> I'm also interested in anyone's personal tips and tricks re man pages.
>
> Thanks for your comment, and cheers,

I'm assuming you mean with a notation about the length of the document
on the last (status) line.

You will have to realize that the application you are interacting with
is a program called "less". You did not invoke it directly, though
you can. It was the last command of a pipeline started by the "man"
command. So what you really need to learn more about is less.

Why is it "less" rather than "man"? Well man can send the formatted
version of the page to several places, to a printer, to a file in
postscript or in text form, or to the terminal. Many manpages are
long and would scroll right off the screen if dumped directly to
the terminal. Thus man sends the text to a screen pager called "less".

When less is reading a file directly, eg. "less /etc/profile" it can
easily determine the length of the document. This is not as easily
done by less when it is reading a pipeline as in the man command or
if you use it as some_cmd | less. Only when it reaches the end of the
pipe will it know how big the document is. So less will not be able
to give the left terminal type of status line until it has reached
the end of the man page.

You could force the left status line with a pair of less commands
that jump to the end of the document and then back. First is the
'go to' command "G". Given alone it will go to the end of the
document. See the less manpage for other uses.

Then jump back to the beginning of the document with a pair of
single quotes telling less to jump back to where I last jumped
from; which in your case would be back to the beginning of the
document. So the sequence G'' should get you the status line
you desire.
From: Ben Bacarisse on 17 Mar 2010 11:05
Jon LaBadie <jlabadie(a)aXcXm.org> writes:
<snip>
> You could force the left status line with a pair of less commands
> that jump to the end of the document and then back. First is the
> 'go to' command "G". Given alone it will go to the end of the
> document. See the less manpage for other uses.
>
> Then jump back to the beginning of the document with a pair of
> single quotes telling less to jump back to where I last jumped
> from; which in your case would be back to the beginning of the
> document. So the sequence G'' should get you the status line
> you desire.

Also, you can give initial commands to less with the + command line
option character. Since less also takes options from an environment
variable called LESS you play tricks like:

LESS="G''" man man

or perhaps more generally

LESS="$LESS +G''" man man

To the OP: there are lots of ways to read man pages. I often read
them in emacs.

--
Ben.
From: Robert Bonomi on 25 Mar 2010 19:19
In article <80at9tF3gvU1(a)mid.individual.net>,
Phred Phungus <Phred(a)example.invalid> wrote:
>
>Thanks for your comment, and cheers,


The short answer is _you_ are not in need of better man-page handling.

Manpages are =reference= material, for _experienced_users_ who *already*
*know* WHAT they need to do, and just need a referesher on the mechanics
of HOW to do it.

They are *NOT* intended to be 'primary educational material' for people
who are _learning_ how to do things. For that you need "tutorial"
materials -- an entirely _different_ kettle of fish.

First, You need a good book on the Unix _user_ environment, this will
clarify nuances of things like how the shell inteprets command-lines,
the various kinds of 'wildcard' capabilities that exist; when, and
*why* you need various kinds of 'quoting', how they are *different*
from each other, etc. It will also, not incidentallly, cover how to
_use_ a bunch of the more common commands.

Second, a good book on whatever text editor you decide to use is
a -very- good idea -- practically every 'real' unix editor has a
*LOT* more capabilities than the average user of it realizes.

Third, you need a good book on *UNIX* programming -- not so much how
to use a programming language, but WHAT the various 'library'
functions that are part-and-parcel of the Unix environment are intended
to accomplish, and why you might pick any particular one of several
similar routines in any given situation.


AFTER you have a solid grasp of the basics, you can 'extend' your under-
standing from the *reference* documentation in the manpages.

Trying to pick up an understanding of the _BASICS_ from =reference=
documentation is a sure route to a _lot_ of frustration, and makes
life un-necessarily difficult for yourself.


As for specific books:
Practically *anything* published by O'Reilly & Assoc. <www.ora.com>
is good reading.

For -using- Unix:
"Unix in a Nutshell"
"Learning the Unix Operating System"



Programming:
*THE* reference: "The Unix Programming Environment"
(written by the guys who wrote the O/s)

"Advanced Unix Programming"
"Advanced Programming in the Unix Environment"
 | 
Pages: 1
Prev: here-document in function and temp file
Next: trying to parametrize find ...