RPM Community Forums

Mailing List Message of <popt-devel>

Re: Disallowing args

From: Danny Sung <danny@dannysung.com>
Date: Sat 05 Jun 2010 - 18:42:55 CEST
Message-ID: <4C0A7E8F.5080401@dannysung.com>
On 06/05/2010 8:56 AM, Jeff Johnson wrote:

> (aside)
> Anything you want to see in POPT 2.0? I'm collecting features ...
>

Since you're collecting features... =)

One thing I'd like is to extend the help/usage capability just a little.

So I'd like to be able to have more descriptive usage parameters (eg. to 
cover left-over arguments).  I addition it'd be nice to have a little 
description/summary of what the program to do.  I realize you can do 
this with a custom help function.  But it'd be nice if these were 
standard elements.

Other niceties might be:
  - a way to indicate parameters enabled by default (eg. having a '*' 
next to them in the help)

  - An additional structure that could provide detailed help on 
argDescription elements.  For example, rpm has an option:
       --queryformat=QUERYFORMAT        use the following query format
    It'd be nice if there were a section of help that could describe 
what QUERYFORMAT could be.  So obviously it's not going to be a full man 
page, but perhaps it could just show supported % format options or 
something like that.
    I use something like this in my code, but I have specific keys like 
"[replaceme]" that I convert.  And I put just the acceptable keys in the 
help cause I just need a quick reminder of what they are.  But it 
clutters the option help a little.  I'd be fine with specifying 
"FORMATSTRING" in the option help.  Then have perhaps an arg help down 
below that shows what values FORMATSTRING understands.


I'm not sure exactly how you could support these without breaking 
compatability with existing apps.  Perhaps a new datatype something like:

enum poptOptionType {
    POPT_OPTION,
    POPT_ARG,
    POPT_USAGE,
};

union poptDetailedOption {
    poptOptionType optType;
    struct poptShortOption;
    struct poptArgHelp;
    struct poptUsageHelp;
}

struct poptShortOption {  /* same as poptOption but with a type field */
     poptOptionType optType;
     const char * longName;
     char shortName;
     int argInfo;
     void * arg;
     int val;
     const char * descrip;
     const char * argDescrip;
};


I'm not sure this would give the desired effect.. but the thought would 
be that it'd turn your options table to something like this:

poptDetailedOption optionsTable[] = {
         { POPT_OPTION, "bps", 'b', POPT_ARG_INT, &speed, 0,
         "signaling rate in bits-per-second", "BPS" },
         { POPT_ARG, "FORMATSTRING", "Possible formatting options are 
[foo] [bar]" },
	{ POPT_USAGE, "infile [outfile]" },
         { POPT_SUMMARY, "This program converts your data to 
something...." },



I don't think the union will allow it to look exactly like that.  In 
fact it may not even be possible to initialize it that way(?)  Maybe 
we'd have to do something wonky with macros to make it look nice.  But 
you get the idea.

If you wanted to get really fancy the "POPT_USAGE" example I gave could 
be separated into something like this:
   { POPT_EXTRAARG,
         "infile",
         1 /* required */,
         "specify input filename",
         "stdin" /* default value */
   },
   { POPT_EXTRAARG,
         "outfile",
         0 /* optional */,
         "file to output" /* description */
         "stdout" /* default value */
   }

This would allow the autohelp to generate "standard" extra arg displays 
(eg. [] for optional parameters, etc.).

Admittedly this feature may be a bit questionable as many programs may 
have rather complex "extra args".  But I think a lot of programs fall 
into this simple category as well.


Anyway, just a few thoughts...
Received on Sat Jun 5 18:59:58 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.