On Sun, 22 Jan 2012 19:29:23 +0530 Siteshwar Vashisht <[email protected]> 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
