Re: Command Line Interpreter
31 Jul 2000 20:18:21 -0400

          From comp.compilers

Related articles
Command Line Interpreter (2000-07-23)
Re: Command Line Interpreter (2000-07-27)
Re: Command Line Interpreter (Juergen Kahrs) (2000-07-27)
Re: Command Line Interpreter (2000-07-27)
Re: Command Line Interpreter (2000-07-29)
Re: Command Line Interpreter (Steven D. Majewski) (2000-07-29)
Re: Command Line Interpreter (2000-07-31)
Re: Command Line Interpreter (Gregory Bond) (2000-08-04)
Re: Command Line Interpreter (Chris F Clark) (2000-08-04)
Re: Command Line Interpreter (Scott Nicol) (2000-08-04)
Re: Command Line Interpreter (Frithiof Jensen) (2000-08-04)
Re: Command Line Interpreter (Tom Moog) (2000-08-05)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: 31 Jul 2000 20:18:21 -0400
Organization: - Before you buy.
References: 00-07-055 00-07-069
Keywords: parse, tools

    Juergen Kahrs <> 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:

ACCESS-LIST acc-list-no {DENY|PERMIT} CABLE-RANGE cable-range
NO ACCESS-LIST acc-list-no [{DENY|PERMIT} CABLE-RANGE cable-range

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


and the system might respond with:

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

(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.



Post a followup to this message

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