Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for a Java like parser mode #7

Open
HaasJona opened this issue Feb 18, 2017 · 2 comments
Open

Add support for a Java like parser mode #7

HaasJona opened this issue Feb 18, 2017 · 2 comments

Comments

@HaasJona
Copy link

HaasJona commented Feb 18, 2017

It would be nice to have a parser mode which parses all arguments as long arguments regardless of the amount of dashes, so you could have a parser that parses like typical java applications (for example consider java -version).

@xenomachina
Copy link
Owner

Thanks for the suggestion. Any ideas on how option names would be specified? Right now you include the dashes, like:

val verbose by parser.flagging("-v", "--verbose",

Would the client instead have to say "-verbose", or would or would "--verbose" be transformed into "-verbose"?

Also, right now it's also possible (though arguably inadvisable) to have single letter "long" options:

val short_a by parser.flagging("-a", ... 
val long_a by parser.flagging("--a", ...

I'm thinking this would be an error in a Java flag mode.

I'm not entirely clear on how option arguments are handled with Java-style options. Looking at the options of java, some, like -ea, -splash, seem to require an intervening colon, while others do not (-X, -D). It looks like it may be the case that long options use the colon, while short options do not, which is kind of similar tow how POSIX and GNU style options work, except they use "=" rather than ":" for long option arguments.

One thing I'm not sure how to resolve is that Java style options seem to let the option decide whether the first of its arguments must be in the same argument, as in -agentpath, or as a separate command line argument, as in -cp. In kotlin-argparser these would both be storing long options, and there is nowhere for the client to indicate this distinction. I'm inclined to just make it impossible to exactly emulate the options of java. So -cp:CLASSPATH would become legal, as would -agentpath AGENTPATH.

Playing around with this actually made me realize that there's a small bug with the existing parsing in that you cannot create an option that non-greedily takes an optional argument, like the -version option of java. I filed issue #8 about this.

@HaasJona
Copy link
Author

Would the client instead have to say "-verbose", or would or would "--verbose" be transformed into "-verbose"?

I'd vote for

val verbose by parser.flagging("-v", "-verbose", ...)

or if you don't need/want the short form simply

val verbose by parser.flagging("-verbose", ...)

Main difference would be to always go into the first if branch here if Java mode is active and only one dash is there: https://github.com/xenomachina/kotlin-argparser/blob/master/src/main/kotlin/ArgParser.kt#L434

I'm not entirely clear on how option arguments are handled with Java-style options.

I'd keep it simple for now. Java isn't necessarily super consistent here. I'd personally only need this:

-a
-b -test -file=foo.txt
-abc=def variable1 variable2

no weird colons and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants