std.getopt suggestion

Christophe travert at phare.normalesup.org
Wed Oct 5 09:29:32 PDT 2011


Jens Mueller , dans le message (digitalmars.D:146124), a écrit :
> Christophe wrote:
>> Jens Mueller , dans le message (digitalmars.D:146114), a écrit :
>> > 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.
>> 
>> Posix behavior is enough for me to use getopt to parse command line 
>> options.
>> 
>> No parametrization by global parameters is really preferable to use 
>> getopt for any other purpose that parsing of the command line argument. 
>> That is something I may use one day. I have a backend program written in 
>> c++ that parses commands and uses options with '-' preceding them, that 
>> I may, one day, translate to D to improve it). I would not be 
>> confortable with global parameters, but I don't know if I would use 
>> getopt in that case (in the program in c++, I use the posix getopt only 
>> for the first command line parsing, but there are many reasons for 
>> that, and my input line parsing is crap).
>> 
>> One think I don't know regarding getopt, and that I didn't find in the 
>> documentation (maybe because I didn't look close enough after having 
>> found that -o output was not supported), is if the arguments are sorted 
>> like in the c getopt, and how to get the remaining arguments ? 
>> Shouldn't getopt return an array of the remaning arguments ?
> 
> By remaining arguments you mean unrecognized options, aren't you? These
> are left in the passed array if configured with passThrough. I.e. getopt
> removes an option iff it is recognized.
> What do you mean by sorted arguments?
> 


the GNU getopt in c changes the order of the arguments of the argv 
parameter, to put the options in the front, and the remaining arguments 
at the end. The global variable optind is used to find the first 
remaining argument.
http://www.gnu.org/s/hello/manual/libc/Using-Getopt.html#Using-Getopt

That is what I meant by 'sorted arguments'. But I got my answer. Thanks.


More information about the Digitalmars-d mailing list