Re: Command Line Interpreter

Scott Nicol <snicol@apk.net>
4 Aug 2000 15:55:18 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: Command Line Interpreter bernfarr@my-deja.com (2000-07-27)
Re: Command Line Interpreter adamo@dblab.ece.ntua.gr (2000-07-29)
Re: Command Line Interpreter sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (2000-07-29)
Re: Command Line Interpreter bernfarr@my-deja.com (2000-07-31)
Re: Command Line Interpreter gnb@hellcat.itga.com.au (Gregory Bond) (2000-08-04)
Re: Command Line Interpreter cfc@world.std.com (Chris F Clark) (2000-08-04)
Re: Command Line Interpreter snicol@apk.net (Scott Nicol) (2000-08-04)
Re: Command Line Interpreter faj@ericssontelebit.com (Frithiof Jensen) (2000-08-04)
Re: Command Line Interpreter tmoog@polhode.com (Tom Moog) (2000-08-05)
| List of all articles for this month |
From: Scott Nicol <snicol@apk.net>
Newsgroups: comp.compilers
Date: 4 Aug 2000 15:55:18 -0400
Organization: APK Net
References: 00-07-055 00-07-069 00-07-093
Keywords: syntax, design

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


Post a followup to this message

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