Re: Disallowing args

2010-06-17 Thread Jeff Johnson

On Jun 5, 2010, at 11:39 AM, Wayne Davison wrote:

 Here's something that was recently fixed for the popt that is included
 with rsync: rejecting an arg to an option that doesn't take an arg.
 Attached is a patch.  A new error code, POPT_ERROR_UNWANTEDARG, was
 created to make the error message nice.  This handles both -l=value
 and --long-arg=value where neither one is supposed to take a value.

Hmmm, I'll get this fix worked in down the road. Certainly a bug.

All this code is actively being simplified for POPT 2.0 so
that I can more easily follow the logic path.

Meanwhile in the future, if you could send a patch against some
POPT release that I can find (I tried all the way back to
the popt-1_11-release tag, patch doesn't apply), or at least provide some hint
about what code repository the patch applies to (the patch itself seems
to have been edited), that would certainly help.

Please also note that I won't accept any patch that doesn't
pass make check regression tests. If you _REALLY_ want
to make sure that odd POPT corner cases like args given to
an option return an error, adding a reproducer to the
test cases too.

73 de Jeff
POPT Library
Developer Communication List

Re: Disallowing args

2010-06-05 Thread Jeff Johnson

On Jun 5, 2010, at 12:48 PM, Wayne Davison wrote:

 On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson wrote:
--foo bar
 returns bar in the argument list?
 Yes.  The user may well have wanted it to be in the arg list.  There's no way 
 for the program to know that the user didn't just toss some options in the 
 middle of some args (which I do all the time these days, like starting my 
 rsync source/dest args, and then tossing in a --remove-source-files, 
 --backup, or what-not at wherever I am in the list), so I wouldn't want to 
 see an error for something like this:
 rsync -aiv --del file --remove-source-args some/dir host:/dest/dir
 ... just because --del doesn't take an arg.
 The other way to fix the error is to morph --foo=bar behavior to be 
 identical to --foo bar, i.e. an extra argument failure.
 I don't see how that would work for something like rsync that takes any 
 number of command-line args outside the options.

Well determistic behavior works, just not very useful ;-) I'm not
arguing, just there's issues like POSIX_ME_HARDER that get factored
into --foo=bar error handling, all mind numbingly tedious.

Your patch is likely what I will add, I'm a very lazy schmuck.

 Anything you want to see in POPT 2.0? I'm collecting features ...
 A couple ideas off the top of my head:
 An incrementing option -- repeated use adds 1 to the variable instead of 
 setting it to the same value.

How about a full blown RPN calculator to handle not just increment/decrement,
but all arithmetic operations, on option values. infix - postfix just isn't 
that hard, and the whole
mess is just a teensy stack and a switch.

I've got several RPN calculators floating around in RPM code these days that 
be dropped into POPT without any effort whatsoever. Nor is a RPM calculator very
hard to implement.
 Multiple long names separated by | in the long-name string (though that 
 could really just be defined as an alias, it might be nice to auto-gen the 

There's already Bloom filters fin POPT 1.16 for opaquely handling multiple 
option value strings
(the bar in --foo bar). That partly addresses the need for fewer popt table 
The usage case is for RPM which has 100 hash algorithm names buried into popt 
and I need to collapse down to a single popt table entry for my own maintenance 

Full pattern matching, either *RE or fnmatch(3), would not be hard. The pdksh 
to fnmatch globs would handle your specific alternation request.

And POPT is already linking fnmatch(3).

If you have any other RFE's just drop a note here ... and blame Rusty Russell 
for encouraging POPT 2.0 ;-)

73 de Jeff

Re: Disallowing args

2010-06-05 Thread Jeff Johnson

On Jun 5, 2010, at 12:42 PM, Danny Sung wrote:

 On 06/05/2010 8:56 AM, Jeff Johnson wrote:
 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.

Well reworking --help is one of the primary motivations for POPT 2.0.

Hysterically, encoding was rammed into POPT by GNOME way back when.
While the scheme is workable, the original change _HAD_ to be done
as an addition to preserve ABI, and so all of the i18n for --help
is rather awkwardly done.

To make matters worse, another patch from GNOME wanted POPT to undertake
localization transforms from UTF8 to whatever was in LC_ALL etc.

While iconv(3) makes the character encoding transform as trivial as deciding
the to - from locales, its hardly trivial to make that decision reliably
based solely on a desired LC_ALL environment variable (the from locale cannot
be determined reliably, and hackery like trying various from locales like
glib does is hardly sound engineering).

The killer is that the data needed to find --help alignment reproducers is 
application resident,
and application chosen, and the GNOME developers who forced the iconv(3) into
POPT just aren't helping with reproducers. I have no interest in supporting
POPT functionality that noone is willing to help maintain any more.

So the short answer is:
All of the --help handling needs to be scrapped and reworked in POPT 

For starters, 30-40% of the code is --help related, and _ALL_ of the bug reports
I've heard for years are
But --help columns don't align!

Enough already ... bring on the --help bulldozers!

 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 
 Other niceties might be:
 - a way to indicate parameters enabled by default (eg. having a '*' next to 
 them in the help)

There is already
#define POPT_ARGFLAG_SHOW_DEFAULT 0x0080U /*! show default value 
in --help */
as well as
#define POPT_ARGFLAG_OPTIONAL   0x1000U  /*! arg may be missing */
wired into --help output.

 - An additional structure that could provide detailed help on argDescription 
 elements.  For example, rpm has an option:
  --queryformat=QUERYFORMATuse 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.

This is a different issue. There is already the 6th/7th fields in POPT tables,
the problem is really information overload from --help. At some point man(1)
or info(1) is a better approach than --help, particularly for RPM which has
an entire eco-system of option processing and far too many options
to be reasonably displayed with --help (because the info is not very helpful).

Note that RPM is _ROUTINELY adding
#define POPT_ARGFLAG_DOC_HIDDEN 0x4000U /*! don't show in 
help/usage */ 
there's zillions of options in RPM that noone knows about. My guess is that 
more hidden than displayed options these days, usually disablers that noone 
really needs to use.

   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:

FYI: POPT 2.0 is all about breaking compatibility. There's only so much
that can be done with obscure overloadings of the existing 7-tuple in
popt table entries.

 enum poptOptionType {
 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 },