Expand options to support short and long names

[ahonor]

Extend option metadata to support more kinds of option processing, specifically supporting short and long option names.

Proposed metadata:

• name of option
• description of option
• arg label for short option - optional
• long option - optional
• arg label for long option - optional
• type of argument (string or boolean) - optional (default=string)
• range for the argument - optional
• name of variable to expose option - optional

[noahcampbell]

What if you defer to the rules defined by getopt (http://www.gnu.org/s/hello/manual/libc/Getopt.html) or getopts (doesn't support long args)?

On Sun, Sep 25, 2011 at 10:55 PM, Alex Honor reply@reply.github.com wrote:

Extend option metadata to support more kinds of option processing, specifically supporting short and long option names.

Proposed metadata:

• name of option
• description of option
• arg label for short option - optional
• long option - optional
• arg label for long option - optional
• type of argument (string or boolean) - optional (default=string)
• range for the argument - optional
• name of variable to expose option - optional

Reply to this email directly or view it on GitHub: https://github.com/dtolabs/rerun/issues/4

[ahonor]

I briefly tried both getopt(s) and in the end felt it was too constrained.

[ahonor]

Note mlei's ticket #1 (Explicit false boolean antonyms).

[spiette]

Would you mind elaborate on getopt(s) being too constrained? Some reasons come to my mind: 1) portability, as gnu getopt is not available on osx or freebsd 2) limited functionnality of getopts

[spiette]

I think a first step would be to have the current long options take a double dash in front of them (instead of one). It would be more like most commands. But it would break most existing script using rerun commands. Better to do that sooner than later i guess.

[ahonor]

I agree. We should make long options take a double dash and since it's at the early stage let's not worry about breaking 0.1 versions.