FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 04-13-2012, 03:50 AM
Allan McRae
 
Default pacman-key: adopt parseopts for option parsing

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 <dreisner@archlinux.org>
> ---
> I really hate this patch, but I don't think it makes sense to split it.

Agreed. One patch is fine.

<snip>

> + 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?

<snip>

> @@ -413,7 +428,7 @@ list_sigs() {
>
> lsign_keys() {
> check_keyids_exist
> - printf 'y
y
' | LANG=C "${GPG_PACMAN[@]}" --command-fd 0 --quiet --batch --lsign-key "${KEYIDS[@]}" 2>/dev/null
> + printf '%s
' y y | LANG=C "${GPG_PACMAN[@]}" --command-fd 0 --quiet --batch --lsign-key "$@" 2>/dev/null
> if (( PIPESTATUS[1] )); then
> error "$(gettext "A specified key could not be locally signed.")"
> exit 1

Is there a good reason beyond the cosmetic for the printf change?
Because I think it fails if it is only cosmetic...

Allan
 
Old 04-13-2012, 12:39 PM
Allan McRae
 
Default 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 <allan@archlinux.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 <dreisner@archlinux.org>
>>> ---
>>> I really hate this patch, but I don't think it makes sense to split it.
>>
>> Agreed. One patch is fine.
>>
>> <snip>
>>
>>> + 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
 

Thread Tools




All times are GMT. The time now is 07:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org