std.getopt suggestion

[Jens Mueller]

Christophe wrote:
> Jens Mueller , dans le message (digitalmars.D:146111), a écrit :
> > Christophe wrote:
> >> Andrei Alexandrescu , dans le message (digitalmars.D:146070), a écrit :
> >> > On 10/4/11 2:39 PM, Andrei Alexandrescu wrote:
> >> >> On 10/4/11 12:05 PM, Christophe wrote:
> >> >>> Andrej Mitrovic , dans le message (digitalmars.D:146060), a écrit :
> >> >>>> I'm don't often use getopt just for the fact that I can't use
> >> >>>> single-dash arguments like '-release'. DMD uses this syntax, and so to
> >> >>>> other tools. It's not a big deal thanks to D's fantastic
> >> >>>> string-manipulation abilities, so I just roll my own. All I need is a
> >> >>>> switch(args) statement.
> >> >>>
> >> >>> I don't use getopt often either. That does not prevent me to wish getopt
> >> >>> could become adequate to my needs...
> >> >>
> >> >> It already is because your needs are the empty set.
> >> >>
> >> >> Andrei
> >> > 
> >> > On second thought what you said suggests your needs set may be nonempty, 
> >> > but said needs are not fulfilled by the current std.getopt.
> >> > 
> >> > What exactly in std.getopt does not fulfill your needs? Would assembling 
> >> > the three variables into a structure help?
> >> 
> >> 
> >> No, it wouldn't.
> >> 
> >> The main reason why I don't want to use getopt is because the syntax "-o 
> >> output" (short-option, space, argument), and that is the main thing 
> >> I want to do. I think I posted about this in the thread.
> > 
> > This will be supported with my changes. I hope I can act soon on the
> > feedback and clean up the pull request.
> > 
> >> Enabling single-dash long option would be nice too.
> > 
> > I suppose there is no technical to not support this kind of option.
> > Though it does make configuring getopt more difficult and I don't see
> > enough usage to add it. Why is this important to you? I see little
> > benefit of -pedantic over --pedantic. If you believe this option is very
> > important (because you want to save a single character), then you could
> > provide the short alias -p.
> > Is this just a matter of taste?
> > Please convince me.
> 
> I can't convince you on that, because I am not really convinced myself.
> --longOption is the posix way, so it is fine with me, even if I think 
> -longOption could be nicer to some eyes.

Does this mean you would write D programs with command options like
--longOption instead of -longOption? I just need to know how strong you
disagree with the current solution. Because you said you wrote your own.
I think we have failed, if a significant number of users rather write
their own command line parsing than using the built-in one.

> However, the current way to parametrise getopt is to change the 
> character for options ('-'), and I belive the string for long option is 
> twice the character for short option ("--"). I don't think this makes 
> great sense. We could parametrize a long option string (that we could 
> set to "-"), and a short option char (that may or may not be 
> automatically set to longOptionString[0]). But no parametrization on the 
> shortOptionChar and on the longOptionString is fine too. Nobody would 
> complain the call to getopt could be screwed up by another programmer 
> modifiying the shortOptionChar behind your back if this could not be 
> changed in the first place...

This can be implemented. But right now I'm trying to figure out whether
it's worth it.

> Well, too much parametrization is wrong. But the posix way has to be 
> supported, and it includes "-o output" (which is much more helpful than 
> -ooutput for readability and for auto-completion in the shell).

Yes. That's why we added it. Hope to finish the pull request soon.

Jens