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