> I added the --no-help and --no-version options for gengetopt that avoid > automatically generating --help and --version
So, you suggest me solving this situation with --no-version. This --version handling is totally up to the application. In other words with --no-version enabled options named "version" or "help" are as regular options as the others specified in .ggo files. Am I right? > Papp Gyozo (VBuster) wrote: > > Hi, > > > >>> another minor issue I've been faced up now. Even if I add > >> '--no-handle-version' the processing of the commandline finishes right > after > >> it encounters with a '-V' or '--version' option. > >>> My application should behave differently, ie. prints the version of > other > >> loaded libraries if the required options are given. Now the situation is > the > >> latter one does not print engine and vdb version to the output: > >>> vbscan --vdb= ... --engine=... --version ; both --vdb and --engine > >> processed > >>> vbscan --version --vdb= ... --engine=... ; neither --vdb and --engine > >> processed > > > >> I don't know whether it's better to change the current [...] > >> the programmer has the complete control for them if he wants to... > > > > The "entire bypass" may be the best if someone really needs. But if it > needs a lot to do, then don't do it. I could live with this behaviour. As I > mentioned it is really a minor issue. > > > > > >>> however in general beside this, gengetopt generated parsers do not deal > >> with the exact order of the program arguments. > >> > >> could you please provide an example? > > > > Look at above! It doesn't usually matter either --vdb or --engine comes > first, the result from the application's view will be the same. > > > > notice that the parser completely relies on getopt_long implementation > > about Yes, you are right indeed. _______________________________________________ Help-gengetopt mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gengetopt
