commandline parser

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

commandline parser

KP Kirchdörfer

Hello gents;

 

I know how to parse a commandline in a "dumb" way.

The command has to start with two dashes, and the sort order of the commands is important.

This is something to start, but still not good enough :)

 

Has anyone written a commandline parser that is not bound to the sort order and preferably supports short and long options?

 

thx kp


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

Kermit Kiser
I am not clear on what you want to do. Can you give examples of the command formats you wish to support and maybe an idea what you want to do with the result?

Offhand, I usually do something like this when operands can vary in order:

if arg.pos("--option") >0 then handleoption

or if you need to record the order of the operands:

optionposition=arg.wordpos("--option")


-- Kermit


On 9/12/2011 1:24 PM, KP Kirchdoerfer wrote:

Hello gents;

 

I know how to parse a commandline in a "dumb" way.

The command has to start with two dashes, and the sort order of the commands is important.

This is something to start, but still not good enough :)

 

Has anyone written a commandline parser that is not bound to the sort order and preferably supports short and long options?

 

thx kp

_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

KP Kirchdörfer

Am Montag, 12. September 2011, 23:24:38 schrieben Sie:

> I am not clear on what you want to do. Can you give examples of the

> command formats you wish to support and maybe an idea what you want to

> do with the result?

>

> Offhand, I usually do something like this when operands can vary in order:

>

> if arg.pos("--option") >0 then handleoption

>

> or if you need to record the order of the operands:

>

> optionposition=arg.wordpos("--option")

>

>

> -- Kermit

 

Currently I have something like this:

 

method main(args=String[]) public static

do

arg=rexx(args)

if arg='' then say "Missing argument - run --help"

loop while arg <>''

parse arg command arg

if command.substr(1,2)='--' then do

parse arg var arg

if command='--argument1' then argument1=var

if command='--help'

then do

say "available commands:"

say "--argument1 - value of argument1"

say "--help - shows this screen"

exit

end --then do

end --then do

 

This way it is unflexible.

I'll look into your proposal. Varying order is for shure an improvement.

 

The second part of the question is, how can I support the long form "--option" together with the short one "-o".

 

Anyway I've got the idea.

 

thx for your help

kp

 

 

> On 9/12/2011 1:24 PM, KP Kirchdoerfer wrote:

> > Hello gents;

> >

> > I know how to parse a commandline in a "dumb" way.

> >

> > The command has to start with two dashes, and the sort order of the

> > commands is important.

> >

> > This is something to start, but still not good enough :)

> >

> > Has anyone written a commandline parser that is not bound to the sort

> > order and preferably supports short and long options?

> >

> > thx kp

> >

> >

> > _______________________________________________

> > Ibm-netrexx mailing list

> > [hidden email]

> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

 

 


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

rickmcguire
I suggest checking out the Commons CLI library.  Very flexible parsing support.

http://commons.apache.org/cli/usage.html

Rick

On Mon, Sep 12, 2011 at 5:52 PM, KP Kirchdoerfer
<[hidden email]> wrote:

> Am Montag, 12. September 2011, 23:24:38 schrieben Sie:
>
>> I am not clear on what you want to do. Can you give examples of the
>
>> command formats you wish to support and maybe an idea what you want to
>
>> do with the result?
>
>>
>
>> Offhand, I usually do something like this when operands can vary in order:
>
>>
>
>> if arg.pos("--option") >0 then handleoption
>
>>
>
>> or if you need to record the order of the operands:
>
>>
>
>> optionposition=arg.wordpos("--option")
>
>>
>
>>
>
>> -- Kermit
>
>
>
> Currently I have something like this:
>
>
>
> method main(args=String[]) public static
>
> do
>
> arg=rexx(args)
>
> if arg='' then say "Missing argument - run --help"
>
> loop while arg <>''
>
> parse arg command arg
>
> if command.substr(1,2)='--' then do
>
> parse arg var arg
>
> if command='--argument1' then argument1=var
>
> if command='--help'
>
> then do
>
> say "available commands:"
>
> say "--argument1 - value of argument1"
>
> say "--help - shows this screen"
>
> exit
>
> end --then do
>
> end --then do
>
>
>
> This way it is unflexible.
>
> I'll look into your proposal. Varying order is for shure an improvement.
>
>
>
> The second part of the question is, how can I support the long form
> "--option" together with the short one "-o".
>
>
>
> Anyway I've got the idea.
>
>
>
> thx for your help
>
> kp
>
>
>
>
>
>> On 9/12/2011 1:24 PM, KP Kirchdoerfer wrote:
>
>> > Hello gents;
>
>> >
>
>> > I know how to parse a commandline in a "dumb" way.
>
>> >
>
>> > The command has to start with two dashes, and the sort order of the
>
>> > commands is important.
>
>> >
>
>> > This is something to start, but still not good enough :)
>
>> >
>
>> > Has anyone written a commandline parser that is not bound to the sort
>
>> > order and preferably supports short and long options?
>
>> >
>
>> > thx kp
>
>> >
>
>> >
>
>> > _______________________________________________
>
>> > Ibm-netrexx mailing list
>
>> > [hidden email]
>
>> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

