pacman-key: adopt parseopts for option parsing
On 13/04/12 22:31, Dave Reisner wrote:
> On Thu, Apr 12, 2012 at 11:50 PM, Allan McRae <firstname.lastname@example.org> wrote:
>> On 13/04/12 00:54, Dave Reisner wrote:
>>> This requires an ugly amount of reworking of how pacman-key handles
>>> options. The change simply to avoid passing keys, files, and directories
>>> as arguments to options, but to leave them as arguments to the overall
>>> program. This is reasonable since pacman-key limits the user to
>>> essentially one operation per invocation (like pacman).
>>> Since we now pass around the positional parameters to the various
>>> operations, we can add some better sanity checking. Each operation is
>>> responsible for testing input and making sure it can operate properly,
>>> otherwise it throws an error and exits.
>>> The doc is updated to reflect this, and uses similar verbiage as pacman,
>>> describing the non-option arguments now passed to pacman-key as targets.
>>> Similar to the doc, --help is reorganized to separate operations and
>>> options and remove argument tokens from operations.
>>> Signed-off-by: Dave Reisner <email@example.com>
>>> I really hate this patch, but I don't think it makes sense to split it.
>> Agreed. One patch is fine.
>>> + if (( $# == 0 )); then
>>> + error "$(gettext "No keys specified")"
>>> + exit 1
>>> + fi
>> This is repeated so many times... How about doing a single check below
>> the check that only one operation is specified?
> Because that would break any option that really can accept 0 arguments,
> such as --list-keys or --refresh-keys.
Yeah. I meant something like:
if (( (ADD || DELETE || EDITKEY || ....) && $# == 0 )); then