[pacman-dev] [PATCH] scripts/library: rewrite parse_options

[Dan McGee]

On Wed, Aug 17, 2011 at 7:22 PM, Allan McRae <allan at archlinux.org> wrote:
> On 18/08/11 09:34, Dave Reisner wrote:
>>
>> On Thu, Aug 18, 2011 at 08:57:55AM +1000, Allan McRae wrote:
>>>
>>> On 18/08/11 08:27, Dan McGee wrote:
>>>>
>>>> On Thu, Jul 21, 2011 at 3:40 PM, Dave Reisner<d at falconindy.com>   wrote:
>>>>>
>>>>> In addition to being what I feel is a cleaner and faster
>>>>> implementation,
>>>>> we avoid the use of eval by normalizing option arguments into a global
>>>>> array which is then set after a successful call to parse_options.
>>>>>
>>>>> This trims out the idea of having multiple arguments to a single
>>>>> option,
>>>>> making our parsing algorithm a little more sane. We never took
>>>>> advantage of
>>>>> this in makepkg (for the one option that feasibly supports it), and I
>>>>> think we've overlooked a much simpler solution in pacman-key. Since
>>>>> actions are limited to 1 at a time the leftover positional parameters
>>>>> become the keys or keyfiles which are acted upon.
>>>>>
>>>>> Also added is a new test directory test/scripts with a harness for
>>>>> parse_options, run as part of make check.
>>>>>
>>>>> Signed-off-by: Dave Reisner<dreisner at archlinux.org>
>>>>> ---
>>>>> Thoughts? I know Allan wasn't quite sold on this, as the downside is
>>>>> that we
>>>>> sort of pigeonhole ourselves into using the non-optional parameter as
>>>>> arguments
>>>>> to our action. This has zero effect on makepkg.
>>>>>
>>>>> I've also thought to add --option=arg syntax parsing, but I'm not sure
>>>>> we need
>>>>> this.
>>>>
>>>> Allan, was deferring to you on this.
>>>
>>>
>>> Well, I was deferring to you as Dave is right that I was never sold
>>> on this...
>>>
>>> Unless I am missing something, this does have a minor effect on
>>> makepkg.  In git "makepkg --pkg foo bar" builds only foo and bar
>>> from a split package.
>>
>> And, imo, this introduces bizzare unexpected behavior. With the
>> "standard" getopt{,_long}, passing something such as:
>>
>>   --pkg foo bar
>>
>> I'd expect bar to be completely unrelated to the flag. Not the case
>> here, and this behavior isn't really documented clearly at all. We don't
>> even properly handle arguments with whitespace anymore. Not such a big
>> deal for makepkg, but I think it's reasonable that pacman-key might some
>> day need to import a key from a file with a space in the name.
>
> I thought the whitespace issue was fixed but testing now I see it is not.
>  That is definitely something that needs addressed.
>
>>> I guess with this patch we would have to quote the package names in
>>> some way (like is needed on the current maint release).  So we would
>>> need to revert changes made to the makepkg documentation when the
>>> multiple arguments stuff was added.
>>
>> We can (should?) follow pacman here and separate multiple arguments by
>> commas. I'm going to channel Dan and call out "consistency" here.
>
> You mean like "pacman -S pkg1,pkg2"?   Fairly sure we do not do that! So I
> call consistency...  Where do we use commas in pacman options?

pacman -Syu --ignorepkg foo,bar.baz