Kermit Kiser
In reply to this post by KP Kirchdörfer
From your code sample it looks like your command format has flags identified by "--" and followed by a value.

If that is the only operand format and you want a general purpose parse for it that is independent of the actual operands and their order, I would do something like this:

flagdata=""

-- save command data

loop i=1 to arg.words-1
    if arg.word(i).left(2) = "--" then flagdata[arg.word(i).substr(3)]=arg.word(i+1)
    end

-- process command data
   
loop flagword over flagdata
    say flagword "=" flagdata[flagword]
    end


If you need to change short commands to long ones, set up a map like this (you can do it with one string but two is a little easier):

incmds = 'option o argument1 a1'
outcmds = 'option option argument1 argument1'

then you can map the input operands to the full ones like this, assuming flagword contains the input operand:

trueflagword=outcmds.word(incmds.wordpos(flagword))


-- KK
               

On 9/12/2011 2:52 PM, KP Kirchdoerfer wrote:

Am Montag, 12. September 2011, 23:24:38 schrieben Sie:

> I am not clear on what you want to do. Can you give examples of the

> command formats you wish to support and maybe an idea what you want to

> do with the result?

>

> Offhand, I usually do something like this when operands can vary in order:

>

> if arg.pos("--option") >0 then handleoption

>

> or if you need to record the order of the operands:

>

> optionposition=arg.wordpos("--option")

>

>

> -- Kermit

 

Currently I have something like this:

 

method main(args=String[]) public static

do

arg=rexx(args)

if arg='' then say "Missing argument - run --help"

loop while arg <>''

parse arg command arg

if command.substr(1,2)='--' then do

parse arg var arg

if command='--argument1' then argument1=var

if command='--help'

then do

say "available commands:"

say "--argument1 - value of argument1"

say "--help - shows this screen"

exit

end --then do

end --then do

 

This way it is unflexible.

I'll look into your proposal. Varying order is for shure an improvement.

 

The second part of the question is, how can I support the long form "--option" together with the short one "-o".

 

Anyway I've got the idea.

 

thx for your help

kp

 

 

> On 9/12/2011 1:24 PM, KP Kirchdoerfer wrote:

> > Hello gents;

> >

> > I know how to parse a commandline in a "dumb" way.

> >

> > The command has to start with two dashes, and the sort order of the

> > commands is important.

> >

> > This is something to start, but still not good enough :)

> >

> > Has anyone written a commandline parser that is not bound to the sort

> > order and preferably supports short and long options?

> >

> > thx kp

> >

> >

> > _______________________________________________

> > Ibm-netrexx mailing list

> > [hidden email]

> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

 

 

_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

billfen
In reply to this post by KP Kirchdörfer
kp,

I don't think the question can be meaningfully answered until the detailed
syntax of a "command line" is specified.  Try BNF or equivalent, or a
specific and unambiguous set of rules.

For example, can options consist of something like:  -f "file\"name"  ?  
or  -F file1  file2  -z ? It could make a significant difference in the
approach.

As for a general strategy, you can break the line into a set of keys and
key / value pairs, and then use another routine to search that set to
retrieve keys and values, or you might use a general method which searches
for a specified key and removes it from the text and returns it, optionally
with a value.  Or you could use separate methods to search for a single
option (and value) or synonym and remove it from the string.  I'm sure
there are other approaches as well.

There are usually numerous ways to solve problems, but until the problem is
clearly defined, specifying algorithms prematurely may not be useful.  One
change or overlooked detail in the format of the command string could
invalidate a lot of work.


--------------------------------------------------------------------
mail2web.com – Enhanced email for the mobile individual based on Microsoft®
Exchange - http://link.mail2web.com/Personal/EnhancedEmail



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

