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