Fixing valid options for std.getopt

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


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


More information about the Digitalmars-d mailing list