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/ |
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:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
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/ |
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/ |
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:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
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/ |
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:
--
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 |
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/ |
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/ |
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/ |
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 ' |
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/ |
Free forum by Nabble | Edit this page |