Re: Options handler for userspace programs

From: Tim Kientzle <kientzle_at_freebsd.org>
Date: Wed, 26 Nov 2008 11:44:24 -0800
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