[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-gengetopt] Feature suggestion and patch

From: Philip W. L. Fong
Subject: Re: [help-gengetopt] Feature suggestion and patch
Date: Wed, 27 Feb 2002 10:16:17 -0800 (PST)


Thank you for the very encouraging response.  It makes me bold enough
to suggest another feature :-).

In my previous mail, we discussed about a machanism for (1) customizing
the look of --help text when command line arguments are not just
filenames, and (2) generating code to check if the number of arguments
supplied by the user is large enough.  Although the above serves my
immediate programming need very well, it occurs to me that a logical
extension to such a mechanism would be to make use of the option
parsing code already built in gengetopt to actually parse the command
line arguments.

Recall that we specified mandatory and optional arguments using
clauses like the following in the .ggo file:

  argument "arg-1"      "Description of arg-1"
  argument "arg-2"      "Description of arg-2"
  rest     "rest-args"  "Optional list of trailing arguments"

It would be nice if we could actually specify the type of the arguments
we expect, and let gengetopt parses them:

  argument "arg-1"      "Description of arg-1"   string
  argument "arg-2"      "Description of arg-2"   long
  rest     "rest-args"  "Optional list of trailing arguments"

Notice that type specification can only be given for mandatory 

Reading this specification, gengetopt would generate new fields in
the args_info structure.  Specifically, the fields

  char *arg_1;
  long arg_2;

will be generated for the mandatory arguments, and the fields

  unsigned rest_args_num;
  char **rest_args

will be generated for the trailing arguments.  At command line
parsing time, the fields will be filled with the corresponding values.
Basically, arg_1 will share the string in inputs[0], args_2 will
hold a long value obtained by parsing inputs[1], rest_args_num will
be (inputs_num - 2), and rest_args will be (inputs + 2).

Notice that in the above scheme we have made an arbitrary design
choice, namely, to leave the optional trailing list of arguments
unparsed.  This actually have no particular technical merit, it is
proposed this way simply because it involes less coding to implement
it.  One might equally imagine a scheme in which rest_args is an array
of double!

What do you think about such an argument parsing feature?  Is it going
to be useful to the users of gengetopt?  Is the design conforming to
your future plans for gengetopt?  Would it be better off to parse also
the optional trailing arguments?

As I understand it, such extension would involve more coding than 
the patch I sent you last time.  Therefore, I think I better get
some feedback from you first, and in case I get the green light,
I would be very happy to make the necessary changes.

Thank you for taking time to read my very long mails. :-)


* Philip W. L. Fong
* BSMT - 3400 Bentinck Place, Richmond, B.C., Canada V7C 4H4
* Home: (604)277-9666 Mobile: (604)719-2333
* address@hidden

Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]