Re: [Groff] Parsing specific section of man page

[James K. Lowden]

On Sun, 22 Jan 2012 19:29:23 +0530
Siteshwar Vashisht <address@hidden> wrote:

> I am working on a shell, and the idea
> is to show suggestions for command line options on pressing tab. So
> let's say on pressing "ls<TAB>", I will get all the command line
> options for ls command. Now a good idea is to fetch these options
> from manual pages.

Yes, it is.  

Opinions on shells and shell-goodness vary.  Otherwise we wouldn't have
the vast ghastly variety we do.  (csh is considered harmful, you
know.)  

Contrary to Ingo, I encourage you.  Two observatoins for the pot:

1.  Twenty-five years ago I used a non-unix shell so far ahead of its
time nothing like it has been seen before or since.  It was a
command-line with ncurses-like forms.  You could type the options on
the command line but, if at any time you became confused, you could
press <mumble> and a whole form appeared.  Fill out the form, press
Return, and you were off.  Fully programmable, nicely interactive on
demand, with integrated help.  Unix shells are crude indeed by
comparison.  

2.  I'm sure what Ted says about mdoc/man is true, that man pages in
general lack the semantic information you need to be used in the way
you want.  That said, inferences are possible.  The existence of
unroff suggests inferences might be useful for a significant
fraction.  (I haven't used it, but you might want to take a look.)  

(Some will definitely defeat you.  I can't find an example now, but some
man pages don't even structure the option descriptions as an itemized
list; some describe the options in running text, in paragraphs.) 

The problem can be broken into two parts: the creation of semantic
information from man pages, and the use of that semantic information by
your shell.  

Suppose you used, say, unroff to populate a database of commands and
their options, and wrote two utilities: one to update that database
both as the man pages were updated (perhaps using cron),  and another to
accept manual overrides for man pages not amenable to semantic
extraction. Now you have a user-extensible system, and your shell
doesn't know about or care about man/mdoc/whatever.  

A design with an intermediate database lets you attack the problem from
both ends.  You can work at turns on producing the information
(populating the database) and on using it in your shell.  You can focus
on the utilities you think are interesting, maybe by sorting your own
shell's command history.  And when you hit a man page that's totally
hopeless, you can still fall back on using your brain to populate the
database based on what you see on the screen.  

Good luck with it.  It might be fun.  After all, that was the idea in
the first place, right?  

--jkl