www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Fixing valid options for std.getopt

reply Jens Mueller <jens.k.mueller gmx.de> writes:
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
Aug 09 2011
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 10.08.2011 1: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)

not working. Though I dunno why change -tv, I think it's widely used form and not only for numerics.
 -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

-- Dmitry Olshansky
Aug 09 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 10.08.2011 1: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)

+1 on this, I recall spending about an hour trying to get why -t v is not working. Though I dunno why change -tv, I think it's widely used form and not only for numerics.
 -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.

Like all of the above except -tv.
 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.

Can't figure out the reason for 4, could you clarify a bit?

Normally, -tv would mean that you passed _two_ flags - the t and v flags. -t2 works because 2 can't be a flag. I'm pretty sure that this proposed behavior is normal. - Jonathan M Davis
Aug 09 2011
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
For SDC I've had to resort to filtering through args before getopt and 
replacing -m32 with --m32. The output flag needs to have that treatment 
too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these 
changes and give them two thumbs up.

d-n_n-b
Aug 09 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 10.08.2011 2:35, Bernard Helyer wrote:
 On Tue, 09 Aug 2011 22:34:29 +0000, Bernard Helyer wrote:

 For SDC I've had to resort to filtering through args before getopt and
 replacing -m32 with --m32. The output flag needs to have that treatment
 too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these
 changes and give them two thumbs up.

 d-n_n-b

allow it?

Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled? -- Dmitry Olshansky
Aug 09 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 8/10/11 2:57 AM, Jonathan M Davis wrote:
 It's _very_ odd for dmd to have flags which are multi-character but only take
 a single -, and I'd argue that that's not behavior which should be emulated.

I don't know what your definition of odd is, but some counterexamples that immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, … David
Aug 09 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 8/10/11 3:57 AM, Andrew Wiley wrote:
 On Tue, Aug 9, 2011 at 6:01 PM, David Nadlinger <see klickverbot.at
 <mailto:see klickverbot.at>> wrote:
     I don't know what your definition of odd is, but some
     counterexamples that immediately come to my mind: GCC, just about
     every Java VM, LLVM/Clang, …

     David
 I can't think of an example with GCC. It does things like
 -fdisable-some-option, but I can't think of a multicharacter _flag_.

Just have a look at its manpage? -combine, -pipe, -pedantic, -trigraphs, etc. David
Aug 10 2011
parent Don <nospam nospam.com> writes:
Andrej Mitrovic wrote:
 On Windoze I think it's pretty standard to use -longname. I really
 like forward-slash style arguments too (boo-hoo for you posixers,
 idk.).

Does anything on Windows use --longname, apart from direct ports of posix tools?
Aug 10 2011
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Thu, 11 Aug 2011, David Nadlinger wrote:

 On 8/10/11 3:57 AM, Andrew Wiley wrote:
 On Tue, Aug 9, 2011 at 6:01 PM, David Nadlinger <see klickverbot.at
 <mailto:see klickverbot.at>> wrote:
     I don't know what your definition of odd is, but some
     counterexamples that immediately come to my mind: GCC, just about
     every Java VM, LLVM/Clang, ?
 
     David
 I can't think of an example with GCC. It does things like
 -fdisable-some-option, but I can't think of a multicharacter _flag_.

Just have a look at its manpage? -combine, -pipe, -pedantic, -trigraphs, etc. David

While it's not hard to find some software the deviates from the behavior of getopt based parameters, I think you'll notice that the majority of it is ancient software. Like any ancient system, there's a cost/benefit to changes that often falls on the "don't change it" side. I greatly prefer the predictability and standardization that getopt style parameter handling has brought to the world and strongly urge NOT going very far with expanding its capabilities. DMD is a particularly good example of bad parameter handling, imho. My 2 cents, Brad
Aug 10 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On Tue, 09 Aug 2011 22:34:29 +0000, Bernard Helyer wrote:

 For SDC I've had to resort to filtering through args before getopt and
 replacing -m32 with --m32. The output flag needs to have that treatment
 too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these
 changes and give them two thumbs up.
 
 d-n_n-b

That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it?
Aug 09 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On Tue, 09 Aug 2011 22:35:44 +0000, Bernard Helyer wrote:
 
 That said, I would like -ofoo.bin to work as well. Perhaps a flag to
 allow it?

