RPM Community Forums

Mailing List Message of <popt-devel>

Re: Disallowing args

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 05 Jun 2010 - 19:09:45 CEST
Message-id: <F91CC47D-4447-499B-80E0-5E77A1E1F742@mac.com>

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

> On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson <n3npq@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.
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
Received on Sat Jun 5 19:10:22 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.