Re: Command Line Interpreter

bernfarr@my-deja.com wrote:
> 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.


That looks like a grammar to me. A big, ugly grammar with a zillion
keywords, but a grammar.


stmt:
ENABLE
| opt_no ACCESS_LIST acc-list-no opt_deny_permit access_list
{ /* check that opt_deny_permit was empty
* if NO and ADDITIONAL_ZONES */
}
| opt_no ATM FRAMING atm_framing
| ...
;
opt_no: /*nix*/ | NO;
opt_deny_permit: /*nix*/ | deny_permit;
deny_permit: DENY | PERMIT;
access_list:
CABLE_RANGE cable-range
| ADDITIONAL_ZONES
;
atm_framing: CBITADM | CBITPLCP | M23ADM | M23PLCP;




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


No problem. If there's no match to the keyword, search through your
keyword list for the first partial match. There are three potential
outcomes:
- no match: error
- 1 match: return token for the keyword
- multiple matches: have the user choose from the list, return the
    appropriate token


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


No problem. The parser does know the list of possible next tokens.
It's
coded in the YACC tables, and you can see a human-readable version in
y.output.


Add some help tags in comments in the YACC source, generate y.output,
and write a little awk/perl/whatever script to smash it together.
You'll then have a list of tokens and help per state. When you need
to display help, pick up the YACC state, index into your table, and
dump out the message. If you need more context, you can look through
all the states taken to get to the current state on the YACC stack.
--
Scott Nicol
snicol@apk.net

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