Although I could just translate that by hand. Not the end of the world.
Aug 09 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 10.08.2011 2:35, Bernard Helyer wrote:
 On Tue, 09 Aug 2011 22:34:29 +0000, Bernard Helyer wrote:
 For SDC I've had to resort to filtering through args before getopt and
 replacing -m32 with --m32. The output flag needs to have that treatment
 too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these
 changes and give them two thumbs up.
 
 d-n_n-b

That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it?

Same here, though not a big deal. Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled?

I'm not sure that it's a bad idea to give some options on how getopt works (e.g. a way to disallow the bundling of arguments), but in general it should probably work like the C getopt as far as what it accepts goes, and I believe that these changes bring it more in line with the C getopt. Typically, the only way to use multi-character flags is --, and when you use -, every all of the characters immediately following it are individual flags. It's _very_ odd for dmd to have flags which are multi-character but only take a single -, and I'd argue that that's not behavior which should be emulated. So, in general, I think that these changes are very much the right approach. However, it may be reasonable to have a way to alter some of getopt's behavior for those who want it. - Jonathan M Davis
Aug 09 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 On 8/10/11 2:57 AM, Jonathan M Davis wrote:
 It's _very_ odd for dmd to have flags which are multi-character but only
 take a single -, and I'd argue that that's not behavior which should be
 emulated.

I don't know what your definition of odd is, but some counterexamples that immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, …

I mean that most programs don't work that way - at least not the ones that I've used. Some _do_ work that way, but in my experience, it's abnormal. I do find it interesting though that all of the examples that you give are compilers or related to compilers. Assuming that they're the prime examples of programs that work that way, I wonder if there's something particular about compilers which makes it so that they don't follow the more general trend (the overabundance of flags that they have perhaps?). But maybe my experience in the matter is just lopsided. - Jonathan M Davis
Aug 09 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--000e0cd2906062e5c904aa1d0014
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 9, 2011 at 6:01 PM, David Nadlinger <see klickverbot.at> wrote:

 On 8/10/11 2:57 AM, Jonathan M Davis wrote:

 It's _very_ odd for dmd to have flags which are multi-character but only
 take
 a single -, and I'd argue that that's not behavior which should be
 emulated.

I don't know what your definition of odd is, but some counterexamples tha=

 immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, =

 David

I can't think of an example with GCC. It does things like -fdisable-some-option, but I can't think of a multicharacter _flag_. Also, I've always felt that the way Java VMs take arguments feels like it grew organically into something terrible (-Xmx512m! -Xkill-the-rabbit!). I can't speak to LLVM/Clang. Could you post a few specific examples? It's hard to generalize with this sort of thing. (And don't even get me started on Windows. Should I be using /? or -? or = =3D? or -help or --FML-this-OS-doesn't-support-CLI) --000e0cd2906062e5c904aa1d0014 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Aug 9, 2011 at 6:01 PM, David Na= dlinger <span dir=3D"ltr">&lt;<a href=3D"mailto:see klickverbot.at">see kli= ckverbot.at</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On 8/10/11 2:57 AM, Jonathan M Davis wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It&#39;s _very_ odd for dmd to have flags which are multi-character but onl= y take<br> a single -, and I&#39;d argue that that&#39;s not behavior which should be = emulated.<br> </blockquote> <br></div> I don&#39;t know what your definition of odd is, but some counterexamples t= hat immediately come to my mind: GCC, just about every Java VM, LLVM/Clang,= =85<br><font color=3D"#888888"> <br> David<br> </font></blockquote></div><br><div>I can&#39;t think of an example with GCC= . It does things like -fdisable-some-option, but I can&#39;t think of a mul= ticharacter _flag_.</div><div>Also, I&#39;ve always felt that the way Java = VMs take arguments feels like it grew organically into something terrible (= -Xmx512m! -Xkill-the-rabbit!). I can&#39;t speak to LLVM/Clang.</div> <div><br></div><div>Could you post a few specific examples? It&#39;s hard t= o generalize with this sort of thing.</div><div><br></div><div>(And don&#39= ;t even get me started on Windows. Should I be using /? or -? or =3D? or -h= elp or --FML-this-OS-doesn&#39;t-support-CLI)</div> --000e0cd2906062e5c904aa1d0014--
Aug 09 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Aug 09 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-10 09:26, Jens Mueller wrote:
 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

