Bugfix: Cli parseArg

[KSR-Yasuda]

Fix #30

[KSR-Yasuda]

  if (/^-(.)([^=]*?)(=(.*))?$/.test(arg)) {
    var opt = RegExp.$1;
    var val = options[opt] && !options[opt].hasArg
                ? true
                : (RegExp.$3
                    ? RegExp.$4
                    : RegExp.$2 ||
                      (!nextArg || /^-/.test(nextArg) ? '' : nextArg));

val is,

• true, if the option does not require arg (options[opt] && !options[opt].hasArg ? true)
• or, string following = (RegExp.$3 ? RegExp.$4)
• or, string following option first char (RegExp$2)
• or, next argument
• or, empty string (!nextArg || /^-/.test(nextArg) ? '')

[bermi]

@KSR-Yasuda 2.3.2 has now the solution to #30 by just defaulting nextArg to true. Is this PR addressing other edge cases that you've encountered?

[KSR-Yasuda]

As I wrote in #30,
I intended to

• set true, for switch options (such as -h)
• set a string value, for options that requires arguments (such as -l <LENGTH>)

For now, it may be too much.