Fixing valid options for std.getopt

Jens Mueller jens.k.mueller at gmx.de
Wed Aug 10 00:26:57 PDT 2011


Jacob Carlborg wrote:
> On 2011-08-09 23:32, Jens Mueller wrote:
> >Hi,
> >
> >I've added some changes to getopt to change when an options is
> >accepted/rejected. I'm going to describe its old behavior in contrast
> >with its old behavior.
> >
> >Consider parsing an option of Type T:
> >
> >T timeout;
> >getopt(args, "t|timeout",&timeout);
> >
> >Short options (single dash):
> >-t v accept (was rejected)
> >-t=v accept
> >-tv only accept for numeric v (was accepted for all types except associative arrays)
> >
> >Strange short options:
> >-timeout v reject
> >-timeout=v reject (was accepted)
> >-timeoutv reject
> >
> >Long options (double dash):
> >--timeout v accept
> >--timeout=v accept
> >--timeoutv reject
> >
> >Strange long options:
> >--t v reject (was accepted)
> >--t=v reject (was accepted)
> >--tv reject
> >
> >
> >I would like to know whether you find the new behavior better or if you
> >prefer the old. Or even a mix of both. Or none of the above.
> >
> >The current behavior is quite simple if you remember some simple rules:
> >1. Short options consist of a single dash and a single character.
> >2. Long options consist of two dashes and more than one character.
> >3. Passing short and long options is supported by
> >    <short/long option><space+><value>  and<short/long option>=<value>
> >4. The form<short option><value>  is only supported for numeric values.
> >5. Anything else is not supported and an exception is thrown.
> >
> >To look at the changes see here:
> >https://github.com/jkm/phobos/commit/b208eeb142ff5a3f189c2595b9800425646b4794 (fixes old behavior)
> >https://github.com/jkm/phobos/commit/a25cd2459418d462c85ab14c2d970dd413b4fb05 (introduces new behavior)
> >
> >Please comment.
> >
> >Jens
> 
> I like it, but I see no reason to accept <short option><value>. I've
> never understood why anyone would want to accept that. For example,
> looking at DMD's help message is often hard to tell where an option
> end and the value beings, i.e. -offilename.

I think short options with no space are supported because a number of
people (don't know how many) type no spaces.
For example
$ ping -c1 <some host>
vs
$ ping -c 1 <some host>

Both work. ping's documentation explains the -c option using a space.
I.e. the documentation is easy to read.
Supporting it does not break anything for you. And this way it does no
harm to anybody. The only reason for dropping it may be inconsistency,
i.e. why does it only work for numeric values.

Jens


More information about the Digitalmars-d mailing list