Just saying I don't like that. I won't break anything for me but it will let people continue to implement tools which uses this syntax. -- /Jacob Carlborg
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Dmitry Olshansky wrote:
 On 10.08.2011 1: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)

is not working. Though I dunno why change -tv, I think it's widely used form and not only for numerics.

I believe it's only safe for numerics. Consider the following example. -tsomestring was passed because -t is supported short option but your program also accepts the boolean long option --tsomestring. Now forgetting a single dash will change the behavior silently. One can argue it's the programmer's job to not define options in this combination. Basically whenever you define a non-boolean short option don't specify a long option starting with the same letter. Allowing it only for numeric values avoids having this rule. Thus, it's less error-prone I think. Jens
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
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
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
David Nadlinger wrote:
 On 8/10/11 2:57 AM, Jonathan M Davis wrote:
It's _very_ odd for dmd to have flags which are multi-character but only take
a single -, and I'd argue that that's not behavior which should be emulated.

I don't know what your definition of odd is, but some counterexamples that immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, $B!D(B

I've also come across this. I first thought it's a GNU vs. something other issue. But gcc proves me wrong. The basic difference is whether a long option has to have two dashes. If it doesn't, then bundling of short options cannot be supported as Mike Wey pointed out some time ago. I often use this bundling when using tar, e.g. tar -xf <file>. Maybe the above tools need no bundling. Jens
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On 10.08.2011 2:35, Bernard Helyer wrote:
 On Tue, 09 Aug 2011 22:34:29 +0000, Bernard Helyer wrote:
 For SDC I've had to resort to filtering through args before getopt and
 replacing -m32 with --m32. The output flag needs to have that treatment
 too (seriously, `sdc -o=foo.bin foo.d` is just weird). I lurve these
 changes and give them two thumbs up.
 
 d-n_n-b

That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it?

Same here, though not a big deal. Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled?

I'm not sure that it's a bad idea to give some options on how getopt works (e.g. a way to disallow the bundling of arguments), but in general it should probably work like the C getopt as far as what it accepts goes, and I believe that these changes bring it more in line with the C getopt.

I will check man 3 getopt.
 Typically, the only way to use multi-character flags is --, and when you use 
 -, every all of the characters immediately following it are individual flags. 
 It's _very_ odd for dmd to have flags which are multi-character but only take 
 a single -, and I'd argue that that's not behavior which should be emulated.
 
 So, in general, I think that these changes are very much the right approach. 
 However, it may be reasonable to have a way to alter some of getopt's behavior 
 for those who want it.

Supporting a short option like -ofoo.bin may be error prone. Let's say I also have the long boolean option --obar. Now somebody passes -obar but intended --obar. Is this problematic? Jens
Aug 10 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 10, 2011 09:51:32 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On 10.08.2011 2:35, Bernard Helyer wrote:
 On Tue, 09 Aug 2011 22:34:29 +0000, Bernard Helyer wrote:
 For SDC I've had to resort to filtering through args before
 getopt and replacing -m32 with --m32. The output flag needs
 to have that treatment too (seriously, `sdc -o=foo.bin foo.d`
 is just weird). I lurve these changes and give them two
 thumbs up.
 
 d-n_n-b

That said, I would like -ofoo.bin to work as well. Perhaps a flag to allow it?

Same here, though not a big deal. Taking Jonathan's comment into account, how about allowing it when bundling of arguments is disabled?

I'm not sure that it's a bad idea to give some options on how getopt works (e.g. a way to disallow the bundling of arguments), but in general it should probably work like the C getopt as far as what it accepts goes, and I believe that these changes bring it more in line with the C getopt.

I will check man 3 getopt.
 Typically, the only way to use multi-character flags is --, and when you
 use -, every all of the characters immediately following it are
 individual flags. It's _very_ odd for dmd to have flags which are
 multi-character but only take a single -, and I'd argue that that's not
 behavior which should be emulated.
 
 So, in general, I think that these changes are very much the right
 approach. However, it may be reasonable to have a way to alter some of
 getopt's behavior for those who want it.

Supporting a short option like -ofoo.bin may be error prone. Let's say I also have the long boolean option --obar. Now somebody passes -obar but intended --obar. Is this problematic?