ThSITC
In reply to this post by KP Kirchdörfer
Hello KP, and all,

   I have written a programmable Scanner (Tokenizer) and Parser(various Languages) in NetRexx.

   I'm about to release this code.

   When you would have IMMEDIATE need, send me a private mail, and I could forward the proper libraries (and sources as well) to you.

   I'm still busy with the documentation, however.

Thomas Schneider.
=========================================================== 
Am 12.09.2011 22:24, schrieb KP Kirchdoerfer:

Hello gents;

 

I know how to parse a commandline in a "dumb" way.

The command has to start with two dashes, and the sort order of the commands is important.

This is something to start, but still not good enough :)

 

Has anyone written a commandline parser that is not bound to the sort order and preferably supports short and long options?

 

thx kp



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



--
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com
Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

KP Kirchdörfer
In reply to this post by Kermit Kiser

Am Dienstag, 13. September 2011, 03:58:39 schrieben Sie:

> From your code sample it looks like your command format has flags

> identified by "--" and followed by a value.

>

> If that is the only operand format and you want a general purpose

> parse for it that is independent of the actual operands and their

> order, I would do something like this:

>

> flagdata=""

>

> -- save command data

>

> loop i=1 to arg.words-1

> if arg.word(i).left(2) = "--" then

> flagdata[arg.word(i).substr(3)]=arg.word(i+1)

> end

>

> -- process command data

>

> loop flagword over flagdata

> say flagword "=" flagdata[flagword]

> end

>

>

> If you need to change short commands to long ones, set up a map

> like this (you can do it with one string but two is a little

> easier):

>

> incmds = 'option o argument1 a1'

> outcmds = 'option option argument1 argument1'

>

> then you can map the input operands to the full ones like this,

> assuming flagword contains the input operand:

>

> trueflagword=outcmds.word(incmds.wordpos(flagword))

>

>

> -- KK

 

Thx for all responses - I see it's something complicated :)

 

Kermits response works for the time being...

 

http://commons.apache.org/cli/usage.html is for shure interesting.

 

thx again

kp

 

 


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

Aviatrexx
In reply to this post by billfen
At one point I wrote an OS/2 Rexx version of the Unix 'getops' command
that sounds like what you are looking for, Kermit.

It involved an associative stem array using the name of each valid
flag as the element, and the value of that flag's entry was either a
boolean or the value associated with the keyword.  Flag abbreviations
were handled by Abbrev() of course, and it handled the 'dash-flag'
(--).  IIRC, it was not the complete Korn shell implementation because
some of the features weren't applicable, but it certainly made
processing boolean flags and keyword/value pairs in an arbitrary order
much easier.

Doubt if I could retrieve it at this point, but re-creating it might
make an interesting diversion from real work one of these days.

-Chip-

On 9/13/11 03:02 [hidden email] said:

> kp,
>
> I don't think the question can be meaningfully answered until the detailed
> syntax of a "command line" is specified.  Try BNF or equivalent, or a
> specific and unambiguous set of rules.
>
> For example, can options consist of something like:  -f "file\"name"  ?  
> or  -F file1  file2  -z ? It could make a significant difference in the
> approach.
>
> As for a general strategy, you can break the line into a set of keys and
> key / value pairs, and then use another routine to search that set to
> retrieve keys and values, or you might use a general method which searches
> for a specified key and removes it from the text and returns it, optionally
> with a value.  Or you could use separate methods to search for a single
> option (and value) or synonym and remove it from the string.  I'm sure
> there are other approaches as well.
>
> There are usually numerous ways to solve problems, but until the problem is
> clearly defined, specifying algorithms prematurely may not be useful.  One
> change or overlooked detail in the format of the command string could
> invalidate a lot of work.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

Kermit Kiser
Chuckle! I write Android applications, Chip - I am not looking for any
command line parsers. The original question was from kp who has quite
startled me by declaring it a "complicated" problem. I would consider
any kind of parsing to be almost trivial in NetRexx because it is so
powerful.

--KK

On 9/13/2011 11:47 AM, Chip Davis wrote:

