[cmaster-next] CLI plans
David Lamparter
equinox at diac24.net
Thu Dec 1 15:48:52 EST 2016
Hi all,
Quentin and I just had a chat about future CLI plans. Here's a summary
for everyone else:
- the parser for CLI commands currently merges them straight into the
common graph of all CLI commands. This'll be split off into an extra
step: (pseudocode)
graph = graph_new()
command_parse_format(graph, cmd->str)
command_merge_graph(graph, target_graph)
The idea here is that the separate merge step makes it easier to
* handle errors
* undo the installation
* do other graph transformations before merging
- I'm finishing up on keyword specification {keyword OPTION|other
A.B.C.D} - it's mostly done and works. There's nothing special for
keywords, they're just selections that loop on themselves, allowing
multiple uses.
- for keyword arg lists one can use by-name references to *fixed* args
(e.g. argv_find("keyword")).
- by-name references to *variables* (WORD, A.B.C.D) will be pending
until we get the merge split off, after which this is a new graph
transformation step.
- Quentin is looking at tests/, the testcli case is exhibiting some
"interesting" behaviour. They're mostly help-string related and some
of these may end up just being changes in design.
- I have autocomplete for {interface, route-map, etc.} names mostly
done, but only in-daemon, not vtysh. I'll push that out; adding
vtysh support is a matter of adding a communication channel for
completions, e.g. a hidden command. Whoever wants to can do that :)
- Help string bloat reduction is complicated and we don't quite have a
plan there yet.
- Improving the way "no" commands work is on the long-term horizon. For
now they need another DEFUN in most cases.
Cheers,
-David
More information about the dev
mailing list