Using zsh as a base for Network device CLI

Using zsh as a base for Network device CLI

[Vinod KK]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Hi,

One of my current tasks is to move our device CLI to a standard shell, to
exploit job control, piping and the rest of the good features. I have
decided to use zsh for this purpose, as it seems to be the most extensive
one, functionally.

The main challenges in this is to
1. change the initial builtins to the commands that the device understands
and
2. update completion to use the command syntax of the device.

There is a bit of existing C code that parses the command syntax grammer
that I would like to leverage.

I had 2 questions regarding this:

1. Has something similar been attempted by anybody in this group?
2. What should be my initial design path, so that the solution fits in with
zsh philosophy?

Thanks
Vinod

Re: Using zsh as a base for Network device CLI

[Peter Stephenson]

On Tue, 5 May 2015 11:00:43 -0400
Vinod KK <nadarji@gmail.com> wrote:
> One of my current tasks is to move our device CLI to a standard shell, to
> exploit job control, piping and the rest of the good features. I have
> decided to use zsh for this purpose, as it seems to be the most extensive
> one, functionally.
> 
> The main challenges in this is to
> 1. change the initial builtins to the commands that the device understands
> and
> 2. update completion to use the command syntax of the device.
> 
> There is a bit of existing C code that parses the command syntax grammer
> that I would like to leverage.
> 
> I had 2 questions regarding this:
> 
> 1. Has something similar been attempted by anybody in this group?
> 2. What should be my initial design path, so that the solution fits in with
> zsh philosophy?

I'm not sure I understand the scope well enough to give any detailed
answer, but definitely the first think I'd suggest is creating a
loadable module with the builtins you require in it --- that will
definitely give you the cleanest interface.  There are plenty of
examples in the Src/Modules directory with builtins.  I wouldn't be shy
of providing special parameters if that's a more natural way of
exchanging certain forms of information, either.

There is some guidance in Etc/zsh-development-guide

Note you'll very likely still need the normal shell build tree --- the
mechanics of building a loadable module separately aren't very well
advanced.

pws