CLIsh functional differences

[Lynn Scott]

After working with CLIsh for about 6 months I am very excited about
what I have found with KLISH. However, there are few minor
differences that I would really like to see in KLISH (or perhaps they
are there and I am just not aware of them).

1. In CLIsh, the PARAMS XML tag, one can specify "default="a default
value" for name=myvalue. Later in the ACTION tag, ${myvalue} is set
to the default value, if no value was entered from the cli interface.
This does not appear to be the case with KLISH. Yes one can work
around this by testing with shell script in the ACTION section, by why
the extra work on the XML coder?

2. is related to 1. above. When a user types a question mark to get
help for parameters after entering a command, only the next parameter
is shown not the entire command with all the parameters. Addtionally
in CLISH the default value is displayed in the list of parameters as
described in 1. above.

3. In CLISH when the tab key is hit with parameters a message comes
back indicating the next parameter to enter in with its PTYPE, in
KLISH nothing happens.

Are these known issues and/or are there work arounds? or are they
schedule for implementation?

Great work on this project? Thanks for doing it.

Lynn

[Serj Kalichev]

Hello.

Yes, you are right. There are some differencies in behaviour.
These are the known issues but these issues have different status.

1. (About defaults). It's planned to fix. But it's not obvious for me
what the right way to implement this feature. The original clish has
the linear list of parameters. The klish has the tree-like parameters.
See the nested parameters, "switch". So some branches can be not used
in some cases. Must it be set to defaults? Or the parameters on the
selected path only must be set? What do you think about it?

2. I think it's a right behaviour because the user wants to know what
he can enter at this moment but not all possible arguments. CISCO uses
such scheme and i agree with them. Additionally the tree-like
parameter structure (in klish) is difficult for understanding imho.
And It's difficult to display adequate help for it. However there is
the DETAIL tag for the COMMAND. In recent SVN revision it will be
displayed when the "?" is entered twice. May be it's good to display
all parameters help together with the DETAILs.

3. The are three different special chars in klish. These are <tab>,
<space> and "?". The <tab> is completion key. The space can make
completion too in some cases. The "?" is help key.
The <tab> displays all possible completions for current param, not
help. It's planned to implement options and mechanisms to set
arbitrary completions for the params. For example list of files or
other predefined values. how can it be combined with help messages? I
think it will be not good. The "?" key will display the parameter
help.

Serj

2011/3/31 Lynn Scott <roger.ly...@gmail.com>:

[Goran Grašič]

Hello,

I am missing one very important functionality.
The user does not now if he can press enter or give a parameter if there is a command preceeding.

Example (not in syntax, but you will understand)

<command = give
param = dollar>

<command = give me>


if user types 'give' and '?' it will only display "me" and it's help. The user will not know that he can also type a parameter.

Another example

<command = give
action = sth>

<command = give me
action = sth else>

Again the same issue, "give" and "?" gives only "me" and we do not know that we can press enter.

Best regards,
Goran

[Serj Kalichev]

Hi.

Please use "Reply to all" when you answer. To send copy to klish
mailing list too.

> P.S.  On a different note, please confirm that KLISH's binary results are
> clish, klish klishd.  clish is the primary binary correct?  what does klish
> do?

The main binaries is clish, konfd, konf. There is no klish, klishd binaries.
clish - the command line interface console application
konfd - daemon to store CISCO-like configuration (running-config).
konf - utility to communicate to konfd daemon

The klish is the clish's wrapper shell script only for klish examples.
It's not the main binary.

> [Lynn] some good points to this.  From an implementation standpoint I agree
> that there are some issues.  You could do a lazy initialization as the tree
> branches come into scope, however from a consumer/user of this product, my
> organization likes the defaults to be preset because we have some commands
> (that are linear) that may consist of several parameters and only a small
> subset are required while all the rest come with preset defaults that can be
> overidden by specifying them on the command line.  To have to specify or add
> logic to determine if they are set in the <ACTION></> is kinda messy
> especially if this is a multiple occurance.  Make sense?

