[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