Re: [Twisted-Python] Cisco-style hierarchial CLI
On Sat, 20 Mar 2004 18:43:36 +0000, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
All,
I'm putting together some glue-ware for a system, and would like to hide the underlying nature of it. It's a bit of software that fits in and around routers / switches etc. and there's a pretty common CLI for those these days, which consists of a hierarchial context-based set of commands, plus completion, e.g. on Cisco, although I suspect everyone is familiar with the concept:
[snip examples]
The hiearchial configure mode is mapped onto a hierarchial configuration file, e.g. the above would generate:
subsystem trusted vlan 1 ! !
It's main features are:
1) Tab completion and partial -> full conversion 2) Nested modes
Relevant to twisted is I want to replace the manhole interactive interpreter.
Any such beast exist?
twisted.python.usage has some support for subcommands. It doesn't support arbitrary abbreviations (if I recall correctly), but could probably be made to without much difficulty. Tab completion would have to be offered by whatever UI was presented, of course, and facilitated by some easily-done introspection into the Options class. t.p.usage.Options instances set their "subOptions" attribute when a sub-command is encountered. I think you could exploit this fact to support nested states, by grabbing the subOptions object and asking it to parse further input. I'm not sure how "backing up" should work, but you could probably accomplish it by keeping a stack of all the options classes that you get from the subOptions attribute. Of course it supports arbitrarily deep nesting, so multilevel commands are support. The API is pretty simple, you just create an Options subclass with a subCommands class attribute bound to a list of lists of the form ["longname", "shortname", OtherOptionsSubclass, "Description"]. The existing code won't get you all the way there (especially the help formatting), but it seems like a reasonable place to start. Jp
Tab completion would have to be offered by whatever UI was presented, of course, and facilitated by some easily-done introspection into the Options class.
Oh, one more idea. The tab completion support should definitely be written so that bash and zsh programmable tab completion could be told how to ask the app for tab completions.. E.g. $ appname --foo -x --bar=a<TAB> path/to/dir/quux* (cursor is on 8th char of 3rd argument, so runs e.g. appname \ --show-tab-completions \ --tab-completion-arg=3 \ --tab-completion-cursor=8 \ -- \ --foo -x --bar=a path/to/dir/quuxthud path/do/dir/quuxbaz which will then output something bash/zsh can parse)
t.p.usage.Options instances set their "subOptions" attribute when a sub-command is encountered. I think you could exploit this fact to support nested states, by grabbing the subOptions object and asking it to parse further input. I'm not sure how "backing up" should work, but you could probably accomplish it by keeping a stack of all the options classes that you get from the subOptions attribute.
Options have a "parent" attribute, so maintaining the stack is unnecessary.
participants (2)
-
exarkun＠divmod.com -
Tommi Virtanen