I'm not about implementation only. The non-linear params with defaults
is more difficult to implement but it's possible. I'm trying to
explain the logical issue. For example we have the optional argument
with optional value (that have default). Like "count 5" The "count" is
optional subcommand, the "5" is optional param nested into "count".
Must it have the value if "count" is not specified at all? I't the
simplest example. I can imagine more complex examples with "switch"
that have nested param branches. Must be the params from unused
branches set to its defaults? Logically... not implementation.
And i agree that messy action is not good. It must be fixed.

> [Lynn]  I was unaware that this was Cisco type behavior.   I will give it
> some more thought.

It was my little misinformation about CISCO. I have recheck it today.
CISCO has poor <tab>. It works only when the single completion can be
detected. Else it makes <cr> only. But the "?" on parameters works
like the klish's "?". It shows only current param help. But CISCO has
no help for whole command parameters list (or i don't know how to get
it :) ).

Serj

[Serj Kalichev]

Hi

> if user types 'give' and '?' it will only display "me" and it's help. The
> user will not know that he can also type a parameter.

It was already fixed in current svn revision. Same issue for
completions was fixed too. It will be accessible in 1.4.2 version.

> Again the same issue, "give" and "?" gives only "me" and we do not know that
> we can press enter.

Yes. It's an issue. Do you like the CISCO behaviour? CISCO display
"<cr>" among a possible params when the "?" is pressed.

[Lynn Scott]

Hi Serj,

 

Thanks for all your comments and explanations.  They are very helpful. 

 

Yes, my mistake, I did mean to say konf & konfd below, not klish klishd. 

 

With respect to optional paramters, I guess you have to decide what will work best for the majority of folks who use this project.  For us, we have the situation where we have the command tree:

 

configure>foo

 

param_1

param_2

param_n

 

Param options above are optional then in action:

 

<ACTION>exec foo ${param_1} ${param_2} ${param_n}</ACTION>

 

For us we need to have the param_* arguments initialized.  I understand (generally) the issues you have raised but in our case we have written lots of XML code from the old CLIsh with this feature and it makes it difficult to port.

 

Thanks, Lynn

[Serj Kalichev]

Hi, Lynn

Probably I'll implement your variant of default values. Note that each
PARAM with "default" field will become optional automatically.

Serj

2011/4/1 Lynn Scott <roger.ly...@gmail.com>:

[Serj Kalichev]

Hello, Lynn

I have fixed the PARAM's default field behaviour.
I was wrong when say: "Note that each
PARAM with "default" field will become optional automatically." It
must not became optional automatically. For example we have ping
command with "repeat" option.

<------><------><PARAM name="repeat"
<------><------><------>help="Requests to send count, default is 5"
<------><------><------>optional="true"
<------><------><------>mode="subcommand"
<------><------><------>ptype="SUBCOMMAND">
<------><------><------><PARAM name="count"
<------><------><------><------>help="Requests count"
<------><------><------><------>ptype="UINT"
<------><------><------><------>default="5"/>
<------><------></PARAM>

The "count" PARAM is not optional but can get default value because
its parent PARAM "repeat" is optional.

So please test the svn revision 415 for default field functionality.
If it's good enough I will create a new release soon.

Serj

2011/4/1 Lynn Scott <roger.ly...@gmail.com>:

[Lynn Scott]

Hi Serj,

 

Thanks!

 

I assume I can just grap the modified source files from:

 

http://code.google.com/p/klish/source/detail?r=415

 

and just drop them in my local sandbox, build, etc and this would give me your changes regarding this feature?

 

If this is incorrect, let me know how to get your changes.

 

I will test either tonight my time or tomorrow and let you know.

 

Thanks, again.

 

Lynn

[Serj Kalichev]

See the http://code.google.com/p/klish/source/checkout for details how
to get specified SVN revision. Don't use diff from
http://code.google.com/p/klish/source/detail?r=415 because it doesn't
contain previous changes since stable release.

