Hello, you are right concerning the organisation of classes in OpenBoot, the "help" is not very good. But the principal method is not so bad.
But your idea having a "help" and a help "--all" is better ! But IMO, there must be a "help --all" .... The idea of having a built-in more in the terminal interface is also very good, someone on the GRUB group also mentioned that. For dumb terminals: If the terminal is a "real box", then 25 lines (or perhaps 24, as one line may be used for other stuff) is quite default. If the terminal is a "xterm", "emacs", etc, no "more"-like handling is not necessary, as a scrolling the "window" or editor is possible. If we will make this configurable, the "--lines" parameter (I like this idea) should default to `24' and there should also be the value `none' (or `0' ?, `none' sounds better), to disable this "more" feature, by holding LINES to invalid. Depending on the key for further paging (<SPACE>, what ever), for dumb terminals a succeeding <ENTER> should be ignored (as the menu control in the new dumb terminal implementation). Having such a "more"-like handling, I would prefer a single coloumn of commands. The space for the short description is too small and is sometimes cut by the following command. Bye Christoph "Yoshinori K. Okuji" wrote: > > At Tue, 05 Feb 2002 09:45:39 +0100, > Christoph Plattner wrote: > > *2* a "help" working on classes, like OpenBoot of Sun: > > > > help booting > > help installing > > help console > > help memory > > help disks > > > > or similar. > > I hate the OpenBoot way, as the classification is far from > intuition. The worst point is that not all commands can be categorized > clearly. In addition, it is bad that you cannot see a summary > immediately by just typing "help". > > > In solution *2* also a "help --all" may exist, listing > > all commands in one coloum (left the command, right the > > short description) plus the `more'-like output. > > I didn't like to add a pager function into "help", because I didn't > think it could be implemented for general purpose. A per-command > implementation of a pager is really bad. > > Now I have an idea: implementing a pager at the grub_putchar > level. The pseudo code is: > > enter_cmdline: > loop: > show a prompt > get a command-line > set LINES to zero > execute a command > set LINES to an invalid value > > grub_putchar: > if newline: > if LINES is valid: > increament LINES > if LINES is equal to MAX_LINES: > show a prompt > wait for any key input > set LINES to zero > else: > print a newline > else: > print a character > > This could have GRUB to wait for user intervention whenever the screen > is full, regardless of what command is executed. One problem is how to > know MAX_LINES. You can get the geometry of a terminal mechanically > with the console and VT100-compatible terminals, but that is impossible > with dumb terminals. Adding "--lines=LINES" into "terminal", or have a > new command "resize"? > > However, I'm still thinking limiting commands shown with "help" is a > Good Thing. I have heard that the number of GRUB commands upsets > newbies several times, although most commands are not useful for them > anyway. It is considerable whether commands useful for debugging GRUB > should be displayed (by default), but, at least, it is a Good Thing to > hide commands useless for interactive use. For example, who wants to > see the usage of the command "lock" in the command-line interface? > This is proven, because of the fact that noone has criticized that > descriptions on menu-specific commands cannot be seen with "help". > > Therefore, I'm now inclined to show descriptions on some commands by > default and show all only if you specify "--all" to "help", like the > UNIX command "ls". > > Any comment is welcome... > > Okuji -- +--------V--------+ [EMAIL PROTECTED] | A L C A T E L | ----------------------------- +-----------------+ Phone: +43 1 27722 3706 T A S Fax: +43 1 27722 3955 _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub