Re: CLI - auto-generated usage message anyone?
Hi, Yes I understand, I mean does not interpret doe's not executes user defined actions then parses command line. May be I wrong, but I don't see any interface for this. It is not very priority. I can do it myself in my application like in this pseudo language: Loop option in AllOptions Handler h = findByOption(option);// option mapped to handler, my be to some predefined h.handle(option); End It is very usual in simple situations ( then we don't need look ahead ) and can be implemented in CLI. It can be useful in trivial situations : mytool -locale LT -license -help readme.txt If you don't understand me, forget this I can always to do in application, it is not very useful for me, I see it useful for some users . At 04:37 AM 1/29/2002 -0800, you wrote: Hi, What do you mean by CLI does not interpret cmd? Now for the option types let me see what we could imagine to have a complete list: 1. -a, --aaa - no additional argument needed 2. -a xxx, -aaa xxx - additional argument needed 3. xxx - only argument All of those should be either required or optional. Finally you should be able to say: [-a|-b xx|-c xx] -d [-e xx] (-f xx|-g xx) yyy This means that: - the first group [...] is optional but if specified must be one of options in brackets - -d is mandatory - -e has argument and is optional - -f or -g is mandatory but only one can be specified - finally yyy is argument without option. I think that it should be possible to check if the conditions above are satisfied. Any thoughts on that? Best Regards, Slawek --- Juozas Baliuka [EMAIL PROTECTED] wrote: Hi, I have suggestion for CLI. CLI does not interpret cmd and It is good. But I think it can be useful to add some CallBack interface and use it in this way: options.addPredefinedOptions( optionArrayOrSomeFilter ); options.addOption(myOption,myHandler); .. options.parse( args);//invokes my handler, then finds option in cmd it is possible to implement some samples or helpers or handlers for standard or predefined options like help At 02:10 AM 1/29/2002 -0800, you wrote: Hi, I was wondering what do you think if CLI were able (or maybe is already :-) ) to automatically generate some sort of usage: ... message - something you get when doing: man -h. Also, does CLI support sub-groups of options, for example: [-c|-f|-k|-w|-tZT device] - all being mutually exclusive? Cheers, Slawek __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: CLI - auto-generated usage message anyone?
HI,
Yes it is not very good idea and can be useful only for trivial situations.
At 07:06 AM 1/29/2002 -0800, you wrote:
Well,
With the handler approach CLI would become a kind of
command controller/dispacher. Is it what we shoot for?
If you have a way to specify a handler for an option
what happens if you have several options - each with
it's own handler :-)))???
My feeling is that CLI should validate (as far as
possible) if the command line is correct (good
options/combinations of options) and give access to
the command line elements but the application specific
job should be done by the application itself using the
provided options.
Cheers,
Slawek
--- bob mcwhirter [EMAIL PROTECTED] wrote:
On Tue, 29 Jan 2002, Slawek Zachcial wrote:
Hi,
What do you mean by CLI does not interpret cmd?
I assume the equivelent of:
cvs -dfoo commit
He'd like to bind 'commit' (the cmd) to a particular
Command callback, or similar. Personally, I like
the idea, and have implemented similar things on top
of werken.opt/CLI in the past, but haven't
integrated
it into actual werken.opt/CLI codebase.
I think that it should be possible to check if the
conditions above are satisfied.
Any thoughts on that?
I bounced around some thoughts on mutually exclusive
options, but didn't come up with anything
generically
useful. There's the potential for combinatorial
explosion, when specifying combinations of options.
ie, you can only pick one of { -A, -B, -C }, but if
you depending on what you pick at that level, you
may have different options available to you.
ie, valid combinations might be:
-A -aa -ab -ac
-B -ba -bb -bc
-C -ca -cb -cc
In this regard, mutual exclusion between {-A, -B,
-C},
but also between an option and complete sub-option
groups.
Could get hairy.
It certainly would benefit the world to have that
ability,
but I personally wasn't up to the task to figure out
a
great implementation a year ago when I originally
wrote it
all.
-bob
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: CLI - auto-generated usage message anyone?
Hi, What do you mean by CLI does not interpret cmd? Now for the option types let me see what we could imagine to have a complete list: 1. -a, --aaa - no additional argument needed 2. -a xxx, -aaa xxx - additional argument needed 3. xxx - only argument All of those should be either required or optional. Finally you should be able to say: [-a|-b xx|-c xx] -d [-e xx] (-f xx|-g xx) yyy This means that: - the first group [...] is optional but if specified must be one of options in brackets - -d is mandatory - -e has argument and is optional - -f or -g is mandatory but only one can be specified - finally yyy is argument without option. I think that it should be possible to check if the conditions above are satisfied. Any thoughts on that? Best Regards, Slawek --- Juozas Baliuka [EMAIL PROTECTED] wrote: Hi, I have suggestion for CLI. CLI does not interpret cmd and It is good. But I think it can be useful to add some CallBack interface and use it in this way: options.addPredefinedOptions( optionArrayOrSomeFilter ); options.addOption(myOption,myHandler); .. options.parse( args);//invokes my handler, then finds option in cmd it is possible to implement some samples or helpers or handlers for standard or predefined options like help At 02:10 AM 1/29/2002 -0800, you wrote: Hi, I was wondering what do you think if CLI were able (or maybe is already :-) ) to automatically generate some sort of usage: ... message - something you get when doing: man -h. Also, does CLI support sub-groups of options, for example: [-c|-f|-k|-w|-tZT device] - all being mutually exclusive? Cheers, Slawek __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: CLI - auto-generated usage message anyone?
On Tue, 29 Jan 2002, Slawek Zachcial wrote:
Hi,
What do you mean by CLI does not interpret cmd?
I assume the equivelent of:
cvs -dfoo commit
He'd like to bind 'commit' (the cmd) to a particular
Command callback, or similar. Personally, I like
the idea, and have implemented similar things on top
of werken.opt/CLI in the past, but haven't integrated
it into actual werken.opt/CLI codebase.
I think that it should be possible to check if the
conditions above are satisfied.
Any thoughts on that?
I bounced around some thoughts on mutually exclusive
options, but didn't come up with anything generically
useful. There's the potential for combinatorial
explosion, when specifying combinations of options.
ie, you can only pick one of { -A, -B, -C }, but if
you depending on what you pick at that level, you
may have different options available to you.
ie, valid combinations might be:
-A -aa -ab -ac
-B -ba -bb -bc
-C -ca -cb -cc
In this regard, mutual exclusion between {-A, -B, -C},
but also between an option and complete sub-option groups.
Could get hairy.
It certainly would benefit the world to have that ability,
but I personally wasn't up to the task to figure out a
great implementation a year ago when I originally wrote it
all.
-bob
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
