I've been doing some hacking on vtysh in an effort to clean it up and fix some obscure bugs and less-than-sane interactions with daemons. Initially my efforts were focused on getting vtysh to automatically update its vty->node when a daemon node changes instead of needing a manual DEFUN override for every such daemon command. I have this working; after executing a command, the daemon side of the vty returns what node it is in in addition to the command status code and any output, which vtysh uses to update its own node. This in contrast to attempting to synchronize shared state over the life of a vtysh session without actually communicating said state.

That said, I think vtysh could use some more work on a slightly larger scale. In my opinion extract.pl is fragile and error-prone. For example, any command definitions outside the source files it looks in (such as the default commands installed by lib/command.c) are not picked up and thus need to be manually replicated in vtysh. Additionally anytime new submodes are added, one has to remember to update extract.pl. And there are quite a few edge cases that vtysh has to handle that ain't pretty.

I propose to change vtysh's behavior such that it no longer needs compile-time knowledge of daemon CLI. Instead it should ask each daemon for its CLI at runtime whenever needed, for example when a user types '?' or hits tab. This has several benefits:

% Unknown command

to something like, for example,

% Unknown command (or daemon not running).

As mentioned above I see this as a benefit since it will prevent users getting confused by vtysh silently accepting CLI for stopped daemons.

Feedback welcome.

Quentin