[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] Command Line Interpreter Enhancements
From:       "Ben Rafanello" <benr () us ! ibm ! com>
Date:       2002-06-14 23:49:43
[Download RAW message or body]




On Fri, Jun 14, 2002 at 11:50AM, Matt Zimmerman wrote:

>> On Wed, Jun 12, 2002 at 07:02PM, Matt Zimmerman wrote:
>> >However, thanks to the modular design of EVMS, it wouldn't be hard to
>> >create, for example, a Python module which presented the EVMS API,
which
>> >could then be used to easily write programs to perform EVMS operations.
>>
>> I don't know much about Python, but I like the idea very much!  I'll
have
>> to look into this.  This may well negate any need for adding conditional
>> and iterative statements, as well as variables, to the CLI.
>
>In that case, I'll see if I can put something together to demonstrate the
>concept.  I have a number of ideas about how it would fit together.

I would be very interested in seeing what you have in mind.

>> >I have in mind a level of functionality similar to what is provided by
>> >Cisco IOS or the text-based MySQL client.
>>
>> I am not familiar with either of those.  I will have to take a look at
>> them to see the level of functionality provided and how hard that would
be
>> to do inside of the CLI.
>
>I can provide some examples then.  Here some examples from a session on a
>Cisco Catalyst switch running IOS:
>
>CAT-01#show ?
>  access-lists       List access lists
>  accounting         Accounting data for active sessions
[...]
>  vtp                VTP information
>
>CAT-01#show
>
?Typing '?' immediately displayed a list of possible 'show' commands, and
>left me back where I started in editing the command line.  I'll abbreviate
>places where I press [TAB] below as such.

I can probably adapt the parser to handle the ? in a fashion similar to
what you showed.  I could treat the ? as if it was a part of the grammar
and cause the message put out when it is encountered to be a list of the
possible keywords that could be put there.  This works for everything
which is not "plug-in" defined, such as the names for <Name Value Pair>
constructs, which must be obtained from the plug-in referenced in the
command.  This is where life gets interesting.  In order to get the
possible values from the plug-in, an EVMS task must be started.  This
requires code which currently resides in the interpreter.  Creating the
task is the first step in actually executing the command.  Thus, elements
of the interpreter must be available to the parser.

>CAT-01#show int[TAB]
>CAT-01#show interfaces
>CAT-01#show interfaces faste[TAB]
>CAT-01#show interfaces fastethernet ?
>
>  <0-2>  FastEthernet interface number
[...]

>Here's a MySQL example:
>
>mysql> cre[TAB]
>create database  create table
>mysql> create
[...]
>
>As you can see, not only does this save a lot of typing, it makes tools
much
>easier to learn and use.  If the user doesn't remember a specific command
>option, etc., it can easily be seen in a completion list, especially if it
>gives descriptive help as IOS does.

>The readline library provides the UI glue to do most of this for free,
>including allowing the user to specify custom preferences.  The
application
>supplies a list of possible words based on a partial command line, via a
>callback function.

There are two main problems to be solved in order to do this.  The first
is that the CLI grammar requires lookahead to be parsed.  There are many
places in the grammar where optional parameters are used.  This gets
particularly interesting when the optional parameters are at the end
of a command.  Since the CLI allows multiple commands on a single command
line, lookahead is used to determine if you have an optional parameter
or the start of a new command.  What do we offer for completion here?
Or do we restrict the user to one command per command line?  This has
implications for command files.  Right now, the parser sees command files
as one long command line.  This allows commands to be formatted however the
user wants in a command file.  If we start introducing limitations on the
number of commands per command line, then we could break existing command
files.  To get around this, we would have to make the parser aware of the
input source so that it could deal appropriately with input from a command
file or input from an interactive session.

Lookahead is also used to determine the type of parameters, such as for an
expand command, where <Name Value Pairs> are followed by the name of an
EVMS
object to be used for the actual expansion.  In order to tell that a token
is a name for a <Name Value Pair> or the name of an object to use for the
expansion requires lookahead.  This also affects what command completions
you would have to offer.  If you don't know if the token is a name for a
<Name Value Pair> or the name of an object, you might have to offer both
possible completions, which could be interesting.  In order to get the
names of options for the <Name Value Pairs> you need to create an EVMS task
and query the appropriate plug-in.  You need to do something similar to get
the acceptable objects.

The second problem is that the plug-in modules actually define what would
be "keywords" in a programming language.  The plug-in modules define the
names used in <Name Value Pairs>.  The plug-in modules also decide what
objects are acceptable for what operations, and this is context sensitive.
The problem also gets worse in that, with multiple commands on a command
line it is possible that several objects used in previous commands
(and which should not be available anymore) will be presented for use
in the current command.

I can see ways to deal with the plug-ins, and if we make the parser aware
of the input source and then limit interactive sessions to one command
per command line, then I can almost see my way through this to a
solution.  Where I am fuzzy is on how to deal with the lookahead issue.
I need to think about that some more.

[...]

>I can certainly appreciate how the plugins would complicate the situation,
>the overall progress that has been made with EVMS, and the length of your
>current "to do" list.  I am willing to assistance as I am able, with the
>limited resources that I can devote to the project.

Thank you for offering to help!  I will take all the help I can get!!! :-)


Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel
[prev in list] [next in list] [prev in thread] [next in thread]