On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson <firstname.lastname@example.org> 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.
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.
- 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
Received on Sat Jun 5 18:49:12 2010