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

> On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson <n3...@mac.com> wrote:
> but
>        --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 
> alias).

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

Reply via email to