Personally, I'll all for requiring that multi-character flags use -- and not -, and I _do_ think that it's problematic to allow multi-character flags to use -. However, I'm not entirely against having a way to tell getopt to accept multi- character flags with a single - if people want that and it can work reasonably without causing problems as long as people are careful about the flags that their program accepts. It definitely shouldn't be the default behavior though. However, given that getopt is a single function call with a variadic argument, the only way that I can think of that you'd be able to tell it whether to accept multi-character flags with a single - would be a template argument, and I'd be very concerned that accepting multi-character flags with a single - would make getopt overly complicated. I'd have to examine the implementation though to see how much worse it would make it. It would probably have to change so that there is no difference between - and -- (both are treated like --), except that --ofbar.bin isn't accepted with your changes (you need either --of bar.bin or --of=bar.bin). So, treating - like -- isn't really going to do what the people who want multi-character flags with - would want anyway (and I do think that disallowing --ofbar.bin is the correct decision, so I'm not advising changing that). So, I don't know. I'm generally against programs having multi-character flags which work with -, and I'm definitely afraid that allowing such things with a separate setting for getopt is going to overcomplicate getopt. Regardless, I would be _completely_ against the default allowing it. So, I'd prefer that getopt just have the one set of behaviors and disallow multi-character flags with -, but I don't want to just reject it out of hand if others want it and it's reasonably feasible without overcomplicating things. The real question is how the C getopt works, since that's what our getopt is at least supposed to be modeled after (and given that it has the same name, it's not unreasonable to expect essentially the same behavior). However, a quick glance at getopt's man page makes it seem far more complicated than our getopt, which I would consider to be undesirable. So, we may not want to quite follow the C getopt. However, we should definitely look at how it handles the flags and what it allows and try for something similar. - Jonathan M Davis
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Andrew Wiley wrote:
 On Tue, Aug 9, 2011 at 6:01 PM, David Nadlinger <see klickverbot.at> wrote:
 
 On 8/10/11 2:57 AM, Jonathan M Davis wrote:

 It's _very_ odd for dmd to have flags which are multi-character but only
 take
 a single -, and I'd argue that that's not behavior which should be
 emulated.

I don't know what your definition of odd is, but some counterexamples that immediately come to my mind: GCC, just about every Java VM, LLVM/Clang, $B!D(B David

I can't think of an example with GCC. It does things like -fdisable-some-option, but I can't think of a multicharacter _flag_.

There are -pg and -pedantic. Jens
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 Personally, I'll all for requiring that multi-character flags use -- and not
-, 
 and I _do_ think that it's problematic to allow multi-character flags to use
-. 
 However, I'm not entirely against having a way to tell getopt to accept multi-
 character flags with a single - if people want that and it can work reasonably 
 without causing problems as long as people are careful about the flags that 
 their program accepts. It definitely shouldn't be the default behavior though.

If I add support for it, it won't be default. I'm thinking about adding a configuration option multiCharDoubleDashOnly (default), multiCharSingleDoubleDash (allow additionally a single dash), and multiCharSingleDashOnly (only allows single dash for long options). multiCharSingleDoubleDash or multiCharSingleDashOnly imply that bundling is turned off.
 However, given that getopt is a single function call with a variadic argument, 
 the only way that I can think of that you'd be able to tell it whether to 
 accept multi-character flags with a single - would be a template argument, and 
 I'd be very concerned that accepting multi-character flags with a single - 
 would make getopt overly complicated. I'd have to examine the implementation 
 though to see how much worse it would make it.