> At one point I wrote an OS/2 Rexx version of the Unix 'getops' command
> that sounds like what you are looking for, Kermit.
>
> It involved an associative stem array using the name of each valid
> flag as the element, and the value of that flag's entry was either a
> boolean or the value associated with the keyword.  Flag abbreviations
> were handled by Abbrev() of course, and it handled the 'dash-flag'
> (--).  IIRC, it was not the complete Korn shell implementation because
> some of the features weren't applicable, but it certainly made
> processing boolean flags and keyword/value pairs in an arbitrary order
> much easier.
>
> Doubt if I could retrieve it at this point, but re-creating it might
> make an interesting diversion from real work one of these days.
>
> -Chip-
>
> On 9/13/11 03:02 [hidden email] said:
>> kp,
>>
>> I don't think the question can be meaningfully answered until the
>> detailed
>> syntax of a "command line" is specified.  Try BNF or equivalent, or a
>> specific and unambiguous set of rules.
>>
>> For example, can options consist of something like:  -f "file\"name"  
>> ?  or  -F file1  file2  -z ? It could make a significant difference
>> in the
>> approach.
>>
>> As for a general strategy, you can break the line into a set of keys and
>> key / value pairs, and then use another routine to search that set to
>> retrieve keys and values, or you might use a general method which
>> searches
>> for a specified key and removes it from the text and returns it,
>> optionally
>> with a value.  Or you could use separate methods to search for a single
>> option (and value) or synonym and remove it from the string.  I'm sure
>> there are other approaches as well.
>>
>> There are usually numerous ways to solve problems, but until the
>> problem is
>> clearly defined, specifying algorithms prematurely may not be
>> useful.  One
>> change or overlooked detail in the format of the command string could
>> invalidate a lot of work.
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

measel
In reply to this post by KP Kirchdörfer
Not the answer to your question but have you considered using a properties file rather than command line switches ?

Properties files are quite easy to use and even as much as I like a good parse, much simpler to implement.

sample:


/* get properties */
do
        aternprop = Properties()
       
        propinput = FileInputStream("aternity.properties") /* our properties file name */
        aternprop.load(propinput)
        debug_flag = aternprop.getProperty("config.debug")
        if debug_flag then say '================>>>  aternity 5 poller debugging enabled '
Reply | Threaded
Open this post in threaded view
|

Re: commandline parser

Aviatrexx
In reply to this post by Kermit Kiser
Oops!  Sorry about the mis-attribution of Kermit as the OP.  I should
have directed my response to KP, not KK.

-Chip-

On 9/13/11 19:41 Kermit Kiser said:

> Chuckle! I write Android applications, Chip - I am not looking for any
> command line parsers. The original question was from kp who has quite
> startled me by declaring it a "complicated" problem. I would consider
> any kind of parsing to be almost trivial in NetRexx because it is so
> powerful.
>
> --KK
>
> On 9/13/2011 11:47 AM, Chip Davis wrote:
>> At one point I wrote an OS/2 Rexx version of the Unix 'getops' command
>> that sounds like what you are looking for, Kermit.
>>
>> It involved an associative stem array using the name of each valid
>> flag as the element, and the value of that flag's entry was either a
>> boolean or the value associated with the keyword.  Flag abbreviations
>> were handled by Abbrev() of course, and it handled the 'dash-flag'
>> (--).  IIRC, it was not the complete Korn shell implementation because
>> some of the features weren't applicable, but it certainly made
>> processing boolean flags and keyword/value pairs in an arbitrary order
>> much easier.
>>
>> Doubt if I could retrieve it at this point, but re-creating it might
>> make an interesting diversion from real work one of these days.
>>
>> -Chip-
>>
>> On 9/13/11 03:02 [hidden email] said:
>>> kp,
>>>
>>> I don't think the question can be meaningfully answered until the
>>> detailed
>>> syntax of a "command line" is specified.  Try BNF or equivalent, or a
>>> specific and unambiguous set of rules.
>>>
>>> For example, can options consist of something like:  -f "file\"name"  
>>> ?  or  -F file1  file2  -z ? It could make a significant difference
>>> in the
>>> approach.
>>>
>>> As for a general strategy, you can break the line into a set of keys and
>>> key / value pairs, and then use another routine to search that set to
>>> retrieve keys and values, or you might use a general method which
>>> searches
>>> for a specified key and removes it from the text and returns it,
>>> optionally
>>> with a value.  Or you could use separate methods to search for a single
>>> option (and value) or synonym and remove it from the string.  I'm sure
>>> there are other approaches as well.
>>>
>>> There are usually numerous ways to solve problems, but until the
>>> problem is
>>> clearly defined, specifying algorithms prematurely may not be
>>> useful.  One
>>> change or overlooked detail in the format of the command string could
>>> invalidate a lot of work.
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/