Re: Command Line Interpreter

    Juergen Kahrs <jkahrs@castor.atlas.de> wrote:
> > What I need is a way to implement an interpreter that will read actions
> > from a command line and process them. The actions never run over
> > several lines.
>
> > [Sounds like another job for TCL. -John]
>
> Indeed. Sounds like you are more interested in getting the job done
> than in learning parsing techniques. If this assumption is correct,
> you might also think about implementing the interpreter as an AWK
> script:


In response to this and some earlier posts. Cisco IOS does not have a
BNF grammar (unfortunately). It has some interesting 'properties' that
make it hard to use some tools that I'm already familiar with.


Some examples of Cisco commands are:


ENABLE
ACCESS-LIST acc-list-no {DENY|PERMIT} CABLE-RANGE cable-range
[BROADCAST-DENY|BROADCAST-PERMIT]
NO ACCESS-LIST acc-list-no [{DENY|PERMIT} CABLE-RANGE cable-range
[BROADCAST-DENY|BROADCAST-PERMIT]]
ACCESS-LIST acc-list-no {DENY|PERMIT} ADDITIONAL-ZONES
NO ACCESS-LIST acc-list-no ADDITIONAL-ZONES
ATM FRAMING [CBITADM|CBITPLCP|M23ADM|M23PLCP]
NO ATM FRAMING [CBITADM|CBITPLCP|M23ADM|M23PLCP]


and so on for several hundred commands. No regular grammar. I'm using
uppercase to indicate keywords, lower case for param values. Square
brackets indicate a single choice of many. Curly braces indicate an
optional choice.


IOS also has a parser that allows partial keyword entry, or the user
can enter the start of a keyword and type the tab key to complete the
word. For any partial line the user can type the start of the line and
a ? to see possible next valid tokens. For the ACCESS-LIST example
above, the user might do


ACCESS-L 234 PERMIT ?


and the system might respond with:


CABLE-RANGE Enter start and end cable ranges
ADDITIONAL-ZONES Define action for access checks not explicitly
defined


(and a number of other valid tokens, with associated help strings)


So the parser must know what the list of possible next tokens are and
the associated help string for that token in that command.


I don't think that porting TCL would be effective because the
resulting parser must run on an embedded system with a limited
footprint. In another life I ported Perl to do this and managed to get
quite far with that approach. And Perl has got better debugging than
TCL from what I understand of TCL.


This time I was just hoping that someone might have finally developed a
tool that might be appropriate.


To summarize what I see as problems with dealing with IOS.


1. Large numbers of commands.
2. Need to support display of associated help for keywords.
3. Keywords can have different meanings (and associated help strings)
depending on where they're used.
4. Requirement to support multiple sessions on same parser with
different instances in different modes (re-entrancy)


If anyone has some tools suggestions besides flex/lex and yacc/bison,
I'd welcome them.


Thanks


Bernard

Return to the comp.compilers page.
Search the comp.compilers archives again.