Improve command line parsing utils to accept strings

[chuggafan]

I think the title speaks for itself, it currently cannot handle strings as command line options when it really, really should and needs to if you want to have more than 13 (nonconfusing) unique commands.

[LADSoft]

do you mean quoted strings? Or do you mean using something more verbose than the simple one-character switches that everything uses?

[chuggafan]

More verbose than one character switches

[LADSoft]

this is probably going to happen this weekend, in conjunction with setting up for #330. Probably what I'll do is just extend the current design to allow for more verbosity while leaving the original design intact; then as time goes by we can migrate to using more verbose switches. Probably designed in such a way that you can use either an existing one character switch or a more verbose version down the road... I'm thinking along the lines of what the other compilers do '--' followed by some name and then if there is a parameter separate with a space.

[GitMensch]

Can I suggest to just drop the current command line parser and use (a possibly adjusted version of) getopt? The license is compatible now, it is "commonly used" and also provides the option to use an abbreviated form for the long option as long as it is still clear - and otherwise prompts the user "did you mean xyz?"

I guess it may need the same amount of time to replace the current parser with a well-debugged version than to rewrite and debug the current one...
For reference: the minimal adjusted one GnuCOBOL uses, along with an internal swap of starting / to - before getopt is called for WIN32 (which could be integrated into an adjusted getopt version directly...).

[LADSoft]

I may look at doing that, let me mull on it a while :)