First, your --i example is a long option that happens to be one letter. So that is handled by the existing getopt_long() interface. The -interface long option style is very rarely used for a reason. In particular, it violates POSIX conventions. For that reason, it is used almost exclusively by a few applications (such as "find") whose interfaces were standardized before POSIX. That said, the getopt() API is not particularly well-designed (the use of global variables is particularly distasteful) and the getopt_long() API is quite a mess. If you could come up with something that had a nicer, easier-to-use API, you might find some people interested in using it, especially if it was very well-written, easy-to-understand, and supported a wide variety of command-line styles. I would suggest you build this first to use in your own projects and share it once you've used it in several different programs. Only after you've used it in a variety of different places will you be able to be certain that you've covered all of the uses that people are interested in. You should carefully study the getopt_long() interface (which supports a lot of variations), the POSIX standards, and the historical command-line interfaces of programs such as "dd", "tar", "cpio", and "find." Here are some problems I have with getopt() and getopt_long(): * gzip supports command-line options in environment variables; neither getopt() nor getopt_long() can be used to parse a string containing command-line options * dd uses "key=value" arguments (with no leading -); neither getopt() nor getopt_long() supports this * both use global variables, which limits how you can use them * getopt_long() uses "magic letters" in the argument string to change the behavior, which is poor API design (mixes behavioral and parametric information in a single argument) Have fun! Tim Andrea Di Pasquale wrote: > Yes but getopt() and getopt() are limited. They can to handle > only 2 options type, character and word. My idea is a main > type that handle all. For example, > > Long options: Short options: > > interface i > -interface -i > --interface --i > > Both they can use one or two flag front the option. For example: > > optarg_t opts[] = { > {"interface", "--i", OPT_REQARG1}, > {"--filter", "f", OPT_REQARG2}, > {"-typed", "t", OPT_REQOPT}, > {"-status", NULL, OPT_OPTARG1}, > {"status", "-s", OPT_OPTARG2}, > {NULL, "--v", OPT_NOARG}, > {"help", "h", OPT_NOARG}, > {NULL, NULL, OPT_NULL} > }; > > and optarg_t is: > > typedef enum optflag { > OPT_NOARG, /* no arguments */ > OPT_REQARG1, /* required argument */ > OPT_REQARG2, /* required two arguments */ > OPT_REQOPT, /* required argument with 2° optional > argument */ > OPT_OPTARG1, /* optional argument */ > OPT_OPTARG2, /* optional two arguments */ > OPT_NULL > } optflag_t; > > typedef struct optarg { > const char *opt_name; /* option's name */ > const char *opt_alias; /* option's alias */ > optflag_t opt_flag; > } optarg_t; > > Thank you, regards > Andrea > > Tim Kientzle wrote: > >> Have you looked at getopt_long, which is in the standard >> FreeBSD C libraries? >> >> man 3 getopt_long >> >> The use of getopt() in most utilities instead of getopt_long() >> is a very deliberate choice. >> >> Tim Kientzle >> >> >> Andrea Di Pasquale wrote: >> >>> Hi! I seen that all freebsd' s programs use getopt() or sequence >>> options with arguments. >>> I wanna to propose new options handler that handle name or alias >>> for options and >>> option's argument, example no argument, required one or two >>> arguments, required >>> argument with 2° option argument and one or two optional arguments. >>> Can it useful for freebsd? >>> Regards, >>> Andrea_______________________________________________ >>> freebsd-current_at_freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe_at_freebsd.org " >> >> > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > >Received on Wed Nov 26 2008 - 18:44:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:38 UTC