Fixing valid options for std.getopt

[Jonathan M Davis]

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