Using getopt's config enum should make it possible as I outlined above. I hope this change keeps the code simple.
 It would probably have to change so that there is no difference
 between - and -- (both are treated like --), except that --ofbar.bin
 isn't accepted with your changes (you need either --of bar.bin or
 --of=bar.bin). So, treating - like -- isn't really going to do what
 the people who want multi-character flags with - would want anyway
 (and I do think that disallowing --ofbar.bin is the correct decision,
 so I'm not advising changing that).

Yeah. Long options (with whatever many dashes) and no space or equal sign as separator is confusing. I'm only going to add this if there is a strong case for it.
 So, I don't know. I'm generally against programs having multi-character flags 
 which work with -, and I'm definitely afraid that allowing such things with a 
 separate setting for getopt is going to overcomplicate getopt. Regardless, I 
 would be _completely_ against the default allowing it. So, I'd prefer that 
 getopt just have the one set of behaviors and disallow multi-character flags 
 with -, but I don't want to just reject it out of hand if others want it and 
 it's reasonably feasible without overcomplicating things.

So far we only have seen some examples of tools that are using single dash multi-character options. Nobody so far has argued that this is a good way of doing it which is kind of interesting.
 The real question is how the C getopt works, since that's what our getopt is 
 at least supposed to be modeled after (and given that it has the same name, 
 it's not unreasonable to expect essentially the same behavior). However, a 
 quick glance at getopt's man page makes it seem far more complicated than our 
 getopt, which I would consider to be undesirable. So, we may not want to quite 
 follow the C getopt. However, we should definitely look at how it handles the 
 flags and what it allows and try for something similar.

D's getopt is actually modeled after Perl's Getopt::Long (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is actually different in the details but I believe D's getopt is easy to use in comparison. Next I will add support for -tv where v can be of arbitrary type to support -ofile.bin. This behavior is configurable via noSpaceForShortOption. If set it implies no bundling. The other behavior is noSpaceForShortOptionNumeric. I'm not sure yet whether defaulting to noSpaceForShortOptionNumeric is good as it breaks code. Many thanks to all for sharing your opinions. Jens
Aug 10 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
 D's getopt is actually modeled after Perl's Getopt::Long
 (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is actually
 different in the details but I believe D's getopt is easy to use in
 comparison.

Well, D's getopt should be fairly standard it terms of default behavior, and it should be reasonably easy to use. As it stands, it's pretty easy to use. I think that my main gripe is http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting out its behavior like you're doing is a definite improvement IMHO.
From the little I looked at Linux' getopt, it was pretty bad in terms of 

in _that_ regard. But I do think that the default settings should follow what is generally standard as far as how flags function and how they accept arguments. - Jonathan M Davis
Aug 10 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Windoze I think it's pretty standard to use -longname. I really
like forward-slash style arguments too (boo-hoo for you posixers,
idk.).
Aug 10 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
 D's getopt is actually modeled after Perl's Getopt::Long
 (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is actually
 different in the details but I believe D's getopt is easy to use in
 comparison.

Well, D's getopt should be fairly standard it terms of default behavior, and it should be reasonably easy to use. As it stands, it's pretty easy to use. I think that my main gripe is http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting out its behavior like you're doing is a definite improvement IMHO.

Didn't know of this report. There are also other regarding getopt that I should check. I will have a look when I'm finished with the current changes. Since the report is concerned with exception reporting it'll be nice to have some specific examples where the thrown exception is not good enough. Maybe you can add the specific usage examples that you found. Jens
Aug 11 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, August 11, 2011 10:02:38 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
 D's getopt is actually modeled after Perl's Getopt::Long
 (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is
 actually
 different in the details but I believe D's getopt is easy to use in
 comparison.

Well, D's getopt should be fairly standard it terms of default behavior, and it should be reasonably easy to use. As it stands, it's pretty easy to use. I think that my main gripe is http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting out its behavior like you're doing is a definite improvement IMHO.

Didn't know of this report. There are also other regarding getopt that I should check. I will have a look when I'm finished with the current changes. Since the report is concerned with exception reporting it'll be nice to have some specific examples where the thrown exception is not good enough. Maybe you can add the specific usage examples that you found.

I'd have to mess around with getopt for a bit to get a good feel for exactly what I'd like out of a specific exception, but the prime example would be that a GetOptException would be able to tell you exactly which flag failed and what the value was that was used with it. A ConvException is incredibly generic about the problem. If I had --flag=stuff --option=stuff and one of those was supposed to take an int instead of a string, then the ConvException is only going to tell you what the string was that faild to convert - not what flag it was for - and regardless, it doesn't tell you in a way that's easy for the program to determine what happened. Ideally, _no_ exceptions would be seen by the user, and for the program to be able to give the user adequate feedback on which flag failed and why it failed, the program needs an exception which actually tells it what failed and why. Right now, all it gets is that a conversion in one of the flags failed, which just doesn't cut it if you want to figure out what went wrong so that you can give the user decent feedback. - Jonathan M Davis
Aug 11 2011
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Thursday, August 11, 2011 10:02:38 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
 D's getopt is actually modeled after Perl's Getopt::Long
 (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is
 actually
 different in the details but I believe D's getopt is easy to use in
 comparison.

Well, D's getopt should be fairly standard it terms of default behavior, and it should be reasonably easy to use. As it stands, it's pretty easy to use. I think that my main gripe is http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting out its behavior like you're doing is a definite improvement IMHO.

Didn't know of this report. There are also other regarding getopt that I should check. I will have a look when I'm finished with the current changes. Since the report is concerned with exception reporting it'll be nice to have some specific examples where the thrown exception is not good enough. Maybe you can add the specific usage examples that you found.

I'd have to mess around with getopt for a bit to get a good feel for exactly what I'd like out of a specific exception, but the prime example would be that a GetOptException would be able to tell you exactly which flag failed and what the value was that was used with it. A ConvException is incredibly generic about the problem. If I had --flag=stuff --option=stuff and one of those was supposed to take an int instead of a string, then the ConvException is only going to tell you what the string was that faild to convert - not what flag it was for - and regardless, it doesn't tell you in a way that's easy for the program to determine what happened.

I see.
 Ideally, _no_ exceptions would be seen by the user, and for the program to be 
 able to give the user adequate feedback on which flag failed and why it
failed, 
 the program needs an exception which actually tells it what failed and why. 
 Right now, all it gets is that a conversion in one of the flags failed, which 
 just doesn't cut it if you want to figure out what went wrong so that you can 
 give the user decent feedback.

Turning the exception into a useful message could be actually done by std.log. In release mode std.log's format string may be changed. But there are other options as well. I will look into providing more useful exceptions which are needed either case. Jens
Aug 11 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 11, 2011 14:16 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Thursday, August 11, 2011 10:02:38 Jens Mueller wrote:
 Jonathan M Davis wrote:
 On Wednesday, August 10, 2011 15:28 Jens Mueller wrote:
 D's getopt is actually modeled after Perl's Getopt::Long
 (http://perldoc.perl.org/Getopt/Long.html). Linux's getopt is
 actually
 different in the details but I believe D's getopt is easy to use in
 comparison.

Well, D's getopt should be fairly standard it terms of default behavior, and it should be reasonably easy to use. As it stands, it's pretty easy to use. I think that my main gripe is http://d.puremagic.com/issues/show_bug.cgi?id=5228 , but better sorting out its behavior like you're doing is a definite improvement IMHO.

Didn't know of this report. There are also other regarding getopt that I should check. I will have a look when I'm finished with the current changes. Since the report is concerned with exception reporting it'll be nice to have some specific examples where the thrown exception is not good enough. Maybe you can add the specific usage examples that you found.

I'd have to mess around with getopt for a bit to get a good feel for exactly what I'd like out of a specific exception, but the prime example would be that a GetOptException would be able to tell you exactly which flag failed and what the value was that was used with it. A ConvException is incredibly generic about the problem. If I had --flag=stuff --option=stuff and one of those was supposed to take an int instead of a string, then the ConvException is only going to tell you what the string was that faild to convert - not what flag it was for - and regardless, it doesn't tell you in a way that's easy for the program to determine what happened.

I see.
 Ideally, _no_ exceptions would be seen by the user, and for the program
 to be able to give the user adequate feedback on which flag failed and
 why it failed, the program needs an exception which actually tells it
 what failed and why. Right now, all it gets is that a conversion in one
 of the flags failed, which just doesn't cut it if you want to figure out
 what went wrong so that you can give the user decent feedback.

Turning the exception into a useful message could be actually done by std.log. In release mode std.log's format string may be changed. But there are other options as well. I will look into providing more useful exceptions which are needed either case.

std.log may be able to help, but getopt really doesn't have anything to do with logging. The primary issue is that it's currently very difficult to programmatically handle failures from getopt. It's difficult to do much better than print the exception message or that there was a general failure. To be able to programmatically handle the failure, you need specific stuff like which flag failed, what value it was given, and why it failed. When all you really have is the type of the exception and its message, it's not really enough to handle it programmatically. - Jonathan M Davis
Aug 11 2011