svn checkout http://klish.googlecode.com/svn/trunk/ klish-read-only -r 415

Serj

2011/4/12 Lynn Scott <roger.ly...@gmail.com>:

[Lynn Scott]

Okay thanks.

[Serj Kalichev]

2011/4/1 Goran Grašič <goran....@gmail.com>:

> Hello,
>
> I am missing one very important functionality.
> The user does not now if he can press enter or give a parameter if there is
> a command preceeding.

The help with possible "<cr>" was implemented in svn revision 417.

[Lynn Scott]

Hi Serj,

 

I finally attempted to test this by pulling down the source and building it.  The steps I took were to get the source, create an archive (*.tar.bz2), copy the archive into my environment and make.  I kept running into problems like have to set permissions to execute on configure and other .sh files.  Shouldn't they be checked in with the required permssions set?

 

I ended up having troubles getting it to build but gave up because Make said I was missing to .h files.  Question is ifi I could build 1.4.1 shouldn't I be able to build this release?

 

Second question, does 1.4.2 contain these changes that you did in this release?  If so that would be great.  However I couldn't get this one to build either.  I didn't have permission issues like I did in the test sandbox you referred me to, but with this build I get the following error:

 

/shell/shell_tinyrl.c  -fPIC -DPIC -o clish/shell/.libs/libclish_la-shell_tinyrl.o
clish/shell/shell_tinyrl.c: In function 'clish_shell_execline':
clish/shell/shell_tinyrl.c:414: error: 'ENODATA' undeclared (first use in this function)
clish/shell/shell_tinyrl.c:414: error: (Each undeclared identifier is reported only once
clish/shell/shell_tinyrl.c:414: error: for each function it appears in.)
*** Error code 1

Is ENODATA a posix or system define?  I am running the following:

 

uname -a
FreeBSD build8064 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009     ro...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

 

Thanks, Lynn

[Serj Kalichev]

Hi

Use klish-1.4.2. It contains these changes.
The ENODATA is a possible value of errno. (See 'man errno'). The
errno.h is included into the shell_tinyrl.c. The errno.h must contain
this define. The manpage says that ENODATA is POSIX. It's strange for
me that FreeBSD has no ENODATA. Can you check FreeBSD headers for the
ENODATA and other possible errno values? If there is no ENODATA i will
choose another errno value to indicate the problem.

I have no FreeBSD installed so it's hard for me to test klish on it.

2011/4/24 Lynn Scott <roger.ly...@gmail.com>:

[Serj Kalichev]

By the way, do you have the FreeBSD computer connected to internet? I
can test klish building before any release if I'll get an user account
on any FreeBSD machine. I'm interested in klish portability.

2011/4/24 Lynn Scott <roger.ly...@gmail.com>:

[Lynn Scott]

Yeah sorry on both accounts.  The FreeBSD machine I have access has restricted access to.  The best I could offer is a VMware VM on my home Windows 7 system that connects via Comcast.  So let me know if that would help.

 

Also, I checked /usr/include/errno.h and it does *not* contain the ENODATA define.

 

Any suggestsions?

 

Thanks, Lynn

[Lynn Scott]

P.S.  In the meantime I defined a value for ENODATA so I could get the klish project to build on FreeBSD 80 and was successful.

 

I also tried out the default="MyDefaultValue" and default *was* defined in the <ACTION></ACTION> section as desired, so thank you very much.

 

Let me know if you have any solutions for the ENODATA build issue.

 

Lynn

[Serj Kalichev]

Hi

Probably I'll install a FreeBSD into VirtualBox and try to compile klish.

2011/4/25 Lynn Scott <roger.ly...@gmail.com>:

[Serj Kalichev]

Hi

The BSD bug and warnings were fixed. Use 1.4.3 version.

Serj Kalichev

2011/4/25 Lynn Scott <roger.ly...@gmail.com>:

[Lynn Scott]

Thanks Serg!  I'll give it a shot.