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 could 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 entries/aliases/execs. (aside) The usage case is for RPM which has >100 hash algorithm names buried into popt tables, and I need to collapse down to a single popt table entry for my own maintenance sanity. Full pattern matching, either *RE or fnmatch(3), would not be hard. The pdksh extensions 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
